Subject: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Jun 2013 11:34:09 +0000

Hi,

Emil suggested that the default, "MTI", mechanism for mapping RTP data to m- lines should be based on PT. Applications are allowed to use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mechanisms).

Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data to m- lines?

Q4: If Q3, do we mandate applications to support, and use (unless applications are made aware of other mechanisms supported by all endpoints) PT for mapping received RTP media?

This means that, when mapping RTP to m- lines is required (whether it is always mandated is discussed in another thread), within a BUNDLE group each PT value must be unique to an individual m- line.

NOTE: If your answer to Q3 is "yes", but your answer to Q4 is "no", please indicate which mechanism you prefer :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Tue, 25 Jun 2013 19:03:01 +0200

On 25.06.13, 13:34, Christer Holmberg wrote:
> Hi,
>
> Emil suggested that the default, “MTI”, mechanism for mapping RTP data
> to m- lines should be based on PT.

Actually, what I thought was important was having it as the "default" 
mechanism. Personally I don't mind having it as MTI might but it might 
be a tad too strong: implementations that deem PT demux insufficient and 
wouldn't want to use bundle without it, don't need implement it.

We should probably also agree on how an answerer can determine whether 
or not it is expected to provide additional demuxing information (e.g. 
SSRCs) or if the offerer is using the default mechanism.

One way would be for the answerer to inspect all m= lines and try to 
detect duplicating PTs. This could be a bit clumsy though. The offerer 
could expect SSRCs but its first offer may not yet contain PT reuse.

With that in mind ... (more below)

> Applications are allowed to use
> whatever other mechanisms, but usage of such mechanisms must be
> negotiated (or, applications need to have some other means knowing that
> the other endpoint support such mechanisms).
>
> *Q3*: Do we need to specify a default, MTI, mechanism for mapping RTP
> data to m- lines?

I am in favour of having a "default" one.

Without this BUNDLE would have to be an abstract spec and I don't see 
why we would want to leave it that way.

> *Q4*: If Q3, do we mandate applications to support, and use (unless
> applications are made aware of other mechanisms supported by all
> endpoints) PT for mapping received RTP media?

In favour.

Cheers,
Emil

>
> This means that, when mapping RTP to m- lines is required (whether it is
> always mandated is discussed in another thread), within a BUNDLE group
> each PT value must be unique to an individual m- line.
>
> NOTE: If your answer to Q3 is “yes”, but your answer to Q4 is “no”,
> please indicate which mechanism you prefer J
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Jun 2013 10:11:20 -0700

Agree with Emil that "default" makes more sense for use of PT for mapping to an m line. If a=SSRC is specified on an m line then that should take precedence over PT.

On Jun 25, 2013, at 10:03 AM, "Emil Ivov" <[email-masked]> wrote:

> Actually, what I thought was important was having it as the "default" mechanism. Personally I don't mind having it as MTI might but it might be a tad too strong: implementations that deem PT demux insufficient and wouldn't want to use bundle without it, don't need implement it.
> 
> We should probably also agree on how an answerer can determine whether or not it is expected to provide additional demuxing information (e.g. SSRCs) or if the offerer is using the default mechanism.
> 
> One way would be for the answerer to inspect all m= lines and try to detect duplicating PTs. This could be a bit clumsy though. The offerer could expect SSRCs but its first offer may not yet contain PT reuse.
> 
> Without this BUNDLE would have to be an abstract spec and I don't see why we would want to leave it that way.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 13:26:50 -0400

I guess if you want to call this a "default" MTI mechanism *for RTP*, 
then I won't object. But doing so is mostly stating the obvious.

The reason it can be the default is because there is no way to have an 
RTP m-line without a PT. So if you are bundling RTP m-lines, then you 
have PT available on every m-line to use for associating packets with 
m-lines.

But that is only sufficient if a given PT only appears on a single 
m-line. Its also insufficient if there are non-RTP m-lines.

If you choose to have non-RTP m-lines in the bundle, or multiple RTP 
m-lines with the same PT, then you are obligated to support some other 
mechanism, and for it to be signaled in such a way that both sides will 
understand what it is.

	Thanks,
	Paul

On 6/25/13 7:34 AM, Christer Holmberg wrote:
> to m- lines should be based on PT. Applications are allowed to use

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 13:43:58 -0400

> Agree with Emil that "default" makes more sense for use of PT for mapping to an m line. If a=SSRC is specified on an m line then that should take precedence over PT.

I don't think "takes precedence" is quite the right way to think about it.

You support some number of mechanisms: PT only, or PT & SSRC, or ...

For the set of mechanisms you support, for each m-line you have some 
values for some of the mechanisms. When you receive a packet, attempt to 
match it to each m-line based on the the values it contains and those 
specified for each m-line. If a packet matches more than one m-line, 
then choose the m-line that matches the most values. If that still 
matches multiple m-lines, then there is an error.

You can statically analyze an offer and a candidate answer and determine 
if there can be any non-unique matches. If so, then you should not send 
that answer. Instead, send one that is more unique, or else reject some 
of the m-lines, or refuse to bundle some of them.

You can also statically analyze the O/A and determine a precedence for 
applying the mechanisms that minimizes the checking required for doing 
the matching. When using PT & SSRC, depending on the details it may be 
favorable to check one or the other first.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Jun 2013 07:25:01 +0200

On 06/25/2013 01:34 PM, Christer Holmberg wrote:
>
> Hi,
>
> Emil suggested that the default, "MTI", mechanism for mapping RTP data 
> negotiated (or, applications need to have some other means knowing 
> that the other endpoint support such mechanisms).
>

No. This makes the assumption that all applications have the need to map 
RTP data to m-lines; this assumption is not proven (and probably cannot 
be - it's hard to prove a negative. It might be possible to disprove it, 
though).

> endpoints) PT for mapping received RTP media?

If the WG disagrees with me on Q3, it might as well go down this path. I 
have no strong opinion.

> This means that, when mapping RTP to m- lines is required (whether it 
> is always mandated is discussed in another thread), within a BUNDLE 
> group each PT value must be unique to an individual m- line.
>
> NOTE: If your answer to Q3 is "yes", but your answer to Q4 is "no",

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Jun 2013 07:05:02 +0000

Hi,

> Agree with Emil that "default" makes more sense for use of PT for mapping to an m line. If a=SSRC is specified on an m line then that should take precedence over PT.

Sure, but a=SSRC would be "whatever other mechanism" :)

The question is, though, how much BUNDLE should talk about "other mechanisms".

Regards,

Christer

>> Emil suggested that the default, “MTI”, mechanism for mapping RTP 
>> data to m- lines should be based on PT.
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Jun 2013 07:11:38 +0000

Hi,

> I guess if you want to call this a "default" MTI mechanism *for RTP*, then I won't object.

Yes, I should have clarified that it was for RTP.

> But doing so is mostly stating the obvious.

We should be careful to make such assumptions :)

> The reason it can be the default is because there is no way to have an RTP m-line without a PT. So if you are bundling RTP m-lines, then you have PT available on every m-line to use for associating packets with m-lines.
>
> But that is only sufficient if a given PT only appears on a single m-line. 

Correct, and I think it is good to point that out, eventhough it may seem obvious to many.

> Its also insufficient if there are non-RTP m-lines.
>
> If you choose to have non-RTP m-lines in the bundle, or multiple RTP m-lines with the same PT, then you are obligated to support some other 
> mechanism, and for it to be signaled in such a way that both sides will understand what it is.

The mechanism to find the right "type" of m- line is a separate issue :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Jun 2013 07:14:40 +0000

Hi Harald,

Just for my clarification: Assuming we are talking about applications using RTP (instead of ANY BUNDLE application), is your answer to Q3 still "no"?

In other words, do you think there might be RTP cases where it is not needed to associate the RTP data with an m- line?

OR, do you think that BUNDLE simply shouldn't say anything about how to map RTP packets to m- lines?

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 26. kesäkuuta 2013 8:25
To: [email-masked]
Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?

No. This makes the assumption that all applications have the need to map RTP data to m-lines; this assumption is not proven (and probably cannot be - it's hard to prove a negative. It might be possible to disprove it, though).

If the WG disagrees with me on Q3, it might as well go down this path. I have no strong opinion.

Regards,

Christer

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Jun 2013 07:25:34 +0000

Hi,

> For the set of mechanisms you support, for each m-line you have some values for some of the mechanisms. When you receive a packet, attempt to match it 
> to each m-line based on the the values it contains and those specified for each m-line. If a packet matches more than one m-line, then choose the m-line '
> that matches the most values. If that still matches multiple m-lines, then there is an error.
>
> You can statically analyze an offer and a candidate answer and determine if there can be any non-unique matches. If so, then you should not send 
> that answer. Instead, send one that is more unique, or else reject some of the m-lines, or refuse to bundle some of them.
>
> You can also statically analyze the O/A and determine a precedence for applying the mechanisms that minimizes the checking required for doing the matching. 
> When using PT & SSRC, depending on the details it may be favorable to check one or the other first.

I don't think we should specify which mechanism "takes precedence". My suggestion is to define the "default" one, and then people can use whatever other mechanisms if they want. One question is whether we should even mention other mechanisms.

(If BUNDLE would, for RTP, mandate the usage of a=ssrc, we could of course also specify that as "default", but currently BUNDLE does not mandate the usage of a=ssrc).

Regards,

Christer

>>> *Q3*: Do we need to specify a default, MTI, mechanism for mapping 
>>> RTP data to m- lines?
>>
>>> This means that, when mapping RTP to m- lines is required (whether 
>>> it is always mandated is discussed in another thread), within a 
>>> BUNDLE group each PT value must be unique to an individual m- line.
>>>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 26 Jun 2013 11:23:04 +0100

On 25 Jun 2013, at 12:34, Christer Holmberg wrote:
> Hi,
>  
> Emil suggested that the default, “MTI”, mechanism for mapping RTP data to m- lines should be based on PT. Applications are allowed to use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mechanisms).
>  

I think the BUNDLE specification needs to define how RTP flows can be associated with m= lines, but ought not mandate that applications do so. The document that describes how WebRTC uses BUNDLE might want to mandate that WebRTC applications use the mechanism. 

> Q4: If Q3, do we mandate applications to support, and use (unless applications are made aware of other mechanisms supported by all endpoints) PT for mapping received RTP media?

I think we should specify how the combination of PT values and a=ssrc: lines can be used to associate RTP data with m= lines, for applications that want to do so. 

I don't think just using PT values is sufficient, since the PT space is small (I can imagine applications that want to send lots of flows using the same codec configuration, and it's more natural to give them all the same PT and use a=ssrc: lines to distinguish).

> NOTE: If your answer to Q3 is “yes”, but your answer to Q4 is “no”, please indicate which mechanism you prefer J
>  
> Regards,
>  
> Christer

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Jun 2013 13:37:46 +0200

I am on vacation now, so short answer:

Apps that use m-lines for rtp session negotiation and not for stream control need no such association.

If we mandate such association, we load those apps with extra luggage.

Christer Holmberg <[email-masked]> wrote:

>Hi Harald,
>
>Just for my clarification: Assuming we are talking about applications
>using RTP (instead of ANY BUNDLE application), is your answer to Q3
>still "no"?
>
>In other words, do you think there might be RTP cases where it is not
>needed to associate the RTP data with an m- line?
>
>No. This makes the assumption that all applications have the need to
>map RTP data to m-lines; this assumption is not proven (and probably
>cannot be - it's hard to prove a negative. It might be possible to
>disprove it, though).
>
>
>
>Q4: If Q3, do we mandate applications to support, and use (unless
>please indicate which mechanism you prefer :)
>
>Regards,
>
>Christer
>
>
>
>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Jun 2013 12:20:13 +0000

Hi Colin,

>> Emil suggested that the default, "MTI", mechanism for mapping RTP data to m- lines should be based on PT. Applications are 
>> allowed to use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have 
>> some other means knowing that the other endpoint support such mechanisms).
>> 
> I think the BUNDLE specification needs to define how RTP flows can be associated with m= lines, but ought not mandate that applications 
> do so. The document that describes how WebRTC uses BUNDLE might want to mandate that WebRTC applications use the mechanism. 

Note that there is a separate discussion, BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?, on whether BUNDLE shall mandate that the receiver must always be able to map received data to an m- line.

So far only Paul has commented on that discussion, but I assume it's just a question of hours before your input will be posted? :)

> I don't think just using PT values is sufficient, since the PT space is small (I can imagine applications that want to send lots of flows using 
> the same codec configuration, and it's more natural to give them all the same PT and use a=ssrc: lines to distinguish).

If you run out of PTs, and have to re-use the same PT in multiple m- lines (for the same codec configuration, though), you will obviously need something else for mapping RTP to m- lines, and we should probably state that.

But, my take from your reply is that you don't think we should specify a default mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc), but it would be up to applications to decide what to use. Correct?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jun 2013 10:16:55 -0400

> I am on vacation now, so short answer:

You don't keep working while on vacation? :-)

> If we mandate such association, we load those apps with extra luggage.

I still don't understand. If the m-lines are only used for session 
negotiation and not stream control then there is no need for multiple 
m-lines.

And note that what is being proposed is only that there be enough 
information available so that the association is *possible*. It isn't a 
requirement that the association actually be *done*. (But I don't see a 
case where it wouldn't be needed.)

Are you thinking of the case where there is just a bundle of one audio 
and one video m-line, because that is necessary in order to define the 
PTs for both audio and video? If so, then if the PTs are unique for the 
two m-lines, as they must be for it to work, then it is indeed possible 
to associate each packet with the proper m-line.

	Thanks,
	Paul

>     Just for my clarification: Assuming we are talking about
>     applications using RTP (instead of ANY BUNDLE application), is your
>     answer to Q3 still “no”?
>
>     In other words, do you think there might be RTP cases where it is
>     not needed to associate the RTP data with an m- line?
>
>     OR, do you think that BUNDLE simply shouldn’t say anything about how
>     to map RTP packets to m- lines?
>
>     Regards,
>
>     Christer
>
>     *From:[email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Harald Alvestrand
>     *Sent:* 26. kesäkuuta 2013 8:25
>     *To:* [email-masked]
>     *Subject:* Re: [MMUSIC] DECISION: Default mechanism to map RTP data
>     to m- line is based on PT?
>
>         Emil suggested that the default, “MTI”, mechanism for mapping
>         RTP data to m- lines should be based on PT. Applications are
>         allowed to use whatever other mechanisms, but usage of such
>         mechanisms must be negotiated (or, applications need to have
>         *Q3*: Do we need to specify a default, MTI, mechanism for
>         mapping RTP data to m- lines?
>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Colin Perkins <[email-masked]>
Date: Sat, 29 Jun 2013 13:44:42 +0100

> But, my take from your reply is that you don't think we should specify a default mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc), but it would be up to applications to decide what…

No. 

Specifying a "default" suggests that there might be alternative ways of doing this. If we specify an algorithm for mapping RTP flows to m= lines, we should specify a single algorithm. We don't need multiple ways of doing this. I think that single algorithm should look at the PT and the a=ssrc: lines. Just looking at the PT isn't sufficient.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Jun 2013 11:44:52 -0400

> Specifying a "default" suggests that there might be alternative ways of doing this. If we specify an algorithm for mapping RTP flows to m= lines, we should specify a single algorithm. We don't need…

But we *will* have alternative ways of doing this:

- one way is by SSRC, specifying which SSRC goes to which m-line

- another way could be by appid (from Roni's new draft)

The only thing that is special about PT is that *every* RTP media 
section contains PTs, so it is always available to be used.

If I want to use appid, I may very well *not* want to use ssrc as well. 
I may want the same ssrc to associate with *different* m-lines in the 
bundle depending on which appid it has.

And in that case I may well not want to use PT either.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Jun 2013 16:57:59 +0000

Hi,

>>>> Emil suggested that the default, "MTI", mechanism for mapping RTP 
>>>> data to m- lines should be based on PT. Applications are allowed to 
>>>> use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mechanisms).
>>>>  
>>> I think the BUNDLE specification needs to define how RTP flows can be 
>>> associated with m= lines, but ought not mandate that applications do so. The document that describes how WebRTC uses BUNDLE might want to mandate that WebRTC applications use the mechanism.
>> 
>> So far only Paul has commented on that discussion, but I assume it's 
>> just a question of hours before your input will be posted? :)
>> 
>>> I don't think just using PT values is sufficient, since the PT space 
>>> is small (I can imagine applications that want to send lots of flows using the same codec configuration, and it's more natural to give them all the same PT and use a=ssrc: lines to distinguish).
>> 
> Specifying a "default" suggests that there might be alternative ways of doing this. If we specify an algorithm for mapping RTP flows to m= lines, we should specify a single
> algorithm. We don't need multiple ways of doing this. I think that single algorithm should look at the PT and the a=ssrc: lines. Just looking at the PT isn't sufficient.

But, what if there is no a=ssrc? Are you suggesting we shall mandate usage of a=ssrc in case of multiple RTP m- lines in a BUNDLE group?

As Paul says in his reply, there may be different mechanisms which can be used (and in future there might be even more). You seem to suggest that BUNDLE shall say "Mechanism X is the only mechanism for mapping RTP media to m- lines". Or?

Regards,

Christer

---

From: Colin Perkins <[email-masked]>
Date: Sun, 30 Jun 2013 18:04:54 +0100

> But, what if there is no a=ssrc? Are you suggesting we shall mandate usage of a=ssrc in case of multiple RTP m- lines in a BUNDLE group?

No, I'm saying that we should define a single algorithm for mapping the RTP flows to m= lines. That algorithm should take into account a=ssrc: lines, if present, as well as payload type mapping.

> As Paul says in his reply, there may be different mechanisms which can be used (and in future there might be even more). You seem to suggest that BUNDLE shall say "Mechanism X is the only mechanism…

I'm suggesting we specify something tractable: one algorithm, if at all possible. I'm unconvinced that too much flexibility is a good thing here.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Jun 2013 17:10:15 +0000

Hi,

>>>>>> data to m- lines should be based on PT. Applications are allowed 
>>>>>> to use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mechanisms).
>>>>>> 
>>>>> I think the BUNDLE specification needs to define how RTP flows can 
>>>>> be associated with m= lines, but ought not mandate that applications do so. The document that describes how WebRTC uses BUNDLE might want to mandate that WebRTC applications use the mechanism.
>>>> 
>>>>> I don't think just using PT values is sufficient, since the PT 
>>>>> space is small (I can imagine applications that want to send lots of flows using the same codec configuration, and it's more natural to give them all the same PT and use a=ssrc: lines to distinguish).
>>>> 
>>> Specifying a "default" suggests that there might be alternative ways 
>>> of doing this. If we specify an algorithm for mapping RTP flows to m= lines, we should specify a single algorithm. We don't need multiple ways of doing this. I think that single algorithm should look at the PT and the a=ssrc: lines. Just looking at the PT isn't sufficient.
>> 

Ok, so you want to have explicit text about usage of a=ssrc, if present. But, I still don't think we should forbid usage of other mechanisms, eventhough we won't describe them in the BUNDLE spec.

Regards,

Christer