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

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Apr 2013 14:41:43 +0000

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:[email-masked]
>        a=max-send-ssrc:{*:1}
>        a=max-recv-ssrc:{*:1}
>        ...
>        m=video 20000 RTP/SAVPF 96 98
>        a=mid:m2
>        a=ssrc:5678 cname:[email-masked]
>        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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Apr 2013 13:05:57 -0400

> 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,…

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.

> 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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Apr 2013 11:13:18 -0700

On 29 April 2013 10:05, Paul Kyzivat <[email-masked]> wrote:
>> 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.

I don't care whether SDP supports it or not, I care whether it makes
sense to do it at all.

There's a reason why you might not want to mux SCTP - it's a protocol
with multiplexing support.  Multiplexing outside of it is at best a
crude thing to do and at worst a way to dilute congestion signals.

I can understand how you can conceive of scenarios where different
application layer protocols don't play well together enough that you
want more aggressive separation.  I don't see significant value in
supporting those scenarios.

That doesn't completely preclude the future use of SCTP port for
demux, but it does constrain complexity.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Apr 2013 15:32:32 -0400

> demux, but it does constrain complexity.

I agree with you that there doesn't seem to be any obvious need for 
this, at least not now. I don't think we need to expend effort 
specifying how to do this sort of multiplexing now. For example, it may 
be sufficient to register a default sctp port for data channel over 
sctp, and assume that any other uses of DTLS/SCTP will either have to 
register their own default port or else specify a way of explicitly 
signaling the port.

My point was only to indicate another reason to design in a flexible 
mechanism for signaling the multiplexing mechanism(s).

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Apr 2013 15:41:51 -0400

One more thing - a question for all:

Do you agree that there is a need to support more than one way to demux 
RTP, and hence a need to signal what way is to be used?

Or do you think we will be able to reach agreement on a single 
algorithm, so that signaling of the algorithm isn't required?

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Apr 2013 16:03:00 -0700

On 29 April 2013 12:41, Paul Kyzivat <[email-masked]> wrote:
> Do you agree that there is a need to support more than one way to demux RTP,
> and hence a need to signal what way is to be used?
>
> Or do you think we will be able to reach agreement on a single algorithm, so
> that signaling of the algorithm isn't required?

There is agreement in avtcore to build two demux schemes.  The need to
signal the choice of demux scheme has already been made for us.

Yes, we could define BUNDLE to mean "demux by SSRC (and maybe PT (oh
and protocol if you've got this DTLS thingy))" and then have a
SHIMBUNDLE grouping.  That would be actively antisocial.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 30 Apr 2013 16:44:18 +0200

> SHIMBUNDLE grouping.  That would be actively antisocial.

Can you please clarify why you think this is anti-social?

I would like to point out that BUNDLE and SHIM operates at different
levels. To my understanding BUNDLE is a way of using multiple media
descriptions (m= lines) to describe one RTP session.

SHIM is an explicit layer for transmitting multiple independent RTP
session on the same lower layer transport. Each RTP session will be
described using its own signaling, which could include BUNDLE of
multiple m= lines.

The transmission of DTLS/SCTP over the same UDP flow as an RTP session
is yet another problem of who shares the lower layer transport.

A number of RTP sessions over SHIM will be able to share the lower layer
transport (UDP) with DTLS/SCTP, more from the perspective that it must
be able to share it with DTLS and STUN to make ICE and DTLS-SRTP work
than anything else.

Colin Perkins and I did privately discuss ways of signalling the SHIM
solution in Orlando and put together a strawman. I can share it here to
see what input you have.

1) We would have one m= line to describe the SHIM's transport itself, i.e.
m=application 12345 UDP/SHIM *
a=candidate ...

2) Each RTP session would be described normally with or without bundle.
Although we prefer to avoid BUNDLE, but that would depend on the rest of
discussion on what recommendation for multiple m= lines description of
one RTP session means.

The port numbers on the m= lines would be used as SHIM IDs. They anyway
have to be unique for fallback if BUNDLE is not supported.

3) The media descriptions involved in one SHIM will for clarity be
indicated using a SHIM specific grouping semantics.

4) If SHIM is supported as determined by first round, the media
descriptions can be cleaned up and any unnecessary transport information
can be removed in second round to verify that middleboxes don't
misunderstand that SHIM is being used and that is the only main
transport parameters for the streams put on that SHIM.

This proposal is intentionally not requiring BUNDLE because we want to
enable the fallback from SHIM to Individual sessions over different
transports if SHIM is not supported. If BUNDLE would be included then
then choice of fallback from SHIM might become BUNDLE, which in most
cases is not desired. You are using SHIM because you want different RTP
sessions, not have everything put into one RTP Session.

Sorry if I missed something important in earlier discussions. I am still
catching up on MMUSIC and I haven't managed to read it linearly.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Apr 2013 12:20:09 -0400

Inline...

> described using its own signaling, which could include BUNDLE of

AFAIK the SDP in support of shim has never really been discussed.
The bundle proposal. But the bundle draft does say:

    When media is transported using the Real-Time Protocol (RTP)
    [RFC3550], the default assumption of the mechanism is that all media
    associated with a "BUNDLE" group will form a single RTP Session
    [RFC3550].  However, future specifications can extend the mechanism,
    in order to negotiate RTP Session multiplexing, i.e.  "BUNDLE" groups
    where media associated with a group form multiple RTP Sessions.

which is a hint that it *could* be extended to apply when shim is used.

My thinking is that this bundling stuff is sufficiently messy and 
complex that we won't want to do something similar but different for shim.

Instead, I am inclined to view the shim as just another mechanism for 
multiplexing. If so, then a suitable mechanism for signaling the sort(s) 
of multiplexing to be used in a bundle should support it as well.

> is yet another problem of who shares the lower layer transport.

Yep! And we *know* we want to coexist that with some flavors of RTP.

> be able to share it with DTLS and STUN to make ICE and DTLS-SRTP work

IIUC the demux of shimmed RTP from DTLS/SCTP is exactly the same as for 
unshimmed RTP.

> solution in Orlando and put together a strawman. I can share it here to

IMO we don't need to spend much time on it now, as long as we can see a 
way forward if/when we get around to working on it.

> sessions, not have everything put into one RTP Session.

This smells like there are as many rat holes to pursue as there have 
been in bundles without SHIM. I doubt we want to go there now.

> catching up on MMUSIC and I haven't managed to read it linearly.

Hard to tell. :-)

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Apr 2013 11:55:22 -0700

> Can you please clarify why you think this is anti-social?

My impression was that there would be a degree of overlap between the
two solutions.  From your mail, it appears as though you intend to go
a completely different path.  So, not anti-social I guess.