Subject: [MMUSIC] RID simplification re: PT

From: Adam Roach <[email-masked]>
Date: Wed, 16 Dec 2015 17:15:35 -0600

Currently, the MMUSIC RID document allows the answerer to pare down (but 
not expand) the list of PTs associated with a RID. As far as I know, 
this behavior was written by analog to the constraints expressed for a 
RID; but the situations aren't actually all that analogous. Indicating 
one or more PTs in a RID line is meant to bind the constraints to the 
payload parameters, rather than constraining the codec behavior (as the 
other RID parameters do).

Based on some hallway conversations in Yokohama, I've heard from some 
implementors that it would be both more sensible and easier to implement 
if the set of PTs associated with a RID were required to be the same in 
the answer as they were in the offer [1].

Can anyone come up with realistic use cases where this would cause issues?

____
[1] Modulo asymmetric PT numbers.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Dec 2015 13:56:05 +0100

> Can anyone come up with realistic use cases where this would cause issues?

Hi,

I participated in a hallway discussion and are fine with the basis for 
the proposal. However, I would like to have a clarification to confirm 
that we have the same understanding. So the PT list for a particular RID 
is immutable between offer and answer with two exceptions. If one 
removes a PT completely, i.e. from the m= line also, then one remove 
them also from all RIDs with that PT value. Further resulting in that 
RIDs which that ends up with no remaining PTs in their PT attribute also 
are removed. The second exception is the one that the answerer may 
renumber PTs between offer and answer.

RID's O/A rules can't prevent the rest of the rules from taking effect. 
Thus, if an answer removes a PT from the m= lines some action needs to 
be taken. If one would use the other alternative of requiring all RIDs 
that has a PT attribute, i.e. not PT=* or absent, to be removed would 
likely result in that an offerer would add a lot of RIDs when it uses 
RIDs that applies to sub-set of the PTs. This simply to fill out the 
combinatorics of what is possible.

Example

Allowing answer reduction for removed PTs uses:

Offer:
m=video 49600 RTP/AVPF 96 97 98 99 100 101
a=rid:A pt=96,97,98 foo=L

Answer (removing 97):
m=video 49600 RTP/AVPF 96 98 99 100 101
a=rid:A pt=96,98 foo=L

Having it truly immutable and wanting to achieve the same for this 
sub-set of PTs:

Offer:
m=video 49600 RTP/AVPF 96 97 98 99 100 101
a=rid:A pt=96,97,98 foo=L
a=rid:B pt=97,98 foo=L
a=rid:C pt=96,98 foo=L
a=rid:D pt=96,97 foo=L
a=rid:E pt=96 foo=L
a=rid:F pt=97 foo=L
a=rid:G pt=98 foo=L

Answer:
m=video 49600 RTP/AVPF 96 98 99 100 101
a=rid:C pt=96,98 foo=L
a=rid:E pt=96 foo=L
a=rid:G pt=98 foo=L

I have a strong preference for the first. I also want to note that this 
is really applicable to usages when the RID applies to a sub-set (of 
more than one) of the PTs. It has no impact when a RID is for all PTs, 
i.e. exclude or pt=*, or when a RID has a single PT.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Dec 2015 10:59:55 -0600

On 12/17/15 06:56, Magnus Westerlund wrote:
> RID's O/A rules can't prevent the rest of the rules from taking 
> effect. Thus, if an answer removes a PT from the m= lines some action 
> needs to be taken. If one would use the other alternative of requiring 
> all RIDs that has a PT attribute, i.e. not PT=* or absent, to be 
> removed would likely result in that an offerer would add a lot of RIDs 
> when it uses RIDs that applies to sub-set of the PTs. This simply to 
> fill out the combinatorics of what is possible.

I agree with your analysis and proposed solution here. Requiring a the 
RID lines to explode combinatorially with PTs would be unwieldy. 
Removing PTs that aren't in the m-line, and changing those that ended up 
being renumbered, seems correct.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 17 Dec 2015 11:31:47 -0800

I am also fine with the proposal, including Magnus's tweak of allowing
removal of PTs via the m= line and removing RIDs that have an empty set of
PTs.

However, having thought about it some more, I think the following rule
would be more simple and suffice those implementers seeking sensibility:
 "If the offer a=rid line contains pt=*, the corresponding answer a=rid
line must contain pt=*".

In other words, if the offer has "pt=A,B", the answer *can* remove A or B
on a per-rid level with "pt=A" or "pt=B", but if an offerer does not want
to support reduction of payload types, it can simply put in "pt=*".​  This
allows more control of a=rid lines in the answer than the originally
proposed rule (in the case where an implementation decides to support pt=
other than pt=*), but it still allows implementations the sensible ease of
putting "pt=*" in the offer and not allowing reduction, but with a more
simple rule.

Would that also work?  Or am I missing something?  If I am and that rule
doesn't work, I still support the original proposal (with Magnus's tweak).

And by the way, does the order of the PTs in a RID line even matter?  What
effect would the answer reordering the PTs even have?

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 17 Dec 2015 14:46:12 -0800

> effect would the answer reordering the PTs even have?

The ordering of the PTs in an rid line shouldn't matter .. Not able to
think where it matters

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Dec 2015 16:58:00 -0600

> The ordering of the PTs in an rid line shouldn't matter .. Not able to 

draft-ietf-mmusic-sdp-simulcast contains text, which casts back to the 
days when it was using PTs instead of RIDs in 'a=simulcast' lines, 
giving meaning to PT order:

>     The order of the format alternatives within a simulcast
>     stream is significant; the alternatives are listed from (left) most
>     preferred to (right) least preferred.  For the use of simulcast, this
>     overrides the normal codec preference as expressed by format type
>     ordering on the "m="-line, using regular SDP rules.  This is to
>     enable a separation of general codec preferences and simulcast stream
>     configuration preferences.

It seems that adding RID as a level of indirection between a=simulcast 
and PT shouldn't remove that capability, right?

If that's true, I think we specify something similar in RID, indicating 
that the order of PTs in 'a=rid:' ranges from most preferred to least 
preferred, probably using language quite similar to that quoted above.

/a

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 17 Dec 2015 23:50:42 +0000

Like Peter, I prefer the simpler rule of only making pt=* immutable. But I can also accept the original proposal.

Regarding order of PTs in a=rid lines, it may be useful to have preferences per RID which differ from the m= line order.

Mo

On Dec 17, 2015, at 5:46 PM, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:

On Thursday, December 17, 2015, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
I am also fine with the proposal, including Magnus's tweak of allowing removal of PTs via the m= line and removing RIDs that have an empty set of PTs.

However, having thought about it some more, I think the following rule would be more simple and suffice those implementers seeking sensibility:  "If the offer a=rid line contains pt=*, the corresponding answer a=rid line must contain pt=*".

In other words, if the offer has "pt=A,B", the answer *can* remove A or B on a per-rid level with "pt=A" or "pt=B", but if an offerer does not want to support reduction of payload types, it can simply put in "pt=*".?  This allows more control of a=rid lines in the answer than the originally proposed rule (in the case where an implementation decides to support pt= other than pt=*), but it still allows implementations the sensible ease of putting "pt=*" in the offer and not allowing reduction, but with a more simple rule.

Would that also work?  Or am I missing something?  If I am and that rule doesn't work, I still support the original proposal (with Magnus's tweak).

And by the way, does the order of the PTs in a RID line even matter?  What effect would the answer reordering the PTs even have?

The ordering of the PTs in an rid line shouldn't matter .. Not able to think where it matters
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Dec 2015 11:05:03 +0100

Hi Peter,

If the offerer includes PT=*, then I think it is reasonable to require 
that to continue to be PT=* in the answer. The reason is that this RID 
is stating that these limitations apply to all Payload Types present in 
the m= section. Changing that to a sub-set of the PTs in the answer 
appears to introduce the complexity I thought was the whole goal here to 
avoid.

If one introduces a RID that has a sub-set of all PTs, then I think it 
is straightforward to remove rejected PTs, that is basic logic in 
contructing messages, and the implication on the offer side when 
receiving the answer is clear. I can't send codec Foo, thus the 
limitations doesn't matter.

If we go with your less restrictive rule, then the offerer has to 
understand what it means on a session level to not get the limitations 
it intended on both A and B codec to only apply to one of them, and the 
other becomes unrestricted in this RID. I personally will not have to 
implement this, but people that has to do, should think about what they 
think becomes most straightforward. I do note that the implementations 
always will have to deal with a RID being refused by the answerer.

So to be clear I don't have a strong preference between these two 
alternatives I can go with either.

Cheers

Magnus

Den 2015-12-17 kl. 20:31, skrev Peter Thatcher:
> removal of PTs via the m= line and removing RIDs that have an empty set
> of PTs.
>
>
> In other words, if the offer has "pt=A,B", the answer *can* remove A or
> B on a per-rid level with "pt=A" or "pt=B", but if an offerer does not
> want to support reduction of payload types, it can simply put in "pt=*".
> ​  This allows more control of a=rid lines in the answer than the
> originally proposed rule (in the case where an implementation decides to
> support pt= other than pt=*), but it still allows implementations the
> sensible ease of putting "pt=*" in the offer and not allowing reduction,
> but with a more simple rule.
>
> And by the way, does the order of the PTs in a RID line even matter?
> What effect would the answer reordering the PTs even have?

-- 

Magnus Westerlund

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 18 Dec 2015 14:10:34 -0800

On Fri, Dec 18, 2015 at 2:05 AM, Magnus Westerlund <
[email-masked]> wrote:

> that to continue to be PT=* in the answer. The reason is that this RID is
> stating that these limitations apply to all Payload Types present in the m=
> section. Changing that to a sub-set of the PTs in the answer appears to
> introduce the complexity I thought was the whole goal here to avoid.

​Right, so a rule of "PT=* offer must be answered PT=*" will avoid the
complexity we're trying to avoid.  ​

> If one introduces a RID that has a sub-set of all PTs, then I think it is
> straightforward to remove rejected PTs, that is basic logic in contructing
> messages, and the implication on the offer side when receiving the answer
> is clear. I can't send codec Foo, thus the limitations doesn't matter.
>

​That's true, which is why I'd be happy with the originally proposed rule,
with your tweak added.  Both rules avoid the complexity we're trying to
avoid.

> understand what it means on a session level to not get the limitations it
> intended on both A and B codec to only apply to one of them, and the other
> becomes unrestricted in this RID. I personally will not have to implement
> this, but people that has to do, should think about what they think becomes
> most straightforward. I do note that the implementations always will have
> to deal with a RID being refused by the answerer.
>
> alternatives I can go with either
> ​.​
>

​I can also.  Both accomplish the same thing.  It's just a question of
which one we want to write down.  And I'm fine with either.​