As there has been no further comments on the proposed text or the 
subsequently updated draft, we conclude that all issues have been 
resolved at this point. In the absence of any objections by the end of 
this week (May 12), we will proceed with the publication request of the 
-05 version of the draft.

Thanks

-- Flemming (MMUSIC co-chair)


On 5/3/13 3:29 AM, Simo.Veikkolainen@nokia.com wrote:
> I didn't find any additional comments on this, so I went ahead and changed the paragraphs according to Flemming's proposal and submitted a new version.
>
> Regards,
> Simo
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Veikkolainen Simo (Nokia-CTO/Espoo)
> Sent: 26. huhtikuuta 2013 12:22
> To: fandreas@cisco.com
> Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com
> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
> See below [SV].
>
> -----Original Message-----
> From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: 25. huhtikuuta 2013 19:16
> To: Veikkolainen Simo (Nokia-CTO/Espoo)
> Cc: mohamed.boucadair@orange.com; aallen@blackberry.com; HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com
> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
>
> On 4/23/13 4:37 AM, Simo.Veikkolainen@nokia.com wrote:
>> Below the original and proposed text on the usage of ccap attribute in
>> Section 3.1.2. of
>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04
>>
>> This is pretty much the same text I proposed earlier, including Jonathan's wording on IN address families.
>>
>> --- begin original text ---
>>      The 'ccap' capability attribute allows for expressing alternative
>>      connection address ('c=') lines in SDP as part of the SDP capability
>>      negotiation process.  The 'ccap' capability attribute is intended to
>>      be used only when there is no other mechanism available for
>>      negotiating alternative connection address information, such as when
>>      the <nettype> is different among the alternative addresses (e.g.
>>      "IN" and "PSTN").  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).
>> --- end original text ---
>>
>> --- begin proposed text ---
>>      The 'ccap' capability attribute is intended for offering
>>      alternative connection addresses where the <nettype>
>>      is "IN" or "PSTN", i.e. selecting between an IP based
>>      bearer or a circuit-switched bearer.
>>
>>      The 'ccap' attribute MUST NOT be used to indicate more
>>      than one address with an IN network type in actual
>>      or potential configurations for any given media description
>>      (e.g. between  "IP4" and "IP6" address families or different
>>      IP addresses within the same IP address family).
>> --- end proposed text---
> I'm ok with the overall restriction but I think the opening wording is overly constraining. With that in mind, a slightly modified proposal below:
> <quote>
>
>      The 'ccap' capability attribute allows for expressing alternative
>      connection address ('c=') lines in SDP as part of the SDP capability
>      negotiation process. One of the primary use cases for this is offering
>      alternative connection addresses where the <nettype>
>      is "IN" or "PSTN", i.e., selecting between an IP based
>      bearer or a circuit-switched bearer.
>
> By supporting the "IN" <nettype>, the 'ccap' attribute enables the signaling of multiple IPv4 and IPv6 addresses, however the Standards Track mechanism for negotiation of alternative IP addresses in SDP is Interactive Connectivity Establishment (ICE) [RFC5245]. The 'ccap' attribute does not change that and hence the combined set of actual and potential configurations (as defined in [RFC5939]) for any given media description MUST NOT use the 'ccap' attribute to negotiate more than one address with an IN network type (i.e., it is not permissible to select between "IP4" and "IP6" address families or different IP addresses within the same IP address family).
>
> </quote>
>
> [SV] I think your proposal makes the intent clearer; I'll edit the text accordingly.
>
> Simo
>
>> Also, since no alternative port numbers can be offered, add this sentence at the end the of the last paragraph to clarify how alternative IP and PSTN media descriptions are offered:
>>
>>      This document does not define any mechanism for negotiating or
>>      describing different port numbers and hence the port number from the
>>      "m=" line MUST be used by default. Exceptions to this default can be
>>      provided by extension mechanisms or network type specific rules.
>>      This draft defines an exception when the network type is "PSTN", in
>>      which case the port number is replaced with 9 (the "discard" port) as
>>      described in Session Decription  Protocol (SDP) Extension For Setting
>>      Up Audio and Video Media Streams over Circuit-Switched Bearers in the
>>      Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs].
>>    --- begin new text ---
>>      An endpoint offering alternative IP and PSTN bearers MUST include the
>>      IP media description in the actual configuration (IP address in the "c=" line
>>      and port number in the "m=" line), and the PSTN media descriptions in the
>>     potential configuration.
>> --- end new text ---
> Looks good.
>
> Thanks
>
> -- Flemming
>
>> Regards,
>> Simo
>>
>>
>> -----Original Message-----
>> From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
>> Sent: 17. huhtikuuta 2013 17:33
>> To: mohamed.boucadair@orange.com
>> Cc: Veikkolainen Simo (Nokia-CTO/Espoo); aallen@blackberry.com;
>> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org;
>> christer.holmberg@ericsson.com
>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and
>> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>
>>
>> On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote:
>>> Hi Felmming,
>>>
>>> Because it does not allow to indicate an alternate port number.
>> Correct - a connection address does not provide a port number; a different capability would be needed for that.
>>> This makes it a no working solution for various scenarios.
>> No - it simply means that you would need to define another capability to convey port numbers if you wanted such a solution (however we have ICE as the complete solution for that and the WG has not indicated a desire to change that).
>>
>>> The text which triggered this discussion was confusing. I hope the updated version will be much more clear and reflect what have been discussion so far in this thread.
>> I have asked Simo to update the draft.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>> Cheers,
>>> Med
>>>