Subject: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 11:53:18 +0000

Hi,

I put together some text regarding the de-muxing for BUNDLE.

Note that there is yet no text on HOW the de-muxing is performed. The text only cover the SCOPE of what will be specified in the BUNDLE spec. I want us to agree on that first :)

Regards,

Christer

---------------------------------------------------

9.  Transport Protocol De-Multiplexing

9.1.  General

   Endpoints can assign "m=" lines representing different transport
   protocols [RFC4566], identified using the "m=" line proto value
   [RFC4566].

   As each "m=" line in a BUNDLE group share the BUNDLE address, an
   endpoint MUST be able to de-multiplex data received on the BUNDLE
   address, meaning it MUST be able to associate the received with one
   of the transport protocols assigned to the BUNDLE group.  Endpoints
   MUST NOT assign a transport protocols to a BUNDLE group, unless it is
   able to separate received data from data associated with other
   transport protocols assigned to the BUNDLE group.

   In addition, if an endpoint assigns multiple "m=" lines representing
   the same transport protocol to a BUNDLE group, the endpoint MUST be
   able to, in addition to associating received data to its transport
   protocol, also associate the received data with a specific "m=" line
   representing that transport protocol.

   This specification defines how to de-multiplex received media
   associated with the following transport protocols:

   o  "RTP/AVP" [RFC4566];

   o  "RTP/AVPF" [RFC4585];

   o  "RTP/SAVP" [RFC3711];

   o  "RTP/SAVPF" [RFC5124];and

   o  "SCTP/DTLS" [ref-to-be added].

   This specification also specifies how RTP packats are separated from
   RTCP packets.

   If an endpoint assigns multiple "m=" lines representing RTP/RTCP
   media to a BUNDLE group, it is outside the scope of this
   specification how the endpoint associates received RTP/RTCP packets
   with a specific RTP/RTCP "m=" line (endpoints might use payload type
   values, or SSRC values, for the association).

   If endpoints want to assign "m=" lines representing other transport
   protocols to a BUNDLE group, it MUST be documented how the de-
   multiplexing is performed.  There might also be a need for signalling
   extensions in order for endpoints to exchange data needed for the de-
   multiplexing.

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 19 Jun 2013 12:12:41 +0000

Christer,

although BUNDLE can be used independent of ICE, the de-mux should consider STUN messages which will also arrive at the BUNDLE address.
If this is then in scope or out of the scope of the BUNDLE spec can be discussed.
However, I would regard it being in scope.

Regards
Thomas

________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Mittwoch, 19. Juni 2013 13:53
An: [email-masked]
Betreff: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Hi,

Regards,

Christer

9.1.  General

   o  "RTP/AVP" [RFC4566];

   o  "RTP/AVPF" [RFC4585];

   o  "RTP/SAVP" [RFC3711];

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 12:19:08 +0000

Hi Thomas,
 
> However, I would regard it being in scope.

Good point. I personally strongly think STUN shall be in the scope.

Regards,

Christer

________________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Mittwoch, 19. Juni 2013 13:53
An: [email-masked]
Betreff: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
Hi,

Regards,

Christer

9.1.  General

   o  "RTP/AVP" [RFC4566];

   o  "RTP/AVPF" [RFC4585];

   o  "RTP/SAVP" [RFC3711];

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Jun 2013 14:31:31 +0200

On 06/19/2013 01:53 PM, Christer Holmberg wrote:
> Note that there is yet no text on HOW the de-muxing is performed. The 
> text only cover the SCOPE of what will be specified in the BUNDLE 
> spec. I want us to agree on that first :)
>

I think you should be careful about this. You risk duplicating material 
from other specs.

> Christer

This is somewhat incomprehensible to me; the most logical description I 
can make is that it means that you can separate packets into one heap 
containing all the RTP variants and another heap containing SCTP/DTLS - 
but that is not obvious. Suggest instead:

This specification defines how to de-multiplex protocols carried over 
RTP (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] 
from protocols carried over DTLS (which include SCTP/DTLS []).

And that makes the specification of the demultiplexing very simple:

"See RFC 5764 section 5.1.2"

>    This specification also specifies how RTP packats are separated from

Again, the specification of how to do this separation is very simple:

"See RFC 5761 section 4"
>    extensions in order for endpoints to exchange data needed for the de-

I agree with the sense of these paragraphs.

>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 12:36:58 +0000

Hi Harald,
 
> I think you should be careful about this. You risk duplicating material from other specs.

That's why I am eager to hear your input on what shall be covered in the BUNDLE spec regarding de-muxing :)

For example, are you saying BUNDLE shouldn't specify HOW the de-muxing is done?

Regards,

Christer

 

 
9.1.  General

 

   o  "RTP/AVP" [RFC4566];
 
   o  "RTP/AVPF" [RFC4585];
 
   o  "RTP/SAVP" [RFC3711];

This is somewhat incomprehensible to me; the most logical description I can make is that it means that you can separate packets into one heap containing all the RTP variants and another heap containing SCTP/DTLS - but that is not obvious. Suggest instead:

This specification defines how to de-multiplex protocols carried over RTP (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from protocols carried over DTLS (which include SCTP/DTLS []).

 

"See RFC 5761 section 4"

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Jun 2013 14:48:26 +0200

> For example, are you saying BUNDLE shouldn't specify HOW the de-muxing is done?

Absolutely, I'm saying that BUNDLE should not specify a procedure for 
de-muxing.
Instead, it should point to the specs that already specify how the 
de-muxing is done.

See my comments below as to what I think it should say.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 13:06:02 +0000

Hi,
 
>>>> Note that there is yet no text on HOW the de-muxing is performed. 
>>>>> The text only cover the SCOPE of what will be specified in the 
>>>> BUNDLE spec. I want us to agree on that first :)
> Absolutely, I'm saying that BUNDLE should not specify a procedure for de-muxing.
> Instead, it should point to the specs that already specify how the de-muxing is done.
>

I didn't see your comments in the previous mail. Sorry for that.

But, as Thomas said, we also need to cover STUN packets.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Jun 2013 15:37:36 +0200

> But, as Thomas said, we also need to cover STUN packets.

This is also covered in RFC 5764 section 5.1.2.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Jun 2013 06:37:57 -0700

Harald said: 
> de-muxing. Instead, it should point to the specs that already specify how the 
> de-muxing is done.
[BA] RTP/RTCP multiplexing is covered in RFC 5761, and de-multiplexing of RTP and DTLS is covered in RFC 5764, so there is no need for BUNDLE to create new text on those aspects.  However, there is still the open question of whether payload type can be required to be unique on all bundled m lines.  If so, then PT demultiplexing is viable; if not, then a combination of PT and SSRC de-muliplexing will be needed.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 13:48:07 +0000

Hi,

> [BA] RTP/RTCP multiplexing is covered in RFC 5761, and de-multiplexing of RTP and DTLS is covered in RFC 5764, so there is no need for BUNDLE to create new text on those aspects. 

Great.

> However, there is still the open question of whether payload type can be required to be unique on all bundled m lines.  If so, then PT demultiplexing is viable; if not, then a combination of PT and SSRC de-muliplexing will be needed.

The suggested text currently says that, in case you have multiple "m=" lines associated with the same transport protocol (e.g. RTP/AVP), selecting which of those "m=" lines received media belongs (whether it's based on PT, SSRC or something else) to is outside the scope of the document.

But, IF we think that shall be described, then we need to add text.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Jun 2013 07:13:31 -0700

Christer said:
"The suggested text currently says that, in case you have multiple "m=" lines associated with the same transport protocol (e.g. RTP/AVP), selecting which of those "m=" lines received media belongs (whether it's based on PT, SSRC or something else) to is outside the scope of the document.

But, IF we think that shall be described, then we need to add text."
[BA] Leaving this out could result in interoperability problems (unless it is specified elsewhere and this document references that).     So I do think that some text is needed, somewhere.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 15:56:35 +0000

Hi,

The question is whether we shall specify exactly how entities associate RTP packets with the correct m= lines, or whether we shall simply give some guidelines and hints.

For example, a client can choose to use unique PT values per m- values, within a given BUNDLE group, and everything should work fine. And, if the endpoint runs out of PT values, the create a new BUNDLE group. Now, whether it's religiously correct, I don't know :)

OR, if the endpoints are able to signal which SSRCs they are going to use, they can use that.

OR, if the endpoints support some kind of RTP header extension for this purpose, they can use that.

Etc.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Bernard Aboba [[email-masked]]
To: Christer Holmberg [[email-masked]]; Harald Alvestrand [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Christer said:

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Jun 2013 18:32:58 +0200

On 06/19/2013 05:56 PM, Christer Holmberg wrote:
> Hi,
> The question is whether we shall specify exactly how entities 
> associate RTP packets with the correct m= lines, or whether we shall 
> simply give some guidelines and hints.
> For example, a client can choose to use unique PT values per m- 
> values, within a given BUNDLE group, and everything should work fine. 
> And, if the endpoint runs out of PT values, the create a new BUNDLE 
> group. Now, whether it's religiously correct, I don't know :)

OR, if they don't care which M-line the stream is associated with, the 
question may be moot.

In all cases, the payload type MUST clearly identify the codec 
configuration it's associated with.

At the moment the text says:

    o  - The dynamic payload type values used in the "m=" lines MUST NOT
       overlap.

That's a holdover from the time I imagined this only being used with a 
very small number of M-lines; since we're now discussing potential SDP 
with hundreds of M-lines, I'd like to change this to:

   o - If the configuration of two M-lines differs in any aspect except 
(.. maybe something goes here ..),
        the dynamic payload type values used in the "m=" lines MUST be 
different.

YMMV.

> Etc.
> Regards,
> Christer
>
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> *From:* Bernard Aboba [[email-masked]]
> *To:* Christer Holmberg [[email-masked]]; Harald 
> Alvestrand [[email-masked]]
> *CC:* [email-masked] [[email-masked]]
> *Subject:* RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
>
> Christer said:
>
> "The suggested text currently says that, in case you have multiple 
> "m=" lines associated with the same transport protocol (e.g. RTP/AVP), 
> selecting which of those "m=" lines received media belongs (whether 
> it's based on PT, SSRC or something else) to is outside the scope of 
> the document.
>
> [BA] Leaving this out could result in interoperability problems 
> (unless it is specified elsewhere and this document references that). 
>     So I do think that some text is needed, somewhere.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 16:47:21 +0000

Hi,
 
> OR, if they don't care which M-line the stream is associated with, the question may be moot.

Correct.

> In all cases, the payload type MUST clearly identify the codec configuration it's associated with.

*IF* you have a way to find the right m= line, couldn't PT X have different codec configurations in different m= lines?

> That's a holdover from the time I imagined this only being used with a very small number of M-lines;

True. I haven't touched that text in the latest version. Guess I could have removed it, or at least added a big NOTE saying it's an open issue.

> since we're now discussing potential SDP with hundreds of M-lines, I'd like to change this to:
>
>  o - If the configuration of two M-lines differs in any aspect except (.. maybe something goes here ..), 
>       the dynamic payload type values used in the "m=" lines MUST be different.

What do you mean by "configuration of two M-lines"?

Don't you mean the configuration of two codecs? For example, if I have 2 m= lines, with exactly the same H.264 configuration in each, could I use the same PT value in both m= lines? But, if I have different codec configurations in each m= line, I CANNOT use the same PT value for both?

...assuming, of course, that there is some other mechanism to find the right m= line, IF needed.

Regards,

Christer

-----Original Message-----
From: Bernard Aboba [[email-masked]]
To: Christer Holmberg [[email-masked]]; Harald Alvestrand [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) 

Christer said:

---

From: Emil Ivov <[email-masked]>
Date: Wed, 19 Jun 2013 19:09:41 +0200

> *IF* you have a way to find the right m= line, couldn't PT X have different codec configurations in different m= lines?

Let's assume that it could ... but then how would you know that your 
peer also supports the same demuxing technique as yourself?

In SIP for example, when constructing a first offer, you may want to map 
both Opus and VP8 to 96, then add SSRCs for demuxing. This means that 
you expect your peer to support SSRC demuxing and you can't expect that 
unless we mandate it.

Or am I missing something?

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 18:01:03 +0000

Hi,

>>>> values, within a given BUNDLE group, and everything should work 
>>>> fine. And, if the endpoint runs out of PT values, the create a new 
>>>> BUNDLE group. Now, whether it's religiously correct, I don't know :)
>>>>
> Let's assume that it could ... but then how would you know that your peer also supports the same demuxing technique as yourself?

In the PT case, he doesn't have to, because he is going to tell you what PT values he wants you to send him.

> In SIP for example, when constructing a first offer, you may want to map both Opus and VP8 to 96, then add SSRCs for demuxing. This means that you expect your peer to support SSRC demuxing and you can't expect that unless we mandate it.
>

No. In case of support of extensions (e.g. the SDP ssrc attribute), you either have to perform some kind of capability exchange before you send the initial Offer. Or, you will figure out in the response to the initial Offer, and then you can "fix" it in a new Offer (as BUNDLE is currently specified, you will have to send a second Offer anyway).

But, again, what I want to discuss now is whether/what we are going to specify regarding the usage of multiple m= lines with the same transport protocol (RTP, or whatever other there could be).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jun 2013 15:09:21 -0400

On 6/19/13 7:53 AM, Christer Holmberg wrote:
> text only cover the SCOPE of what will be specified in the BUNDLE spec.
> I want us to agree on that first :)
>
> Regards,
>
> Christer
>

There is something this doesn't address. Suppose I tried to bundle an 
RTP/AVP with a TCP/RTP/AVP. I could indeed demux them, because they 
actually travel over different 5-tuples. But I don't think we should 
consider this bundling.

So, to be bundled, I think at the lowest level they must all share the 
same transport protocol. But I don't know exactly what terminology to 
use to say that.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Jun 2013 21:18:07 +0200

On 06/19/2013 07:09 PM, Emil Ivov wrote:
>>>> associate RTP packets with the correct m= lines, or whether we 
>>>> shall simply give some guidelines and hints.
>>>>
>> *IF* you have a way to find the right m= line, couldn't PT X have 
>> different codec configurations in different m= lines?
>
> In SIP for example, when constructing a first offer, you may want to 
> map both Opus and VP8 to 96, then add SSRCs for demuxing. This means 
> that you expect your peer to support SSRC demuxing and you can't 
> expect that unless we mandate it.

Using 96 for both Opus and VP8 is flat out illegal according to the RTP 
specs.

The corner case where we're discussing whether one can use the same 
payload type is if you have two M-lines that both specify VP8, with the 
same codec parameters - whether they can both use 96, given that it's 
the same codec.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jun 2013 15:18:34 -0400

On 6/19/13 9:37 AM, Bernard Aboba wrote:
> [BA] RTP/RTCP multiplexing is covered in RFC 5761, and de-multiplexing
> of RTP and DTLS is covered in RFC 5764, so there is no need for BUNDLE
> to create new text on those aspects.

I'm replying here, rather than to Harald because both of you say more or 
less the same thing and its more concise here.

IIUC, RFC 5764 says how to demux DTLS from DTLS/SRTP, but not how to 
demux DTLS from other RTP. I think it turns out that the same mechanism 
works for both, but that is by accident rather than specification.

I don't know if/when someone would want to use vanilla RTP with DTLS, 
but somebody will probably find a reason. (Not RTCWEB.) It will take 
more than a reference to 5764 to cover it.

Also, 5764 only covers a single m-line using DTLS payload packets. That 
also needs to be addressed explicitly.

> However, there is still the open
> question of whether payload type can be required to be unique on all
> bundled m lines.  If so, then PT demultiplexing is viable; if not, then
> a combination of PT and SSRC de-muliplexing will be needed.

I agree.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Wed, 19 Jun 2013 21:20:50 +0200

On 19.06.13, 20:01, Christer Holmberg wrote:
>>>>> associate RTP packets with the correct m= lines, or whether
>>>>> we shall simply give some guidelines and hints.
>>>>>
>>>>> For example, a client can choose to use unique PT values per
>>>>> m- values, within a given BUNDLE group, and everything should
>>>>> work fine. And, if the endpoint runs out of PT values, the
>>>>> create a new BUNDLE group. Now, whether it's religiously
>>>>> correct, I don't know :)
>>>>>
>>>>> OR, if the endpoints support some kind of RTP header
>>>>> extension for this purpose, they can use that.
>>>>>
>> Let's assume that it could ... but then how would you know that
>> your peer also supports the same demuxing technique as yourself?
>

Yes but how do you know whether or not it is going to pre-announce SSRCs 
so that you could demux the payload types that you want to receive?

>> In SIP for example, when constructing a first offer, you may want
>> to map both Opus and VP8 to 96, then add SSRCs for demuxing. This
>> means that you expect your peer to support SSRC demuxing and you
>> can't expect that unless we mandate it.
>>
> No. In case of support of extensions (e.g. the SDP ssrc attribute),
> you either have to perform some kind of capability exchange before
> you send the initial Offer. Or, you will figure out in the response
> to the initial Offer, and then you can "fix" it in a new Offer (as
> BUNDLE is currently specified, you will have to send a second Offer
> anyway).

Exactly. So what bothers me is that without at least one default 
demuxing a bundle offer can be downgraded to non-bundle if

1. the answerer doesn't support bundle
2. the answerer doesn't support the demuxing mechanism the offerer would 
like to use.

Point 2 means that UAs would have to support as many demuxing mechanisms 
as possible, even if they don't actually need them, just so that they 
could have bundle. This doesn't sound like a great thing.

What would be the downside of mandating PT demuxing but allowing it to 
be overridden by other mechanisms when available?

Emil

> But, again, what I want to discuss now is whether/what we are going
> to specify regarding the usage of multiple m= lines with the same
> transport protocol (RTP, or whatever other there could be).
>
> Regards,
>
> Christer
>
>

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jun 2013 15:22:02 -0400

> OR, if they don't care which M-line the stream is associated with, the

I think this is a silly argument. If they don't care which m-line the 
stream is associated with then there was no need to insert the m-line.

If there is a reason to have the m-lines, then there needs to be a way 
to associate packets with m-lines.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Wed, 19 Jun 2013 21:25:30 +0200

> Using 96 for both Opus and VP8 is flat out illegal according to the RTP

It somehow sounded to me that people decided this didn't matter. Crazy 
times :). I am glad to know I was wrong.

> same codec parameters - whether they can both use 96, given that it's

Well same question then: what would be the downside of only allowing 
that once support for a non-PT demuxing mechanism has been confirmed?

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Jun 2013 21:26:20 +0200

> What do you mean by "configuration of two M-lines"?

I mean everything that follows "m=" and right up to the next "m=".

I don't think it ever makes sense to insist that two M-lines have the 
same MID, so the parenthesis should not be empty. But I want to hear 
from other people what they think are the conditions under which they 
think that the PT *MUST* be different (as opposed to MAY be different; 
it is always permissible to make them different, as long as you have PTs 
enough).

> ...assuming, of course, that there is some other mechanism to find the right m= line, IF needed.

If you have different codec configuration (the stuff like a=fmtp that is 
indexed by PT), I think you MUST use different PTs.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jun 2013 15:35:13 -0400

>> different codec configurations in different m= lines?

Yes, I think so.

> peer also supports the same demuxing technique as yourself?

Muxing/demuxing (in the sense of associating to a particular m-line) 
MUST be consistent on both ends. (The sender knows which m-line he 
associates a packet with, and expects that the receiver will make the 
same association.)

There must be enough signaling to get the two sides in sync about this.

> you expect your peer to support SSRC demuxing and you can't expect that

In this case there will be two m-lines, one audio and one video, each 
using PT 96. And the offer specifies a specific ssrc for each m-line.

If the answerer does't understand or support muxing by ssrc it will then 
note that if it accepted both m-lines it would not be able to associate 
packets with m-lines. So it then has two choices in constructing its answer:

- reject the bundle, but accept both m-lines
- accept the bundle, but reject one of the m-lines.

This works even for hypothetical new demux techniques that might not be 
supported by all.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 19:38:30 +0000

Hi,

> There is something this doesn't address. Suppose I tried to bundle an RTP/AVP with a TCP/RTP/AVP. I could indeed demux them, because they 
> actually travel over different 5-tuples. But I don't think we should consider this bundling.
>
> So, to be bundled, I think at the lowest level they must all share the same transport protocol. But I don't know exactly what terminology to use to say that.

Well, the low level transport protocol is part of the 5-tuple definition, but I agree that it's currently not part of the BUNDLE address definition (where we only talk about the IP address and port).

However, the idea from the beginning has been that a BUNDLE group shares a single 5-tuple, so we need to make sure that is clear.

In the text, however, I use the SDP definition of "transport protocol", which refers to the whole m= line proto value (e.g. "RTP/AVP", etc).

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Jun 2013 12:53:38 -0700

Christer said: 

 
 If you have different codec configuration (the stuff like a=fmtp that is indexed by PT), I think you MUST use different PTs.

[BA] This advice is consistent with examples from RFC 6190 and other documents. For example, RFC 6190 shows different PTs used for an offer including support for both H.264/AVC and H.264/SVC.  
 
However, we need to be a bit careful about how we phrase the requirement, exactly.  I do not consider simulcast and layered streams to represent a "different codec configuration" which would require a different PT for each stream (or even a different SSRC).

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Jun 2013 21:23:39 +0100

On 19 Jun 2013, at 20:18, Harald Alvestrand wrote:
> Using 96 for both Opus and VP8 is flat out illegal according to the RTP specs.

Agree.

> The corner case where we're discussing whether one can use the same payload type is if you have two M-lines that both specify VP8, with the same codec parameters - whether they can both use 96, given that it's the same codec.

Surely yes, but you lose the ability to distinguish the m= line based on the PT if you use the same PT (mapped to the exact same codec and set of codec parameters) in several m= lines. Some applications care about distinguishing m= lines based on PT values, and so need distinct PT values for every m= line; others don't care, and can use the same PT to represent the same codec across multiple m= lines.

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2013 04:47:31 +0000

Hi,

>> Christer said: 
>>
>> Don't you mean the configuration of two codecs? For example, if I have 2 m= lines, with exactly the same H.264 configuration in each, 
>> could I use the same PT value in both m= lines? But, if I have different codec configurations in each m= line, I CANNOT use the same PT value for both?
>>
> However, we need to be a bit careful about how we phrase the requirement, exactly.  I do not consider simulcast and layered streams to represent 
> a "different codec configuration" which would require a different PT for each stream (or even a different SSRC).

My hope is that we, in BUNDLE, don't need to specify how endpoints assign their PT values. 

Of course, if there is some mechanism which requires usage of the same PT value in multiple m= lines, we probably need to say something about that in BUNDLE.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2013 04:53:05 +0000

Hi,

>> Using 96 for both Opus and VP8 is flat out illegal according to the RTP specs.

So, we DO agree that the usage of the *same* PT value (even if in different m= lines) for different codecs, or different codec configurations, is not allowed.

Is there some specific section in some specific RFC that can be referenced to show that?

>> The corner case where we're discussing whether one can use the same payload type is if you have two M-lines that both specify VP8, with 
>> the same codec parameters - whether they can both use 96, given that it's the same codec.
>
> Surely yes, but you lose the ability to distinguish the m= line based on the PT if you use the same PT (mapped to the exact same codec and set of codec parameters) in
> several m= lines. Some applications care about distinguishing m= lines based on PT values, and so need distinct PT values for every m= line; others don't care, and can 
> use the same PT to represent the same codec across multiple m= lines.

Exactly. So, I think it's a good idea to have some text about that in BUNDLE.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2013 05:04:12 +0000

Hi,

>> payload type is if you have two M-lines that both specify VP8, with 
> Well same question then: what would be the downside of only allowing that once support for a non-PT demuxing mechanism has been confirmed?

It for sure seems like a feasible solution, in my opinion.

But, again, at this point I'd like to figure out whether we are going to specify A rule in BUNDLE to begin with, or whether we trust the applications to do the right thing :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2013 05:11:32 +0000

Hi,

>> different codec configurations in different m= lines?

RTP seems to forbid it, though.

> Muxing/demuxing (in the sense of associating to a particular m-line) MUST be consistent on both ends. (The sender knows which m-line he associates a packet with, and expects that the receiver will make the same association.)
>

When it comes to PT values, each endpoint decides which PT values it wants to other endpoint to send.

So, even if Alice uses the same PT value in multiple "m=" lines, and have some way to find the "m=" line when media is received, Bob can still assign unique PT values in each "m=" line.

I don't think there is a requirement to have symmetric PT values in both directions, eventhough I know implementations often do that.

> In this case there will be two m-lines, one audio and one video, each using PT 96. And the offer specifies a specific ssrc for each m-line.
>
> If the answerer does't understand or support muxing by ssrc it will then note that if it accepted both m-lines it would not be able to associate packets with m-lines. So it then has two choices in constructing its answer:
>

Again, my understanding is that the Offerer indicates which PT values it wants to RECEIVE. So, it it assigns the same PT value to both audio and video, it will receive the same PT value in the media packets.

But, the Answerer can indicate different PT values for audio and video in the SDP Answer, and it will receive different PT values in the media packets.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 20 Jun 2013 10:10:27 +0200

On Jun 20, 2013 7:04 AM, "Christer Holmberg" <[email-masked]>
wrote:
> >
> > Well same question then: what would be the downside of only
> > allowing that once support for a non-PT demuxing mechanism has > > been
confirmed?
> But, again, at this point I'd like to figure out whether we are going to
> specify A rule in BUNDLE to begin with, or whether we trust the
> applications to do the right thing :)

I was suggesting (here
http://www.ietf.org/mail-archive/web/mmusic/current/msg11569.html ) that we
adopt PT demuxing and make it the default and MTI mechanism. Others would
of course also be allowed to override it if supported by both sides. This
way SIP UAs wouldn't need  to implement five demuxing techniques to
maximize their chances of successfully negotiating bundle from the first
o/a.

Is there any downside to this?

Emil

-- sent from my mobile

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2013 08:52:17 +0000

Hi,

>>> allowing that once support for a non-PT demuxing mechanism has > > been confirmed?
>>
> I was suggesting (here  http://www.ietf.org/mail-archive/web/mmusic/current/msg11569.html ) that we adopt PT demuxing and make it the default 
> and MTI mechanism. Others would of course also be allowed to override it if supported by both sides. This way SIP UAs wouldn't need  to implement 
> five demuxing techniques to maximize their chances of successfully negotiating bundle from the first o/a.

That could be done for RTP, yes.

Keep in mind, though, that the text in BUNDLE is generic. You could also have multiple m= lines for some other transport protocol, and I don't think we want to start specifying solutions for all of them.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 20 Jun 2013 13:33:09 +0200

Hey Christer,

> Keep in mind, though, that the text in BUNDLE is generic. You could also have multiple m= lines for some other transport protocol, and I don't think we want to start specifying solutions for all of…

Well we'd certainly need RTP demuxing to be discussed somewhere. Given 
that 3264 takes RTP rather "personally", I don't think it would be a bad 
idea to do the same in BUNDLE and at least define one default mechanism 
there.

I agree that BUNDLE is not the right place to define demuxing procedures 
for any possible transport. (One of the main issues being that all 
possible transports have yet to be specified.)

Emil

-- 
https://jitsi.org

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Jun 2013 13:37:05 +0100

> Is there some specific section in some specific RFC that can be referenced to show that?

RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is defined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The BUNDLE defines a single RTP session, which operates under a single RTP profile, so must have a single mapping from Payload Type to Payload Formats. RFC 3551 section 3 says:

   ...
   mechanisms for defining dynamic payload type bindings have been
   specified in the Session Description Protocol (SDP) and in other
   protocols such as ITU-T Recommendation H.323/H.245.  These mechanisms
   associate the registered name of the encoding/payload format, along
   with any additional required parameters, such as the RTP timestamp
   clock rate and number of channels, with a payload type number.  This
   association is effective only for the duration of the RTP session in
   which the dynamic payload type binding is made.  This association
   applies only to the RTP session for which it is made, thus the
   numbers can be re-used for different encodings in different sessions
   so the number space limitation is avoided.

You'll note that the association is per RTP session, not per SSRC or other subset of the session.

If you're looking for a statement that two m= lines in an SDP can't map the same PT value to different things, you're unlikely to find it, since pre-BUNDLE those two m= lines would refer to different RTP sessions, so it would be legal to reuse PT values across m= lines. It's because BUNDLE makes a single RTP session out of several m= lines that you need unique PT mapping across all the m= lines.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2013 13:01:19 +0000

Hi,

> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is defined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The BUNDLE 
> defines a single RTP session, which operates under a single RTP profile, so must have a single mapping from Payload Type to Payload Formats. RFC 3551 section 3 says:
>
>   ...
> If you're looking for a statement that two m= lines in an SDP can't map the same PT value to different things, you're unlikely to find it, since pre-BUNDLE those two m= lines would refer to
> different RTP sessions, so it would be legal to reuse PT values across m= lines. It's because BUNDLE makes a single RTP session out of several m= lines that you need unique PT 
> mapping across all the m= lines.

I agree.

So, unless someone disagrees, BUNDLE can reference the text above, and clarify that the rule applies to the whole BUNDLE group, as it forms a single RTP session.

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2013 13:05:25 +0000

Hi,

>>>> But, again, at this point I'd like to figure out whether we are 
>>>> going to specify A rule in BUNDLE to begin with, or whether we trust 
>>>> the applications to do the right thing :)
>>>
>>> I was suggesting (here  
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11569.html ) 
>>> that we adopt PT demuxing and make it the default and MTI mechanism. Others would of course also be allowed to override it if supported by both sides. This 
>>> way SIP UAs wouldn't need  to implement five demuxing techniques to maximize their chances of successfully negotiating bundle from the first o/a.
> Well we'd certainly need RTP demuxing to be discussed somewhere. Given that 3264 takes RTP rather "personally", I don't think it would be a bad idea to do the same in BUNDLE and at least define one default mechanism there.

I personally have no problem to specify a default mechanism for RTP in BUNDLE, and use the mechanism you suggest. After all, RTP is probably going to be the most common transport protocol using multiple m= lines.

After the weekend, I'll put together a separate RFD (Request For Decision) e-mail for that :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jun 2013 10:32:43 -0400

> You'll note that the association is per RTP session, not per SSRC or other subset of the session.

I'm not inclined to argue the details of RTP with an RTP expert!
But just wearing my standards-lawyer hat I read all of the above 
references, and could not find anything that clearly justified the 
assertions you make. I read them as clearly stating that the *static* 
ones are defined for a profile. I guess the key part of the quote above 
is: "This association is effective only for the duration of the RTP 
session". That seems to *bound* the scope of the association, but 
doesn't explicitly state that it must be unique within that scope.

But maybe that is just a matter of me not reading it right, or of the 
text not having captured every nuance of the intent.

> If you're looking for a statement that two m= lines in an SDP can't map the same PT value to different things, you're unlikely to find it, since pre-BUNDLE those two m= lines would refer to differe…

Of course. So I think that means its important for bundle to clearly 
state the requirement, if it is to be a real one.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jun 2013 10:55:00 -0400

> RTP seems to forbid it, though.

I just commented on that in a separate reply.
I can't find clear text about that.
But if that is the consensus interpretation, then I'm fine with that as 
long as then the bundle spec clearly specifies the implications of that 
on bundle usage.

> I don't think there is a requirement to have symmetric PT values in both directions, eventhough I know implementations often do that.

Yeah, you are right about that. But I don't think it changes the essence 
of what I am saying, at least for PT, since there is no question that 
both sides support the notion of PT.

Specifically, the answerer can look at the offer, and the answer it is 
planning to send, and it can determine if:
- the offerer will be able to associate any packet that might be sent
   to a specific m-line by use of PT alone.
- the answerer will be able to associate any packet it might receive
   to a specific m-line by use of PT alone.

And if it can't, and nothing else has been negotiated to assist in the 
association, then the answer is invalid. So then it will have to revise 
the answer before sending it.

> But, the Answerer can indicate different PT values for audio and video in the SDP Answer, and it will receive different PT values in the media packets.

I think I covered all the PT issues above.

But it may be a little harder than I suggest above to figure out if 
things are ok using ssrc, since a=ssrc only applies to what will be sent.

It works ok for the answerer deciding if he will be able to associate 
received packets to m-lines.

But for the answerer to decide if the offerer will be able to associate 
the packets it receives to m-lines, the answerer will need to know if 
the offerer supports using the ssrc to associate packets to m-lines.

The simplest thing I can suggest for that is that if the offer requires 
using ssrc for demux, then perhaps one can assume that the offerer is 
also prepared to use ssrc to demux on its end. Most of the time that 
would be a no-brainer.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Jun 2013 09:48:08 -0700

> I can't find clear text about that.
[BA] Within the Multiiplexing Guidelines document, Appendix A cover PT multiplexing (see text below): http://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines
However, I do not see any text there addressing the specific issues that are being discussed relating to the BUNDLE document.  IMHO, this is unfortunate. 
> But if that is the consensus interpretation, then I'm fine with that as > long as then the bundle spec clearly specifies the implications of that 
> on bundle usage.
[BA] If in fact there is a consensus, I'd argue that it should be included in the WG consensus document that is supposed to be covering this topic (e.g. the Multiplexing Guidelines document). 
====================
Appendix A.  Dismissing Payload Type Multiplexing

   This section documents a number of reasons why using the payload type
   as a multiplexing point for most things related to multiple streams
   is unsuitable.  If one attempts to use Payload type multiplexing
   beyond it's defined usage, that has well known negative effects on
   RTP.  To use Payload type as the single discriminator for multiple
   streams implies that all the different media streams are being sent
   with the same SSRC, thus using the same timestamp and sequence number
   space.  This has many effects:

   1.   Putting restraint on RTP timestamp rate for the multiplexed
        media.  For example, media streams that use different RTP
        timestamp rates cannot be combined, as the timestamp values need
        to be consistent across all multiplexed media frames.  Thus
        streams are forced to use the same rate.  When this is not
        possible, Payload Type multiplexing cannot be used.

   2.   Many RTP payload formats may fragment a media object over
        multiple packets, like parts of a video frame.  These payload
        formats need to determine the order of the fragments to
        correctly decode them.  Thus it is important to ensure that all
        fragments related to a frame or a similar media object are
        transmitted in sequence and without interruptions within the
        object.  This can relatively simple be solved on the sender side
        by ensuring that the fragments of each media stream are sent in
        sequence.

   3.   Some media formats require uninterrupted sequence number space
        between media parts.  These are media formats where any missing
        RTP sequence number will result in decoding failure or invoking
        of a repair mechanism within a single media context.  The text/
        T140 payload format [RFC4103] is an example of such a format.
        These formats will need a sequence numbering abstraction
        function between RTP and the individual media stream before
        being used with Payload Type multiplexing.

   4.   Sending multiple streams in the same sequence number space makes
        it impossible to determine which Payload Type and thus which
        stream a packet loss relates to.

   5.   If RTP Retransmission [RFC4588] is used and there is a loss, it
        is possible to ask for the missing packet(s) by SSRC and
        sequence number, not by Payload Type.  If only some of the
        Payload Type multiplexed streams are of interest, there is no
        way of telling which missing packet(s) belong to the interesting
        stream(s) and all lost packets must be requested, wasting
        bandwidth.

   6.   The current RTCP feedback mechanisms are built around providing
        feedback on media streams based on stream ID (SSRC), packet
        (sequence numbers) and time interval (RTP Timestamps).  There is
        almost never a field to indicate which Payload Type is reported,
        so sending feedback for a specific media stream is difficult
        without extending existing RTCP reporting.

   7.   The current RTCP media control messages [RFC5104] specification
        is oriented around controlling particular media flows, i.e.
        requests are done addressing a particular SSRC.  Such mechanisms
        would need to be redefined to support Payload Type multiplexing.

   8.   The number of payload types are inherently limited.
        Accordingly, using Payload Type multiplexing limits the number
        of streams that can be multiplexed and does not scale.  This
        limitation is exacerbated if one uses solutions like RTP and
        RTCP multiplexing [RFC5761] where a number of payload types are
        blocked due to the overlap between RTP and RTCP.

   9.   At times, there is a need to group multiplexed streams and this
        is currently possible for RTP Sessions and for SSRC, but there
        is no defined way to group Payload Types.

   10.  It is currently not possible to signal bandwidth requirements
        per media stream when using Payload Type Multiplexing.

   11.  Most existing SDP media level attributes cannot be applied on a
        per Payload Type level and would require re-definition in that
        context.

   12.  A legacy endpoint that doesn't understand the indication that
        different RTP payload types are different media streams may be
        slightly confused by the large amount of possibly overlapping or
        identically defined RTP Payload Types.