Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-02.txt

[Paul Kyzivat <[e-mail]>]

Harald,

(Speaking as co-chair of CLUE)

In clue we have some goals that overlap with this work and with rtcweb.

For one thing, we want to ensure that an webrtc client browser can act 
as a clue client. That means that the things that one must do to act as 
a clue client should be things that can be done from a browser using 
webrtc APIs and rtcweb protocols.

But of course we also expect clue clients that are *not* webrtc clients, 
that are built on a native sip infrastructure. And so we require that 
all combinations of native and webrtc clients to interoperate.

Also, in clue we need a single reliable bi-directional data channel for 
clue-specific signaling. We have mostly been considering the same 
SDP/DTLS/UDP transport that rtcweb is, partly because you guys have 
already done most of the work of defining it, and partly because we hope 
that means the APIs you define for it will mean that a browser based 
clue client will be able to implement that part of clue without needing 
any new clue-specific APIs. (Note that we only need *one* channel over 
the transport for this purpose. We don't care which one, but of course 
we do care that the two ends agree on what one it is.)

(The following point is more speculative - we haven't really considered 
it formally in clue, though there have been a few passing discussions 
here and there. And so this part is personal, not as chair.)

It is also the case that a clue client (either flavor) is likely to have 
need to simultaneously implement BFCP. This isn't really special to 
clue. When webrtc is used to hook a browser into any sip conference it 
may be necessary to use BFCP to access the advanced features of the 
conference.

It would be *nice* if the clue protocol and the bfcp protocol could 
coexist over a single SCTP transport, each taking its own channel. That 
would also make it possible for a webrtc cient to implement bfcp using 
the webrtc datachannel APIs. (If bfcp is run over TCP or UDP then AFAIK 
a webrtc client would not be able to support it.)

Of course there is currently no definition for bfcp over SCPT, and the 
work is still wrapping up to define it over UDP. So this is more wishful 
thinking on my part than anything else.

*If* we had both a clue protocol binding and a bfcp binding to SCTP data 
channels, then there would be a need for a way to set up a session that 
contains an SCTP transport m-line, and the channels to be used for clue 
and/or bfcp. This would be needed both natively, and with webrtc/rtcweb. 
The stuff that Salvatore is proposing in the sctp-sdp draft will 
hopefully support that.

(End of personal speculative part.)

*** Note: I am *not* arguing that channels may only be used if they have 
been negotiated in SDP. I think we should be able to work it out so that 
some channels are reserved in SDP and others can be used based on 
implicit agreement and/or by dynamic run-time negotiation. Obviously 
some work is required to make those things coexist, but that isn't 
rocket science.

What I want to avoid is the need for clue to support dynamic assignment 
of the channels it needs using some rtcweb-specific channel assignment 
protocol. Nor would I like to see some standardized static assignment of 
channels to protocols. (E.g. BFCP always uses channel 10 and CLUE always 
uses channel 11.)

AFAICT, the alternative to the above is that a webrtc clue client would 
be forced to run "its end" of the clue and bfcp protocols in the web 
server rather than the browser, and then exchange that information with 
the browser via translation to html or to a separate rtcweb data 
channel. While this is *possible*, it seems less than ideal.

Also, even ignoring rtcweb compatibility, when running native sip, I 
think we will want a way, in SDP, to negotiate one SCTP channel for the 
clue protocol and maybe another for bfcp (if that becomes supported).

	Thanks,
	Paul

On 11/2/12 6:35 AM, Harald Alvestrand wrote:
> On 10/24/2012 08:05 AM, Salvatore Loreto wrote:
>> Hi there,
>>
>> I have updated the draft trying to capture the result of the
>> discussion we had in this mailing list
>> writing down for SCTP a <fmt> syntax similar to that used for RTP,
>> i.e. with "channle numbers" being used in a way analogous to payload
>> type numbers.
> FWIW, I think locking ourselves into this scheme is a Very Bad Idea. It
> will make it impossible to do many of the novel and interesting
> applications envisaged by WebRTC participants.
>
> If you want to have the ability to declare some scoping for SCTP usage,
> I think we should at least:
>
> - Extend the "a=streams" parameter to take a range, including "*" for
> "unlimited".
> a=streams:1-* would mean that one expects to use at least 1 stream, but
> no upper limit.
> a=streams:0-255 would mean that one may or may not use streams, but
> can't support more than 255.
>
> - Extend the "a=datachannel" syntax to take a default notation, and not
> limit other fields.
> a=datachannel:* RTCWeb would then mean that all datachannels not
> explicitly specified will use the RTCWeb protocol, and label and other
> options will be passed using the RTCWeb initialization protocol.
>
> I would like to just hardcode in my browser that it always sends
>
> m=application 1234 DTLS/SCTP 0
> a=streams:0-*
> a=datachannel:* RTCWeb
>
> and really have SDP O/A stay out of the way of datachannel setup. I
> don't see the need to do more.
> But others may have other needs.
>
>>
>> The proposal is a very first attempt to see if this is the direction
>> we want to go
>> and it is obviously incomplete lacking the possibility to define
>> all the properties of the specific channel...
>>
>> feedback and comments are very welcome and necessary at this point
>>
>> best regards
>> Salvatore
>>
>>
>>
>>
>> On 10/22/12 10:07 PM, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>   This draft is a work item of the Multiparty Multimedia Session
>>> Control Working Group of the IETF.
>>>
>>>     Title           : Stream Control Transmission Protocol
>>> (SCTP)-Based Media Transport in the Session Description Protocol (SDP)
>>>     Author(s)       : Salvatore Loreto
>>>                            Gonzalo Camarillo
>>>     Filename        : draft-ietf-mmusic-sctp-sdp-02.txt
>>>     Pages           : 13
>>>     Date            : 2012-10-22
>>>
>>> Abstract:
>>>     SCTP (Stream Control Transmission Protocol) is a transport protocol
>>>     used to establish associations between two endpoints.  This document
>>>     describes how to express media transport over SCTP in SDP (Session
>>>     Description Protocol).  This document defines the 'SCTP',
>>> 'SCTP/DTLS'
>>>     and 'DTLS/SCTP' protocol identifiers for SDP.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-02
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>