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

[Christer Holmberg <[e-mail]>]

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.

> 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. 

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

Regards,

Christer