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

[Paul Kyzivat <[e-mail]>]

On 3/22/13 10:28 PM, Mary Barnes wrote:
> On Fri, Mar 22, 2013 at 5:18 AM, Magnus Westerlund
> <[e-mail]> wrote:
>> On 2013-03-21 21:01, Paul Kyzivat wrote:
>>> On 3/21/13 6:15 PM, Magnus Westerlund wrote:
>>>> On 2013-03-20 17:55, Paul Kyzivat wrote:
>>>>> 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.
>>
>> What I understand you can't really in the general case sort out the
>> WebRTC interoperability. WebRTC is after all a JavaScript specific usage
>> of a generic bi-directional multi-channel data transmission. Where the
>> generic bi-directional paradigm is realized using RTCWEB defined data
>> protocol. Clue could reuse that basic scheme but it would not make it
>> clear about will be on specific channels, that can be explicit or
>> implicit and depends on the WebRTC application.
>>
>> It might be that certain usages becomes standardized and that we can
>> agree on labeling them and interconnect them with other systems. Doest
>> that need to happen in SDP. Don't think so. What I think will be
>> happening is that when you like to connect to a CLUE system using a
>> WebRTC supporting browser then you deploy a CLUE speaking JS, that will
>> use the data channel in a CLUE agreed way requiring minimal translation.
>> In fact the only adaptation is likely that the PeerConnection peer must
>> be capable of accepting peerConnections and interconnect them with a
>> CLUE system. In such system I don't see the WebRTC endpoint indicating
>> that it is CLUE interoperable, it is the CLUE JS APP plus the WebRTC to
>> CLUE gateway that ensures that this works. No changes to the WebRTC browser.
>
> [MB] This is exactly how I was anticipating it to work for the most
> part.  CLUE is defining a data model and from that I believe we can
> extract the data relevant to the CLUE JS APP. I also don't see how we
> could do it without a gateway. [/MB]

I'm not certain if I agree with my co-chair or not. :-)

I do agree that clue-specific JS must be delivered to the browser. And 
so this calls for a webserver that can do that and knows it should. And 
in the webrtc-sip case that means the webserver must serve as a 
signaling gateway for sip.

I don't think this requires that there be a signaling gateway for the 
clue protocol. It ought to be possible for the clue protocol to be 
direct between the browser and the sip-clue endpoint. That in turn means 
that the SCTP association setup and channel usage must be identical 
between the SIP UA and the browser. The webserver can of course adjust 
the JS to arrange that to be the case. I suppose it can arrange for the 
SCTP m-line to reference "clue" when talking to the sip server, while 
the SDP interface in the browser says "webrtc" for that.

This isn't the way I would *like* to be signaling SCTP usage in SIP/SDP, 
but I can live with it. Perhaps it is better to work on the taxonomy 
document before doing more. (I think we should at some point include 
SCTP associations and streams/channels in the taxonomy.)

	Thanks,
	Paul