Re: [MMUSIC] SCTP question: Where does it multiplex?

[Harald Alvestrand <[e-mail]>]

On 12/01/2012 12:03 PM, Salvatore Loreto wrote:
> Hi Harald,
>
> sorry to be late on this
> and thanks a lot for raising the question
>
> IMO how to multiplex DTLS/SCTP traffic with te rest of the "WebRTC" 
> traffic is something that belongs
> to the BUNDLE discussion, and there won't be anything about how to 
> bundle in this draft.
> To answer your question at present I don't think there should be 
> anything special for DTLS/SCTP
The interesting difference is that the multiplexing between DTLS/SCTP 
traffic and BUNDLE multiplexing is that DTLS/SCTP traffic is not carried 
in SSRCs, which means:

- There can be only one DTLS/SCTP stream in a bundle (which may have 
multiple associations, as you state below); you can't have multiple 
lines with proto DTLS/SCTP in a bundle.
- None of the ordinary BUNDLE considerations about colliding parameters 
apply

Since the ability to multiplex was thought an important factor for 
selecting this stacking, we'd better make sure we specify how it's being 
done.

>
> However, what I have in my working copy on the draft (I will publish 
> it at some point next week)
> and it can be interesting to you is the possibility to have multiple 
> SCTP associations on top of the same
> DTLS connection (for future WebRTC scenarios, or non WebRTC scenarios):
>
>        Running SCTP over DTLS make possible to have multiple SCTP
>        associations on top of the same DTLS connection; each SCTP
>        association make use of a distinct port number that is mainly
>     used to
>        demultiplex the associations.  If the <proto> sub-field is 'DTLS/
>        SCTP' the <fmt> sub-fields contain SCTP association port numbers.
>
that's a sentence fragment I can't parse, so I hope you revise that 
before submission. If there's a comma before "the <fmt> sub-fields" it 
parses.
>
>        When a list of port number identifiers is given, this implies that
>        all of these associations MUST run on top of the DTLS connection.
>        For the payload type assignments the "a=sctpmap:" attribute
>        SHOULD be used to map from a port number to a media
>        encoding name that identifies the payload format transported by the
>        association or the actual application protocol running on top
>     of it.
>
>
>                   m=application 54111 DTLS/SCTP 5000 5001 5002
>                   c=IN IP4 79.97.215.79
>                   a=sctpmap:5000 protocol=webrtc-DataChannel;streams=16
>                   a=sctpmap:5001 protocol=XXX;streams=2
>                   a=sctpmap:5002 protocol=YYY;streams=1
>
>
> best regards
> Salvatore
>
>
>
> On 11/2/12 12:39 PM, Harald Alvestrand wrote:
>> As currently specified, the DTLS/SCTP protocol is carefully specified 
>> in such a way that it can ride on the same 5-tuple as an SRTP 
>> session. I'd like to keep that property when we SDP-negotiate it.
>>
>> The proposed syntax for DTLS/SCTP seems to be
>>
>> m=<something, likely application> <port number> DTLS/SCTP <fmt data, 
>> mostly meaningless>
>>
>> I see two ways to define this as a multiplex:
>>
>> - Give the same port number as another m= line in the same SDP session
>> - Give a meaningless port number, and use the a=group:BUNDLE (of 
>> whatever flavor) to give which port number it's actually multiplexed 
>> together with.
>>
>> The best way to do this may be obvious after the BUNDLE discussion, 
>> but in case there are other considerations .... are there thoughts?
>>
>>                Harald
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>
> -- 
> Salvatore Loreto, PhD
> www.sloreto.com
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic