IETF Logo Mail Archive

Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 15 March 2013 06:11 UTC

Return-Path: <btv1==786c9b4b8d3==HKaplan@acmepacket.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443C821F918D for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 23:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO5DBBEcxR-b for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 23:11:15 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2E21F9188 for <mmusic@ietf.org>; Thu, 14 Mar 2013 23:11:15 -0700 (PDT)
X-ASG-Debug-ID: 1363327873-03fc21725ffb0370001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id DMd4WcrhdQLCXuwi (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Mar 2013 02:11:13 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 15 Mar 2013 02:11:13 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "Simo.Veikkolainen@nokia.com Veikkolainen" <Simo.Veikkolainen@nokia.com>
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-ASG-Orig-Subj: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOIUPkbSOR6Ns9c0GQFY3QLJiTKA==
Date: Fri, 15 Mar 2013 06:11:12 +0000
Message-ID: <8680FAA9-F3DC-48FD-8CEC-82E801229072@acmepacket.com>
References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <D09DAE6B636851459F7575D146EFB54B21096CE7@008-AM1MPN1-026.mgdnok.nokia.com> <C91F1F83-C472-4FBF-A6D3-B37B08D85D10@acmepacket.com>
In-Reply-To: <C91F1F83-C472-4FBF-A6D3-B37B08D85D10@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <05A4E5A1EC223740AD4C4E2F0597D986@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363327873
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125247 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2013 06:11:16 -0000

Sorry, I didn't notice there was a lengthy email chain about this topic.  Ignore my email below.  It appears from the later emails that others were also confused by the wording of that section, but they know what they meant it to say.

Although I still have one simple question: when is it ok to use a 'ccap' attribute containing either an IP4 or IP6 address?

For example, how is this useful:

    m=audio 9 PSTN -
    c=PSTN E164 +15555556666
    a=ccap:1 IN IP4 198.51.100.7
    a=tcap:2 RTP/AVP
    a=omcap:1 0

Since there is no port number being offered for the IPv4 ccap, and the number 9 is being used for PSTN, how would this actually work??

-hadriel


On Mar 15, 2013, at 1:38 AM, Hadriel Kaplan <HKaplan@acmepacket.com>
 wrote:

> 
> For section 3.1.2, page 9:
>  The 'ccap' attribute MUST NOT be used in
>  situations where an existing mechanism (such as Interactive
>  Connectivity Establishment (ICE) [RFC5245]) can be used to select
>  between different connection addresses (e.g.  "IP4" and "IP6" or
>  different IP addresses within the same IP address family).
> 
> What does that sentence actually mean??  What's a "situation" where an existing mechanism *can* be used?
> 
> Does it mean 'ccap' MUST NOT be used if ICE is also used - i.e., they cannot both be in an offer?  
> Does it mean 'ccap' MUST NOT be used if it's technically possible to accomplish using ICE, even if the device in question doesn't support ICE?
> 
> When is it ok to use a ccap containing an IP4 or IP6 address?
> 
> -hadriel
> 
> 
> On Mar 13, 2013, at 11:08 AM, Simo.Veikkolainen@nokia.com wrote:
> 
>> Hello,
>> 
>> We just submitted a new version of the miscellaneous-caps draft, with text that states that if the connection data capability attribute (a=ccap) is used the port number in the resulting SDP MUST be the same as in the original "m=" line, except for PSTN type bearers (when the port number used is 9).
>> 
>> Regards,
>> Simo
>> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email