Subject: [MMUSIC] Offer/Answer PT Questions

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 20 Feb 2016 04:30:12 +0000

Hello O/A lovers,

Section 8.3.2 of RFC 3264 says the following:

   "However, in the case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session.  For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session."

Now, assume the following case:

1.      Alice sends an Offer, with the following PT values:

PT 100: AMR-WB(mode-set=2)
PT 111: AMR-WB(mode-set=2, OA)
PT 0: PCMU

2.      Bob sends the associated Answer:

PT 100: AMR-WB (mode-set=2)
PT 0: PCMU

3.      Later Bob sends the following subsequent Offer:

PT 111: AMR(mode-set=0,2,5,7)

QUESTION 1: Is it allowed for Bob to offer PT 111 for AMR in the subsequent Offer, as Alice used PT 111 for AMR-WG in the initial Offer? In other words, does the pt-value-must-only-refer-to-a-specific-payload-for-the-stream-within-the-session text in section 8.3.2 apply to user A only, or to *all* users within the session?

QUESTION 2:   Assuming the text applies to all users, is it allowed to re-use a PT value for the same codec, but for a different CODEC CONFIGURATION? The text only talks about codec.

Now, I agree that the easiest way to avoid trouble is simply to make sure PT values aren't re-used by any party. But, the text still needs to be clear, because this is causing problems in real deployments.

Regards,

Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Feb 2016 12:16:54 -0500

On 2/19/16 11:30 PM, DOLLY, MARTIN C wrote:
>     “However, in the case of RTP, the mapping from a particular dynamic
> payload type
>
>     or answers for that media stream within the session.”

As you know, this area is not well defined.

> 1.Alice sends an Offer, with the following PT values:
>
> 2.Bob sends the associated Answer:
>

At this point, I think there is an open question of whether the "must 
not change" even applies for a PT that was offered but not accepted in 
the answer.

One might argue that the real point of the requirement is that it can't 
be reused once there might be packets in flight using it. But that isn't 
true in this case. So IMO it is uncharted territory.

> 3.Later Bob sends the following subsequent Offer:
>

You mean the new offer no longer mentions 0 and 100, only 111 with this 
new mapping? (Though I don't think the answer to that affects your 
questions.)

> QUESTION 1: Is it allowed for Bob to offer PT 111 for AMR in the
> subsequent Offer, as Alice used PT 111 for AMR-WG in the initial Offer?
> In other words, does the
> pt-value-must-only-refer-to-a-specific-payload-for-the-stream-within-the-session
> text in section 8.3.2 apply to user A only, or to **all** users within
> the session?

While it is *recommended* that the answer use the same PT as the offer 
for a given codec configuration, that isn't *required*. The answer may 
accept the codec from the offer using a different PT.

So, in the first answer Bob *could* have accepted the offer for 
AMR-WB(mode-set=2, OA) using some other PT (say 112). If so, when Bob 
subsequently sent an offer reusing the same codecs it would have used 
100, 112, and 0. (111 would not have been used.) In that case it seems 
like Bob would be free to use 111 for something else. Alice, in her 
answer, would be free to map it to a different PT in order to avoid a 
clash with 111 on her end.

All of that seems equally applicable in your example, where Bob never 
accepted AMR-WB(mode-set=2, OA).

> QUESTION 2:   Assuming the text applies to all users, is it allowed to
> re-use a PT value for the same codec, but for a different CODEC
> CONFIGURATION? The text only talks about codec.

I think use of "codec" was just sloppy, and that it always meant codec 
configuration.

> Now, I agree that the easiest way to avoid trouble is simply to make
> sure PT values aren’t re-used by any party. But, the text still needs to
> be clear, because this is causing problems in real deployments.

Agree.

The spec is far from clear on this subject. A starting point for 
clarifying it to ascertain as best we can the original intent. But then 
we also need to try to understand common practice. Where this has been 
unclear there may well be conflicting interpretations in the wild. 
*Somebody* is likely to be negatively affected by whatever decision we 
come to.

	Thanks,
	Paul

P.S. Martin: maybe you have found a subject where we can agree.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2016 19:16:33 +0000

Hi,

I had a talk with Martin about this, suggesting we put this in front of the collective wisdom of MMUSIC, so I'll jump in.

>>     "However, in the case of RTP, the mapping from a particular 
>>     dynamic payload type number to a particular codec within that media stream MUST NOT 
>>     change for the duration of a session.  For example, if A generates an offer
> At this point, I think there is an open question of whether the "must not change" even applies for a PT that was offered but not accepted in the answer.

Correct. That is one issue. If it *does* apply, the answerer would have to remember everything that has been offered by the remote endpoint within the session, even if it was not accepted in the answer.

(Now, once could claim that there is no such thing as "accepting" a codec, and that technically the answerer is allowed to send whatever was offered, eventhough it most of the time wouldn't work in reality: endpoint will reserve resources for the codecs both parties indicate support for.)

> One might argue that the real point of the requirement is that it can't be reused once there might be packets in flight using it. But that isn't true in this case. So IMO it is uncharted territory.

And it is not even a special case: offers including more codecs than the corresponding answer is more or less the norm, at least when we take codec configurations into consideration :)

> You mean the new offer no longer mentions 0 and 100, only 111 with this new mapping? (Though I don't think the answer to that affects your
> questions.)

The new offer may have included 0 and 100 too, I don't remember. But, as you say, it does not affect the question. The question is whether Bob can use 111 for something else than Alice previously used it for.

>> pt-value-must-only-refer-to-a-specific-payload-for-the-stream-within-t
>> he-session text in section 8.3.2 apply to user A only, or to **all** 
>> users within the session?
>
> While it is *recommended* that the answer use the same PT as the offer for a given codec configuration, that isn't *required*. The answer may accept the codec from the offer using a different PT.

Assuming Bob is allowed to offer 111, then I assume Alice would not be allowed to answer with 111, as Alice previously offered 111 for something else - eventhough Bob did not "accept" it.

> So, in the first answer Bob *could* have accepted the offer for AMR-WB(mode-set=2, OA) using some other PT (say 112). If so, when 
> Bob subsequently sent an offer reusing the same codecs it would have used 100, 112, and 0. (111 would not have been used.) In that case 
> it seems like Bob would be free to use 111 for something else. Alice, in her answer, would be free to map it to a different PT in order to avoid a clash with 111 on her end.
> 
> All of that seems equally applicable in your example, where Bob never accepted AMR-WB(mode-set=2, OA).

Correct. 

> I think use of "codec" was just sloppy, and that it always meant codec configuration.

I would probably agree with that, but it should be clarified.

>> sure PT values aren't re-used by any party. But, the text still needs 
>> to be clear, because this is causing problems in real deployments.
>
> Agree.
>
> The spec is far from clear on this subject. A starting point for clarifying it to ascertain as best we can the original
> intent. 

What is the original intent? :)

> But then we also need to try to understand common practice. Where this has been unclear there may well 
> be conflicting interpretations in the wild. 
> *Somebody* is likely to be negatively affected by whatever decision we come to.

It is always much easier to get things fixed when the specification is clear on who is wrong and who is right :)

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Feb 2016 14:52:36 -0500

> >>    or answers for that media stream within the session."

One thing that bothered me here is that PT cannot be reused for the
duration of the session. It is probably safe to reuse the PT after session
modification if PT is no longer used. I always felt that dynamic PT reuse
criteria were much stricter then realistically possible or needed.

> not change" even applies for a PT that was offered but not accepted in the
> answer.

I think the most important criteria here is that there should be no
ambiguity regarding how an RTP packet with particular PT should be decoded.
If it is guaranteed that there are no packets sent between Alice and Bob
with PT 111 over some reasonable time interval (couple of network round
trip times), then PT 111 can be safely reused. If, in this scenario Bob's
end point knows that it was not sending anything with payload 111 recently,
then it can safely reuse this payload. Alice could not be sending anything
with payload 111 since Bob did not accept it previously. On the other hand,
Bob must not reuse PT 100 for, let's say, CN, since there are packets with
this payload in flight and this will create decoding ambiguity. To
conclude, an end point should be able to safely reuse any PT that it is not
currently accepting or was not sending or accepting for at least a few
network round trip intervals.

Regards,
______________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2016 15:21:10 -0500

On 2/22/16 2:52 PM, Roman Shpount wrote:

> duration of the session. It is probably safe to reuse the PT after
> session modification if PT is no longer used. I always felt that dynamic
> PT reuse criteria were much stricter then realistically possible or needed.
...
> ambiguity regarding how an RTP packet with particular PT should be
> decoded. If it is guaranteed that there are no packets sent between
> Alice and Bob with PT 111 over some reasonable time interval (couple of
> network round trip times), then PT 111 can be safely reused. If, in this
> scenario Bob's end point knows that it was not sending anything with
> payload 111 recently, then it can safely reuse this payload. Alice could
> not be sending anything with payload 111 since Bob did not accept it
> previously. On the other hand, Bob must not reuse PT 100 for, let's say,
> CN, since there are packets with this payload in flight and this will
> create decoding ambiguity. To conclude, an end point should be able to
> safely reuse any PT that it is not currently accepting or was not
> sending or accepting for at least a few network round trip intervals.

I agree that this is how it *should* be. I don't know if we can change 
this safely or not. It seems likely to me that some implementations 
might be freaked out by this. It is worth discussion.

There are cases where it really isn't feasible to meet the current 
requirement. In particular, when a transfer is done via 3pcc the 
transferee won't know the history of past PT usage. So I expect in cases 
such cases the rule is commonly broken.

Coming up with clear rules for when PTs can be recycled could be a 
challenge.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2016 20:42:28 +0000

Hi,

>> session modification if PT is no longer used. I always felt that 
>> dynamic PT reuse criteria were much stricter then realistically possible or needed.
>...
>> Alice and Bob with PT 111 over some reasonable time interval (couple 
>> of network round trip times), then PT 111 can be safely reused. If, in 
>> this scenario Bob's end point knows that it was not sending anything 
>> with payload 111 recently, then it can safely reuse this payload. 
>> Alice could not be sending anything with payload 111 since Bob did not 
>> accept it previously. On the other hand, Bob must not reuse PT 100 
>> for, let's say, CN, since there are packets with this payload in 
>> flight and this will create decoding ambiguity. To conclude, an end 
>> point should be able to safely reuse any PT that it is not currently 
>> accepting or was not sending or accepting for at least a few network round trip intervals.
>
> I agree that this is how it *should* be. I don't know if we can change this safely or not. It seems likely to me that 
> some implementations might be freaked out by this. It is worth discussion.
>
> There are cases where it really isn't feasible to meet the current requirement. In particular, when a transfer is 
> done via 3pcc the transferee won't know the history of past PT usage. So I expect in cases such cases the rule is commonly broken.
>
> Coming up with clear rules for when PTs can be recycled could be a challenge.

Well, I think we have to try, because these kind of issues keep causing problems.

The fact that something may freak about because we fix it is not a reason for not fixing it :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2016 16:12:27 -0500

> The fact that something may freak about because we fix it is not a reason for not fixing it :)

I would like to see it fixed.

Where there are ambiguities we have to accept that there will be winners 
and losers. (We hopefully aim for more winners than losers.)

It is a little different when there is no ambiguity but we think that 
the spec was excessively stringent. Implementations that were following 
the clear but strict rules have some justification for being miffed if 
we make a change that breaks them.

OTOH, when the current definition breaks a common use case, leading to 
common violation of the spec, then we have good justification for a change.

Bottom line is that any "fix" needs to be thoroughly discussed and 
reviewed. IMO the right place to do that is sipcore. But we need to 
determine if there is support for working on the fix. (You and I and 
Martin constitute some interest.) We *could* take it through dispatch.

Another possibility is to file an errata about it.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2016 16:17:49 -0500

On 2/22/16 4:12 PM, Paul Kyzivat wrote:

> IMO the right place to do that is sipcore.

Duh - that was stupid. Of course MMUSIC is the home of 3264.

	Sorry,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Feb 2016 17:01:55 -0500

> common violation of the spec, then we have good justification for a change.
I think you have mentioned before that 3rd party call control cannot
possibly track all the PT for the session which causes common violation for
the spec. Is this justification enough?
_____________
Roman Shpount

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 22 Feb 2016 22:43:04 +0000

Paul,

I agree with Christer, this needs to be fixed. We are doing interop testing with other carriers for VoIP interconnection, and this is  a major issue.

Fixing this would help accelerate VoIP interconnection.

Regards,

Martin

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, February 22, 2016 3:42 PM
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions

Hi,

>> of network round trip times), then PT 111 can be safely reused. If, 
>> in this scenario Bob's end point knows that it was not sending 
>> anything with payload 111 recently, then it can safely reuse this payload.
>> Alice could not be sending anything with payload 111 since Bob did 
>> not accept it previously. On the other hand, Bob must not reuse PT 
>> 100 for, let's say, CN, since there are packets with this payload in 
> this safely or not. It seems likely to me that some implementations might be freaked out by this. It is worth discussion.
>
> requirement. In particular, when a transfer is done via 3pcc the transferee won't know the history of past PT usage. So I expect in cases such cases the rule is commonly broken.
>

Regards,

Christer

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Feb 2016 18:01:39 -0500

Marin,

Can you provide any more details about how exactly things are failing and
potentially what equipment is affected?

I believe part of the effort in fixing this issue would be trying to
determine who will be negatively affected by the fix and how to minimize
the disruption.
_____________
Roman Shpount

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 22 Feb 2016 23:10:21 +0000

Roman,

My initial email illustrated a failure case.

NDA prevents me from answering the equipment question.

Regards,

Martin

From: Roman Shpount [mailto:[email-masked]]
Sent: Monday, February 22, 2016 6:02 PM
To: DOLLY, MARTIN C <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions

Marin,

Can you provide any more details about how exactly things are failing and potentially what equipment is affected?

I believe part of the effort in fixing this issue would be trying to determine who will be negatively affected by the fix and how to minimize the disruption.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2016 18:21:45 -0500

> I agree with Christer, this needs to be fixed. We are doing interop testing with other carriers for VoIP interconnection, and this is  a major issue.

As I said, I also think fixing this would be a good thing. I'm not the 
chair, so it isn't my call. Key is to round up a critical mass to 
work-on/review this, and flush out any with concerns about such a change.

IMO this will at least require a work item and a draft.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Feb 2016 18:23:27 -0500

> My initial email illustrated a failure case.

What exactly is happening after Bob send a re-INVITE with PT 111:
AMR(mode-set=0,2,5,7)? Do you get an error response back or does some other
failure occurs?

This is understandable. Any information you can provide about how this
issue affects real world deployments would be helpful.

Regards,
_____________
Roman Shpount

---

From: Colin Perkins <[email-masked]>
Date: Tue, 23 Feb 2016 10:29:28 +0000

> On 22 Feb 2016, at 19:52, Roman Shpount <[email-masked]> wrote:
…
> One thing that bothered me here is that PT cannot be reused for the duration of the session. It is probably safe to reuse the PT after session modification if PT is no longer used. I always felt that dynamic PT reuse criteria were much stricter then realistically possible or needed. 
…
> I think the most important criteria here is that there should be no ambiguity regarding how an RTP packet with particular PT should be decoded. If it is guaranteed that there are no packets sent between Alice and Bob with PT 111 over some reasonable time interval (couple of network round trip times), then PT 111 can be safely reused. If, in this scenario Bob's end point knows that it was not sending anything with payload 111 recently, then it can safely reuse this payload. Alice could not be sending anything with payload 111 since Bob did not accept it previously. On the other hand, Bob must not reuse PT 100 for, let's say, CN, since there are packets with this payload in flight and this will create decoding ambiguity. To conclude, an end point should be able to safely reuse any PT that it is not currently accepting or was not sending or accepting for at least a few network round trip intervals.

No objection in principle, but it’s not as simple as “a few network RTTs”:

No ambiguity in decoding means that the packets need to have been played out, so the codec state for that PT can be discarded. Some systems can have large (multi-second) playout buffers. 

Any packets referring to the old PT also need to be gone. Formats like RFC 6354 allow large offsets between streams, referenced by PT (the example in Section 5 has a 5.1 second offset). 

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

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 23 Feb 2016 12:04:12 +0000

I agree that here we are discussing offer / answer, but we must also remember that any rules must be consistent with declarative usages of SDP.

It may also be that some of those declarative rules are also inherited by offer answer, such as the answer to the question as to whether the requirement to remember payload type usage (and whether than applies to both offers and answers, or independently to each).

Regards

Keith

From: mmusic [mailto:[email-masked]] On Behalf Of EXT Colin Perkins
Sent: 23 February 2016 10:29
To: Roman Shpount
Cc: [email-masked]; Paul Kyzivat; Christer Holmberg
Subject: Re: [MMUSIC] Offer/Answer PT Questions

On 22 Feb 2016, at 19:52, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
…

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Feb 2016 12:11:40 +0000

Hi,

>Can you provide any more details about how exactly things are failing and potentially what equipment is affected?

The updated offer is rejected (with a 488 response code, afaik).

>I believe part of the effort in fixing this issue would be trying to determine who will be negatively affected by the fix and how to minimize the disruption.

In this particular case, one part will obviously be “negatively affected” (read: will have to update their code). But, as long as the rules are unclear, and different parties have different opinions on who is right and who it wrong, nobody will update their code. That’s perhaps good for the SBC vendors, because the only solution may be deploying an SBC – just for fixing the PT values(!).

But, in the long term, having clear procedures is good for everyone :)

Regards,

Christer

_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2016 10:37:12 -0500

On 2/23/16 7:04 AM, Drage, Keith (Nokia - GB) wrote:
> I agree that here we are discussing offer / answer, but we must also
> remember that any rules must be consistent with declarative usages of SDP.
>
> It may also be that some of those declarative rules are also inherited
> by offer answer, such as the answer to the question as to whether the
> requirement to remember payload type usage (and whether than applies to
> both offers and answers, or independently to each).

I don't understand your point. ISTM that none of this discussion is 
relevant to declarative usage - why should there ever be any need to 
retain history or remain consistent with it in the declarative case?

	Thanks,
	Paul

> Regards
>
> Keith
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *EXT Colin
> Perkins
> *Sent:* 23 February 2016 10:29
> *To:* Roman Shpount
> *Cc:* [email-masked]; Paul Kyzivat; Christer Holmberg
> *Subject:* Re: [MMUSIC] Offer/Answer PT Questions
>
> No ambiguity in decoding means that the packets need to have been played
> out, so the codec state for that PT can be discarded. Some systems can
> have large (multi-second) playout buffers.
>
> Any packets referring to the old PT also need to be gone. Formats
> like RFC 6354 allow large offsets between streams, referenced by PT (the
> example in Section 5 has a 5.1 second offset).
>
> --
>
> Colin Perkins
>
> https://csperkins.org/
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2016 10:44:40 -0500

> example in Section 5 has a 5.1 second offset).

Thanks for the insight. It helps to ground the discussion.

I'm also interested in hearing if there might be *other* reasons behind 
the rules as they are written.

The advantage of the current rule is that it is easy to explain, and is 
sufficient to deal with the problem you describe above. Unfortunately it 
is also difficult/impossible to comply with in some cases. If we are to 
replace it, we need to find something else to replace it with.

Would it be possible to instead make a rule that a PT can't be reused 
until there are no active streams using it? (That any that were 
initiated have been terminated.) Note: I don't know RTP well enough to 
be confident that this even makes sense.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 23 Feb 2016 10:25:09 -0600

Jumping in on one point:

On 22 Feb 2016, at 15:12, Paul Kyzivat wrote:

[...]

>From the conversation so far, this doesn't seem like errata material to me.

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Feb 2016 18:04:19 +0000

Hi,

>> No ambiguity in decoding means that the packets need to have been 
>> played out, so the codec state for that PT can be discarded. Some 
>> systems can have large (multi-second) playout buffers.
>>
>> Any packets referring to the old PT also need to be gone. Formats like 
>> RFC 6354 allow large offsets between streams, referenced by PT (the 
> I'm also interested in hearing if there might be *other* reasons behind the rules as they are written.
>
> The advantage of the current rule is that it is easy to explain, and is sufficient to deal with the problem you describe 
> above. Unfortunately it is also difficult/impossible to comply with in some cases. If we are to replace it, we need to find 
> something else to replace it with.

The current rule may be easy to understand, but it's difficult to understand - and that's what triggered this discussion :)

So, while we can discuss possible rules/guidelines on when a PT value can be used, I still think we need to answer the first question:

- If Alice allocates PT=X for codec 1, is Bob allowed to allocate PT=X for codec 2 within the same session? The current text is unclear on that, and I think that is the first question we need to sort out.

After that, we can discuss whether e.g. Alice at some point can allocate PT=X for codec 3, and what the criteria for that is.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Feb 2016 13:22:04 -0500

On Tue, Feb 23, 2016 at 1:04 PM, Christer Holmberg <
[email-masked]> wrote:

> The current rule may be easy to understand, but it's difficult to
> understand - and that's what triggered this discussion :)
>
> So, while we can discuss possible rules/guidelines on when a PT value can
> be used, I still think we need to answer the first question:
>
> - If Alice allocates PT=X for codec 1, is Bob allowed to allocate PT=X for
> codec 2 within the same session? The current text is unclear on that, and I
> think that is the first question we need to sort out.
>
> After that, we can discuss whether e.g. Alice at some point can allocate
> PT=X for codec 3, and what the criteria for that is.
>

As far as I can see there are 3 question/clarifications that are required:

1. PT is allocated per codec profile (codec and all associated parameters),
not codec. For instance, if end point uses PT=100 for SILK/8000, it cannot
reuse it for SILK/16000

2. Is PT blocked from each direction independently or both directions at
the same time. For instance if A sent an offer with PT=100, but B never
sent an offer or an answer with PT=100, can B sent an offer with PT=100?

3. PT reuse in sessions such as one triggered by 3pcc where it would be
impossible to enforce PT from ever being reused.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2016 14:01:55 -0500

On 2/23/16 1:22 PM, Roman Shpount wrote:
> On Tue, Feb 23, 2016 at 1:04 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     So, while we can discuss possible rules/guidelines on when a PT
>     value can be used, I still think we need to answer the first question:
>
>     - If Alice allocates PT=X for codec 1, is Bob allowed to allocate
>     PT=X for codec 2 within the same session? The current text is
>     unclear on that, and I think that is the first question we need to
>     sort out.
>
>     After that, we can discuss whether e.g. Alice at some point can
>     allocate PT=X for codec 3, and what the criteria for that is.
>
>
> 1. PT is allocated per codec profile (codec and all associated
> parameters), not codec. For instance, if end point uses PT=100 for
> SILK/8000, it cannot reuse it for SILK/16000
>

Note that in general the 3pcc case has other issues besides PT reuse. It 
is only "simple" if we assume that everybody is using only a single 
audio session. If we get beyond that there is the matter of matching the 
number of m-lines and their media types.

So it may be that we should separate it from the others.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 23 Feb 2016 13:40:11 -0600

>> From the conversation so far, this doesn't seem like errata material 

Oops, messed up the quotes. The sentence starting with "From the 
converation..." was mine.

Ben.

---

From: "Makaraju, Raju (Nokia - US)" <[email-masked]>
Date: Mon, 22 Feb 2016 23:29:24 +0000

+1 for fixing it to allow unambigous payload reuse.

Thanks Christer, for bringing it up.

BR

Raju

------ Original message------

From: DOLLY, MARTIN C

Date: Mon, Feb 22, 2016 4:43 PM

To: Christer Holmberg;Paul Kyzivat;[email-masked];

Subject:Re: [MMUSIC] Offer/Answer PT Questions

Paul,

Regards,

Martin

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, February 22, 2016 3:42 PM
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions

Hi,

Regards,

Christer

---

From: Colin Perkins <[email-masked]>
Date: Wed, 24 Feb 2016 10:37:59 +0000

> On 23 Feb 2016, at 18:04, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

RFC 3551 (the RTP/AVP profile), section 3, top of page 7, 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.

I always interpreted that as RTP payload types being per RTP session, not per SSRC. That may, or may not, be consistent with the SDP specifications.

Colin

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 11:08:39 +0000

Hi Colin,

>>>> like RFC 6354 allow large offsets between streams, referenced by PT 
>>>> (the example in Section 5 has a 5.1 second offset).
>>> 
>>> The advantage of the current rule is that it is easy to explain, and 
>>> is sufficient to deal with the problem you describe above. 
>>> Unfortunately it is also difficult/impossible to comply with in some cases. If we are to replace it, we need to find something else to replace it with.
>> 
>> - If Alice allocates PT=X for codec 1, is Bob allowed to allocate PT=X for codec 2 within the same session? The current 
>> text is unclear on that, and I think that is the first question we need to sort out.
>

Q1: Then my next question is: when is the BINDING created? Is a binding created once a user has indicated (in an offer or answer) a PT/codec mapping - no matter if the other endpoint will use the same codec to begin with, or PT value for that codec?

Example #1:
----------------

Alice offers:

PT 100: (AMR-WB)
PT 111: (VP8)

Bob answers:

PT 111: (VP8)

Q2: Now, eventhough did not indicate support of AMR-WR, the BINDING between PT 100 and AMR-WR has still been created, and neither Alice or Bob is allowed to re-use PT 100 for anything else within the session?

Example #2:
----------------

Alice offers:

PT 100: (AMR-WB)

Bob answers:

PT 111: (AMR-WB)

Q3: Now, two bindings have been created: one binding between PT 100 and AMR-WB, and one binding between PT 111 and AMR-WB. After this, neither Alice or Bob is allowed to re-use PT 100 or PT 111 for anything else within the session?

Q4: HOWEVER, even if Bob indicated PT 111 and AMR-WB, I assume Bob would still be allowed to indicate PT 100 and AMR-WB, as it does not conflict with the existing binding?

Regards,

Christer

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 24 Feb 2016 12:15:29 -0500

> impossible to enforce PT from ever being reused.

Thanks for writing a clear list of the issues!  I think it is important
that we provide a formal clarification of these points, as they've been
discussed again and again, though people have a general consensus on
the correct answers.

My understanding is that the answer to 1 has always been understood to
be that the PT identifies the entire codec profile.

My understanding is that the answer to 2 has always been understood to
be that the PT number spaces in each direction are independent.  For
instance, RFC 3264 section 5.1 notes

      Different payload type numbers may be needed in each direction
      because of interoperability concerns with H.323.

My understanding is that PT reuse has always been formally forbidden but
that implementations should tolerate PT reuse by the other endpoint and
should process reused PTs "as you'd expect" as long as all packets
containing the old use of the PT were gone from "the system" before the
reuse is specified.  And it has been understood that this limitation is
not well defined.

Personally, I'd like to see a clean solution to this problem, as I had
to wrestle with it when I wrote RFC 7088 section 2.8 (music-on-hold),
which discusses the problem.

One amelioration is that the sender uses the PTs specified in the SDP
that was sent to it by the receiver, and that SDP also includes the
address to which the RTP is to be sent.  So in simple cases, as long as
the sender updates the PTs it is sending at the same time as it updates
the destination address of the RTP, then the receiver can never be
confused regarding the meaning of PTs it receives. -- Any packets using
the old PT definition have been sent to a different address.

This may break down if there is an RTP gateway in the middle, and while
the ultimate destination of the RTP is different, the sender is always
given the same destination address in the rewritten SDP that it is sent.
But such a gateway has problems knowing which destination to forward the
RTP to.

What do people at sip-implementors say about this?

Dale

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Feb 2016 12:27:22 -0500

>       because of interoperability concerns with H.323.
Based on this, the answer to original question is that if

This offer should be accepted. PT is each direction is independent and Bob
is allowed to reuse it.

The complication here is that Alice will not be allowed to reuse PT 111
for AMR(mode-set=0,2,5,7) in the answer. Alice will need to pick a
different PT for AMR(mode-set=0,2,5,7), if it is supported and end points
will use asymmetric payload types.

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Feb 2016 12:35:14 -0500

> What do people at sip-implementors say about this?

Speaking with an implementer hat on, based on the interop that I have
conducted for audio based networks, most of them ignore the MUST NOT reuse
PT rule. You routinely see PT changed or reused.

To deal with this, if implementation is robust remote address change, SSRC
change, or payload type change causes codec re-initialization based on the
codec parameters in the latest SDP send by this end point. Such change is
triggered by the packets after the jitter buffer, so all the packets using
the previous codec profile for the particular PT should be processed and
out of the system. If any of those packet do arrive late, they will be
discarded either by jitter buffer as late packets or based on some sort of
probation counter which starts on unexpected SSRC, remote address, or
payload change.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 12:55:41 -0500

Christer,

See inline.

> Q1: Then my next question is: when is the BINDING created? Is a binding created once a user has indicated (in an offer or answer) a PT/codec mapping - no matter if the other endpoint will use the s…

I agree this is an important question.

The way 3264 was written it seems to mostly imply that the O/A is 
*negotiating* two-way usage of codecs rather than *declaring* 
independent usage of codecs in each direction. That made sense for a 
long time when usage focused on single stream audio.

But it sometimes seems to waffle on that and subsequently, IIUC, has 
been interpreted to be more flexible than that. This has become much 
more important with multi-stream usage, such as webrtc and clue.

I have the impression that initially it was expected that the same PT 
would be used on both ends. Later that got clarified so that the 
answerer can use a different PT than the offerer for the same codec 
configuration. With that, I think it is necessary that the PT reuse rule 
be applied independently on each end.

In your questions below I'm assuming sendrecv applies to all the 
m-lines. (the other cases need to be analyzed separately.)

> Example #1:

As noted above, I think bindings must be managed independently for each 
end. PT 100 is locked in on Alice's end, because Bob is allowed to send 
to it even though he didn't mention it in the answer. Alice can't use it 
for some other codec because Bob might have packets in flight that could 
then be misunderstood by Alice.

But Alice is forbidden from sending PT 111 to Bob. So if Bob 
subsequently offers PT 111 with some other coded and Alice starts 
sending to it there can be no ambiguity about what is being received. So 
it seems ok to allow *that*.

> Example #2:

As I noted above, I think it must be the case that the bindings are 
managed independently on each end.

> Q4: HOWEVER, even if Bob indicated PT 111 and AMR-WB, I assume Bob would still be allowed to indicate PT 100 and AMR-WB, as it does not conflict with the existing binding?

Yes. It is explicitly allowed (I forget where) to map the same codec 
config to more than one PT (on the same end). (It isn't clear to me 
*why* one would do that.)

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 24 Feb 2016 22:13:44 +0000

In declarative usage a session still exists (it is still the session description protocol, and the session announcement protocol) and therefore there must be a set of rules for the reuse or non-reuse of payload types. 

All I am saying is that we must not get carried way and defined a set of rules that are inconsistent between the two. Rather one should be a subset of the other.

Keith

-----Original Message-----
From: EXT Paul Kyzivat [mailto:[email-masked]] 
Sent: 23 February 2016 15:37
To: Drage, Keith (Nokia - GB); EXT Colin Perkins; Roman Shpount
Cc: [email-masked]; Christer Holmberg
Subject: Re: [MMUSIC] Offer/Answer PT Questions

On 2/23/16 7:04 AM, Drage, Keith (Nokia - GB) wrote:
> requirement to remember payload type usage (and whether than applies 
> to both offers and answers, or independently to each).

I don't understand your point. ISTM that none of this discussion is relevant to declarative usage - why should there ever be any need to retain history or remain consistent with it in the declarative case?

	Thanks,
	Paul

> Regards
>
> Keith
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *EXT 
> Colin Perkins

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 17:54:06 -0500

> All I am saying is that we must not get carried way and defined a set of rules that are inconsistent between the two. Rather one should be a subset of the other.

I have never tried to understand the declarative use (other than in 
OPTIONS, which clearly *isn't* describing a session.) It is my 
impression that SAP hasn't been used for a very long time.

If somebody who understands and cares about it would like to help then 
maybe we can see that we don't break that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 10:06:06 +0000

Hi Roman,

> This offer should be accepted. PT is each direction is independent and Bob is allowed to reuse it.

Not necessarily. Even if PT is per direction is allowed as such, we still need to clarify whether the same PT/codec binding is per direction, or whether it applies to the whole session. 

> The complication here is that Alice will not be allowed to reuse PT 111 for AMR(mode-set=0,2,5,7) in the answer. Alice will need to pick a
> different PT for AMR(mode-set=0,2,5,7), if it is supported and end points will use asymmetric payload types.

So, you are saying that Alice is not allowed to reuse a PT value that Alice has previously used for another PT/codec binding - no matter if Bob supported the codec or not?

For example: assume Alice offered PT 111: VP8, but Bob did not include VP8 in the answer. Then Bob offers PT 111:AMR. Now, Alice is not allowed to use PT 111 for AMR, since Alice previously used it for VP8.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 09:12:08 +0000

Hi,

I have to say that I don't understand the connection with declarative use either.

First, declarative use is not a negotiation - there is no offer and answer.

Second, if I send a declarative SDP now, and a second one later, there are no rules saying that the second one has to be dependent on the first one. The number of m- lines can be different, properties associated with the m- lines can be different, PT/codec mappings can be different. Etc etc etc etc.

We are not trying to change the basic SDP semantics - we are trying to clarify the semantics and rules associated with Offer/Answer.

Regards,

Christer 

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 25 February 2016 00:54
To: [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions

> All I am saying is that we must not get carried way and defined a set of rules that are inconsistent between the two. Rather one should be a subset of the other.

I have never tried to understand the declarative use (other than in OPTIONS, which clearly *isn't* describing a session.) It is my impression that SAP hasn't been used for a very long time.

If somebody who understands and cares about it would like to help then maybe we can see that we don't break that.

	Thanks,
	Paul

>> It may also be that some of those declarative rules are also 
>> inherited by offer answer, such as the answer to the question as to 
>> whether the requirement to remember payload type usage (and whether 
>> than applies to both offers and answers, or independently to each).
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Feb 2016 14:19:51 -0500

On Thu, Feb 25, 2016 at 5:06 AM, Christer Holmberg <
[email-masked]> wrote:

> Not necessarily. Even if PT is per direction is allowed as such, we still
> need to clarify whether the same PT/codec binding is per direction, or
> whether it applies to the whole session.
>

Yes, this needs to be clarified, but general consensus is that each
direction is independent.

> > different PT for AMR(mode-set=0,2,5,7), if it is supported and end
> points will use asymmetric payload types.
>
> So, you are saying that Alice is not allowed to reuse a PT value that
> Alice has previously used for another PT/codec binding - no matter if Bob
> supported the codec or not?
>
> For example: assume Alice offered PT 111: VP8, but Bob did not include VP8
> in the answer. Then Bob offers PT 111:AMR. Now, Alice is not allowed to use
> PT 111 for AMR, since Alice previously used it for VP8.
>

This is exactly what I am saying. The fact that Bob did not include VP8 in
the answer does not mean it is not sending VP8 to Alice. Because of this
Alice is not allowed to use PT 111 for AMR since there can be VP8 media in
flight with PT 111.

What I am trying to highlight here that if an end point is reusing a PT
which was used in one direction only, it is forcing asymmetric PT
assignment. This, of cause, breaks the SHOULD from section 6.1 in RFC 3264:

In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer.

Regards,
_____________
Roman Shpount