Re: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example

[Paul Kyzivat <[e-mail]>]

On 4/29/13 10:41 AM, Christer Holmberg wrote:
>
> Hi,
>
>> For instance, consider the following:
>>
>>         ...
>>         c=IN IP4 host.biloxi.com
>>         a=group:BUNDLE m1 m2 m3 m4
>>         m=audio 20000 RTP/SAVPF 0
>>         a=mid:m1
>>         a=ssrc:12345 cname:[e-mail]
>>         a=max-send-ssrc:{*:1}
>>         a=max-recv-ssrc:{*:1}
>>         ...
>>         m=video 20000 RTP/SAVPF 96 98
>>         a=mid:m2
>>         a=ssrc:5678 cname:[e-mail]
>>         a=max-send-ssrc:{*:1}
>>         a=max-recv-ssrc:{*:1}
>>         ...
>>         m=video 20000 RTP/SAVPF 96 98
>>         a=mid:m3
>>         a=max-send-ssrc:{*:4}
>>         a=max-recv-ssrc:{*:4}
>>         ...
>>         m=application 20000 DTLS/SCTP ...
>>         a=mid:m4
>>         ...
>>
>> We have four bundled m-lines. We have one proto (RTP/SAVPF) in three
>> m-lines, and another (DTLS/SCTP) in the other m-line. From a protocol
>> layering perspective we have:
>>
>>     m1      m2      m3      m4
>>     =====   =====   =====   ====
>>     SAVPF   SAVPF   SAVPF   SCTP
>>     RTP     RTP     RTP     DTLS
>>     UDP     UDP     UDP     UDP
>>     IP      IP      IP      IP
>>
>> So, the first demux that must be done is to distinguish RTP from DTLS.
>> DTLS has been designed to have a field that distinguishes it from
>> RTP/RTCP/ICE, so that can perhaps be considered a default demux
>> algorithm for that.
>
> Correct.
>
>> Because there is only one SCTP m-line, that is enough to identify those
>> packets that should be bound to m4.
>
> In your example there is only one SCTP m- line, and in WebRTC I guess it will also be the case, but SDP doesn't prevent you from using multiple SCTP m- lines - unless BUNDLE explicitly forbids it, that is.

I agree. If we want to support that, then the obvious way (for 
DTLS/SCTP) is via SCTP port. That depends on there being a way to 
specify the SCTP with DTLS/SCTP. That has come and gone from the SDP 
proposal for SCTP.

If we were talking about just plain SCTP then I don't think bundling 
makes any sense.

And for SCTP/DTLS I suppose it might be possible to bundle with some 
other things running over DTLS. I'm not sure if we want to think about 
that now.

>> But we need to use something else to sort out the RTP.
>>
>> In this example, payload type can be used to distinguish audio from
>> video. But there may be cases where that isn't possible. If we want to
>> allow this mechanism, then perhaps we need some way to signal that it
>> should be used. Or *maybe* we could count on it being inferred. Assuming
>> that is used, then it is sufficient to identify those packets that
>> belong to m1.
>>
>> Or, because m1 is marked as having at most one ssrc, and the ssrc value
>> (1234) is specified, that could be used to bind packets to m1.
>>
>> Similarly, RTP packets having ssrc=5678 can be bound to m2.
>>
>> m3 supports multiple unspecified SSRCs. Since there is only one m-line
>> that does, all the packets with pt 96 or 98 and with an ssrc other than
>> 1234 or 5678 can be bound to m3.
>>
>> I'm undecided if we can count on inferring this decision logic from
>> existing signaling options, or if we ought to signal the choices more
>> explicitly.
>
> At least I think that, based on e-mail discussions, we most likely cannot rely on unique payload type values for each RTP flow.

What I saw from the discussions was the possibility of bundling *one* 
audio m-line and *one* video m-line, and potentially running multiple 
flows within each of those. In that usage, using PT for demux is feasible.

> (Nothing of course forbids users from using unique payload type values.)

Its unclear to me how the usage of bundlling is going to evolve. So I 
don't have a clear idea how much flexibility we need to allow for a 
multitude of different demux strategies.

BTW, another demux strategy appears if you use bundling with the shim 
proposal.

To me the key is to provide a framework for signalling the mux/demux 
strategy in SDP. And part of that is deciding whether the strategy is 
declarative or negotiated in O/A. (It is hard for me to see how it could 
be *negotiated* in one O/A cycle. So I'm imagining that the offer makes 
a proposal and it succeeds or fails - with failure meaning no bundling.)

	Thanks,
	Paul