Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03

[Paul Kyzivat <[e-mail]>]

On 3/21/13 6:15 PM, Magnus Westerlund wrote:
> On 2013-03-20 17:55, Paul Kyzivat wrote:
>> Magnus,
>>
>> Some comments on your review, from a CLUE perspective:
>>
>> On 3/20/13 11:11 PM, Magnus Westerlund wrote:
>>
>>> 6. Section 4.1:
>>>
>>> This section discuss the usage of the "data channels" within the SCTP
>>> association. My personal position is that for the moment this appears to
>>> be unnecessary. The most important part is the SCTP association
>>> establishment. Then one can discuss the general application using the
>>> SCTP association as whole. Examples of such are WebRTC data channel.
>>>
>>> If anyone want stream level information in SDP then I propose that this
>>> is handled as a extension to this signaling, not an from the start
>>> included functionality as we don't appear to have clear requirement for
>>> that.
>>
>> Who is "we"?
>
> MMUSIC WG
>
>> In CLUE we expect to use this mechanism for a CLUE data channel.
>> And we intend to do so in pure sip-sip cases as well as webrtc-sip and
>> webrtc-webrtc cases.
>
> Yes.
>>
>> While webrtc-webrtc may have an independent mechanism to work out the
>> channel usage, that is certainly not so for sip-sip sessions.
>>
>> So I think "we" (CLUE) have a requirement to negotiate channel usage in
>> SDP.
>
> Do you? Or it is sufficient to say
>
> m=application 12234 UDP/DTLS/SCTP CLUE
>
> Indicating that this SCTP association is using CLUEs defined way, not
> WebRTC. I want to separate the usage of individual SCTP streams and the
> general usage of the SCTP association.

Then what do we do for an WEBRTC client doing CLUE, talking to a native 
sip CLUE endpoint?

I guess clue could live with a mechanism that reserves the complete SCTP 
association, with all of its streams, as globally managed in a 
clue-specific way, as long as we can sort out the interop with webrtc.

	Thanks,
	Paul

>>> 7. Section 4.2:
>>>
>>> What are the requirements behind being able to establish multiple SCTP
>>> association over the same DTLS connection? I am very unclear why this
>>> would be required, and if not really needed I would suggest keeping
>>> things simple.
>>
>> I agree there has been no compelling need advanced for multiple SCTP
>> associations over the same DTLS connection. But the fact is that SCTP
>> has its own notion of port, and that needs to be dealt with one way or
>> another. At a minimum this document should specify what SCTP port is to
>> be used when conforming to this specification.
>
> Agreed, there need to be clarity on the port usage.
>
>>
>>> 8. Section 4.3: I guess this can for the moment be removed as it appears
>>> to be taken care in other places, such as the RTCWEB WG data channel
>>> protocol proposal.
>>
>> See above. That doesn't meet CLUE needs.
>
> Disagree, I don't think CLUE need SCTP stream specific indication or
> negoitation. It will be sufficient to indicate that this is CLUE using SCTP.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>
>