Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

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

Hi,

I put together some text:

"The scope of a mapping from a particular dynamic payload type number to a codec 
(or codec configuration) is for a given RTP media flow direction within a session. 
The same dynamic payload type number can be mapped to another codec in another RTP 
media flow direction within the same session. The mapping MUST NOT change to a different
coded (or coded configuration) for the duration of a session. Eventhough not recommended, 
for a given direction, multiple dynamic payload type numbers can be mapped to the 
same codec (or codec configuration). 

Note that a mapping has been created once an endpoint
has sent and offer or answer, describing the mapping for a given direction. Even if the
offer or answer is rejected or discarded, or if RTP media associated with the mapping is never
sent, the mapping MUST NOT change for the given direction within the session.

Within an offer or answer, the mapping is for the RTP media flow direction towards the offerer/answerer,
unless the media flow is indicated as 'sendonly' in which case the mapping is for the media flow direction
from the offerer/answerer."

Note that the text probably needs some fine tuning, but please take a look and see whether you are ok with the approach, and whether you think the text covers the issues we've discovered.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 14:29:13 +0000

And, just to clarify: the idea is that this text would update the existing text in 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." 

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 25 February 2016 16:17
To: [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

Hi,

"The scope of a mapping from a particular dynamic payload type number to a codec (or codec configuration) is for a given RTP media flow direction within a session. 
The same dynamic payload type number can be mapped to another codec in another RTP media flow direction within the same session. The mapping MUST NOT change to a different coded (or coded configuration) for the duration of a session. Eventhough not recommended, for a given direction, multiple dynamic payload type numbers can be mapped to the same codec (or codec configuration). 

Note that a mapping has been created once an endpoint has sent and offer or answer, describing the mapping for a given direction. Even if the offer or answer is rejected or discarded, or if RTP media associated with the mapping is never sent, the mapping MUST NOT change for the given direction within the session.

Within an offer or answer, the mapping is for the RTP media flow direction towards the offerer/answerer, unless the media flow is indicated as 'sendonly' in which case the mapping is for the media flow direction from the offerer/answerer."

Regards,

Christer

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

---

From: "Schwarz, Albrecht (Nokia - DE)" <[email-masked]>
Date: Thu, 25 Feb 2016 14:45:13 +0000

Comment to used RTP terminology:
Should be tightly coupled to RFC 7656 in my understanding. We got know an agreed RTP terminology with that RFC.
Replacements in text:
=> "session" = "RTP session" (RFC 7656, § 2.2.2)
=> "media stream" = "(media) source stream" (RFC 7656, § 2.1.5) ???

With regards to notion "RTP media flow direction":
= "RTP media flow" is identified by the 2-tuple {SSRC, PT}, i.e. represents a subflow component of an "RTP stream" (given by SSRC; RFC 7656, § 2.1.10)
If this is the aimed semantic of an RTP media flow, then attribute "direction" might be obsolete because an "RTP stream" is inherently unidirectional (from RTP source towards RTP sink).

Regards,
Albrecht

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 25 February 2016 16:17
To: [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

Hi,

Regards,

Christer

---

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

Hi Albrecht,

Thanks for the input. We also need to look at what terminology is used elsewhere in 3264. I didn't check that when writing the text.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Nokia - DE) [mailto:[email-masked]] 
Sent: 25 February 2016 16:45
To: Christer Holmberg <[email-masked]>; [email-masked]
Subject: RE: [MMUSIC] Offer/Answer PT Questions - text proposal

Comment to used RTP terminology:
Should be tightly coupled to RFC 7656 in my understanding. We got know an agreed RTP terminology with that RFC.
Replacements in text:
=> "session" = "RTP session" (RFC 7656, § 2.2.2) => "media stream" = "(media) source stream" (RFC 7656, § 2.1.5) ???

With regards to notion "RTP media flow direction":
= "RTP media flow" is identified by the 2-tuple {SSRC, PT}, i.e. represents a subflow component of an "RTP stream" (given by SSRC; RFC 7656, § 2.1.10) If this is the aimed semantic of an RTP media flow, then attribute "direction" might be obsolete because an "RTP stream" is inherently unidirectional (from RTP source towards RTP sink).

Regards,
Albrecht

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 25 February 2016 16:17
To: [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2016 12:37:29 -0500

> (or codec configuration) is for a given RTP media flow direction within a session.

Albrecht raised the question of terminology and of whether "RTP media 
flow direction" is the right term. I think the concept is specific to 
O/A. In 7656 terms I think it applies to all RTP streams with a 
particular PT flowing in a single direction between two participants in 
one RTP Session.

> sent, the mapping MUST NOT change for the given direction within the session.

The paragraph above seems overly strict. Surely it should not be 
necessary to retain the mapping if the entire offer is rejected. (There 
isn't any way to reject an answer.)

Similarly, if the m-line is rejected (port zero) ISTM that all bindings 
could be forgotten. (I guess in this case the RTP Session ends so 
"within the session" covers it.)

> from the offerer/answerer."

ISTM that no bindings should be created for sendonly m-lines. (AFAIK the 
PT mentioned in a sendonly offer/answer never appears on the wire in 
RTP/RTCP.)

OTOH, as a session is modified (by additional O/As), bindings need to be 
retained even if sendonly is sometimes used.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Feb 2016 13:12:11 -0500

> same codec (or codec configuration).

I think MUST NOT is too strict for this rule and SHOULD NOT should be
sufficient. In current implementation this rule is often ignored. The worst
thing that can happen is a small media disruption, but with the careful
implementation, even that will not occur in most use cases.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 18:23:34 +0000

Hi,

> I think MUST NOT is too strict for this rule and SHOULD NOT should be sufficient. In current implementation this 
> rule is often ignored. The worst thing that can happen is a small media disruption, but with the careful 

There may also be implementations that DO implement the rule. SHOULD NOT means that endpoints have to be prepared to handle it.

Is there really a reason why we should allow it? 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 18:32:37 +0000

Hi,

>> "The scope of a mapping from a particular dynamic payload type number 
>> to a codec (or codec configuration) is for a given RTP media flow direction within a session.
>
> Albrecht raised the question of terminology and of whether "RTP media flow direction" is the right term. I think the concept
> is specific to O/A. In 7656 terms I think it applies to all RTP streams with a particular PT flowing in a single direction between 
> two participants in one RTP Session.

We need to look whether there is existing terminology in 3264, in which case we should use that (or update every instance of the terminology within 3264...)

>> The same dynamic payload type number can be mapped to another codec in 
>> another RTP media flow direction within the same session. The mapping 
>> MUST NOT change to a different coded (or coded configuration) for the 
>> duration of a session. Eventhough not recommended, for a given 
>> direction, multiple dynamic payload type numbers can be mapped to the same codec (or codec configuration).
>>
>> Note that a mapping has been created once an endpoint has sent and 
>> offer or answer, describing the mapping for a given direction. Even if 
>> the offer or answer is rejected or discarded, or if RTP media 
>> associated with the mapping is never sent, the mapping MUST NOT change for the given direction within the session.
>
> The paragraph above seems overly strict. Surely it should not be necessary to retain the mapping if the entire offer is rejected. (There isn't any way to reject an answer.)

Sometimes strict is good :) But, I'm not religious about it, as long as the text is clear on when the mapping has been created.

> Similarly, if the m-line is rejected (port zero) ISTM that all bindings could be forgotten. (I guess in this case the RTP Session ends so "within the session" covers it.)

What if an m- line is disabled, using port zero in an *offer*, and later taken back in use? Are the previous mappings still valid? In my opinion they are.

>> Within an offer or answer, the mapping is for the RTP media flow 
>> direction towards the offerer/answerer, unless the media flow is 
>> indicated as 'sendonly' in which case the mapping is for the media flow direction from the offerer/answerer."
>
> ISTM that no bindings should be created for sendonly m-lines. (AFAIK the PT mentioned in a sendonly offer/answer never appears on the wire in
> RTP/RTCP.)

So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply with PT 111:PCMU? Both are associated with the same media flow direction, as the offer was sendonly.

Regards,

Christer

OTOH, as a session is modified (by additional O/As), bindings need to be retained even if sendonly is sometimes used.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Feb 2016 13:41:35 -0500

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

> another RTP
> sufficient. In current implementation this
> There may also be implementations that DO implement the rule. SHOULD NOT
> means that endpoints have to be prepared to handle it.
>

I guess what I am trying to say is these implementations really should not
be enforcing this rule. There is no technical reason for strict enforcement
and this will break things during the interop.

> Is there really a reason why we should allow it?

It is impossible to implement 3pcc with this rule in place.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Feb 2016 13:45:03 -0500

On Thu, Feb 25, 2016 at 1:32 PM, Christer Holmberg <
[email-masked]> wrote:

> So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply
> with PT 111:PCMU? Both are associated with the same media flow direction,
> as the offer was sendonly.
>

These PT are not associated with the same flow direction. Each end point
lists PTs it is willing to receive. The end point which is sending the
sendonly offer has no idea what the other end point is willing to receive
and their PT preferences. The PT in sendonly are in the direction to
sendonly end point, They are simply placeholders and will not be used.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 18:50:15 +0000

Hi,

> I guess what I am trying to say is these implementations really should not be enforcing this rule. There is no technical reason for strict enforcement and this will break things during the interop.
>

In that case, maybe should allow it ONLY when an endpoint does not have any knowledge about the mappings, and give 3pcc as an example.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 18:51:43 +0000

Hi,

>> So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply with PT 111:PCMU? Both are associated
>> with the same media flow direction, as the offer was sendonly.
>
> These PT are not associated with the same flow direction. Each end point lists PTs it is willing to receive. The end
> point which is sending the sendonly offer has no idea what the other end point is willing to receive and their PT 
> preferences. The PT in sendonly are in the direction to sendonly end point, They are simply placeholders and will not be used. 

If so, we should either explicitly specify it, or reference to where it is already specified.

Regards,

Christer

---

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

On Thu, Feb 25, 2016 at 1:51 PM, Christer Holmberg <
[email-masked]> wrote:

> >> So, I send you a sendonly offer with PT 111:VP8, it is ok for you to
> reply with PT 111:PCMU? Both are associated
> lists PTs it is willing to receive. The end
> > preferences. The PT in sendonly are in the direction to sendonly end
> point, They are simply placeholders and will not be used.
>

We will probably need to clarify how asymmetric PT in each direction work
with offer/answer. There is a lot of confusion regarding this issue as well.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2016 15:51:16 -0500

On 2/25/16 2:06 PM, Roman Shpount wrote:
> On Thu, Feb 25, 2016 at 1:51 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> We will probably need to clarify how asymmetric PT in each direction
> work with offer/answer. There is a lot of confusion regarding this issue
> as well.

I agree it would be a good idea to do that.

	Thanks,
	Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 25 Feb 2016 21:02:58 +0000

> On Feb 25, 2016, at 12:51 PM, Paul Kyzivat <[email-masked]> wrote:
> 

I do as well.

-G

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2016 16:07:59 -0500

> We need to look whether there is existing terminology in 3264, in which case we should use that (or update every instance of the terminology within 3264...)

Sounds good.

> Sometimes strict is good :) But, I'm not religious about it, as long as the text is clear on when the mapping has been created.

I agree about being clear. IMO we should try not to impose unnecessary 
restrictions. But if being a little stricter than necessary greatly 
simplifies the rules then it is worth considering.

> What if an m- line is disabled, using port zero in an *offer*, and later taken back in use? Are the previous mappings still valid? In my opinion they are.

Once you have used port zero the RTP session is *gone*. If you then 
recycle the m-line with a valid addr/port you are establishing a *new* 
RTP session, so the old bindings are gone and you start building a new set.

> So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply with PT 111:PCMU? Both are associated with the same media flow direction, as the offer was sendonly.

The following from 3264 applies in this case:

    For streams marked as recvonly in the answer, the "m=" line MUST
    contain at least one media format the answerer is willing to receive
    with from amongst those listed in the offer.  The stream MAY indicate
    additional media formats, not listed in the corresponding stream in
    the offer, that the answerer is willing to receive.

So if you *only* offered PT 111:VP8, then the answer MUST include VP8. 
(Preferably with PT 111, but it could be some other PT.) It could *also* 
include PCMU. So PT 110:VP8, PT 111:PCMU would be valid.

If I can't accept VP8, then I guess I have to either reject the m-line 
or else reject the offer.

IMO the MUST is too restrictive. It ought to be SHOULD. But changing 
that is a separate issue.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 25 Feb 2016 23:19:15 +0000

Hi,

> On 25 Feb 2016, at 14:17, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

I think this conflicts with various RTP-related RFCs and drafts, although whether this conflict causes practical problems is unclear. RFC 3551 indicates that the binding between RTP payload type and RTP payload format is per RTP session, not per sender within an RTP session:

   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.

(note: reuse in different sessions, not different participants within a session) and:

   Session participants agree through mechanisms beyond the scope of
   this specification on the set of payload types allowed in a given
   session. 

which is again, agree the set of PTs for a session, not per participant.

RFC 3550 is unclear, and defers to RFC 3551, but suggests the payload type mapping is per RTP session:

   RTP media type: An RTP media type is the collection of payload
      types which can be carried within a single RTP session.  The RTP
      Profile assigns RTP media types to RTP payload types.

draft-ietf-avtcore-multi-media-rtp-session-13 (currently in the RFC Editor queue) says, in Section 7:

   Establishing a single RTP session using multiple media types requires
   signalling.  This signalling has to:

   1.  ensure that any participant in the RTP session is aware that this
       is an RTP session with multiple media types;

   2.  ensure that the payload types in use in the RTP session are using
       unique values, with no overlap between the media types;

draft-ietf-rtcweb-rtp-usage-25 says, in section 4.3:

   A single RTP payload type number MUST NOT be assigned to different
   RTP payload formats, or different configurations of the same RTP
   payload format, within a single RTP session (note that the "m=" lines
   in an SDP bundle group [I-D.ietf-mmusic-sdp-bundle-negotiation] form
   a single RTP session).

Finally, the allowable RTP payload type numbers depend on the RTCP packet types used in the session, since use of certain RTCP packet types prevents use of some RTP payload types when RTP and RTCP multiplexing is used. The allowable RTCP packet types are signalled per RTP session, also suggesting that the mapping is per session. 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2016 18:53:36 -0500

> (note: reuse in different sessions, not different participants within a session) and:

Does a sendrecv m-line established via O/A create one or two RTP sessions?

If one, then it seems this conflicts with 3264 allowing the two ends to 
use different PTs for the same codec configuration.

It always seemed to me that the original intent was to require the same 
PT number on both ends (perhaps because of what you quote), and that 
allowing the two ends to be different was an afterthought. If so, it may 
be that rfc3551 should have been updated.

Is there any *technical* difficulty when the two ends use different PTs? 
(E.g. does it screw up rtcp reports?)

We are starting to get to the meat of the issue. The question is: what 
needs to be fixed?

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Feb 2016 09:39:43 +0000

> On 25 Feb 2016, at 23:53, Paul Kyzivat <[email-masked]> wrote:
> 

One, since RTP sessions are defined by shared SSRC space, not directionality of media.

> If one, then it seems this conflicts with 3264 allowing the two ends to use different PTs for the same codec configuration.

That depends exactly what 3264 allows: if the two ends use different payload types to refer to the same codec, that’s okay; but if the two ends use the same payload type to refer to different codecs, that problematic.

> It always seemed to me that the original intent was to require the same PT number on both ends (perhaps because of what you quote), and that allowing the two ends to be different was an afterthought. If so, it may be that rfc3551 should have been updated.
> 
> Is there any *technical* difficulty when the two ends use different PTs? (E.g. does it screw up rtcp reports?)

Using different payload types to refer to the same codec is wasteful, but not harmful.

Allowing different senders to use the same payload type to refer to different codecs is problematic. It makes the payload type to codec mapping depend on the SSRC, but SSRCs can change without signalling. 

> We are starting to get to the meat of the issue. The question is: what needs to be fixed?
> 
> 	Thanks,
> 	Paul
> 

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Feb 2016 10:17:50 +0000

Hi,

>>>> "The scope of a mapping from a particular dynamic payload type 
>>>> number to a codec (or codec configuration) is for a given RTP media flow direction within a session.
>>> 
>>> I think this conflicts with various RTP-related RFCs and drafts, although whether this conflict causes practical 
>>> problems is unclear. RFC 3551 indicates that the binding between RTP payload type and RTP payload format is per 
>>> RTP session, not per sender within an RTP session:
>>> 

> That depends exactly what 3264 allows: if the two ends use different payload types to refer to the same codec, that’s okay; but if 
> the two ends use the same payload type to refer to different codecs, that problematic.

From a 3264 perspective, "use" doesn't automatically mean that the PT is ever sent on the wire - it only means that a PT/codec mapping has been indicated in an offer or answer.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2016 10:53:24 -0500

Colin,

Thanks for the clarifications. My knowledge of RTP is scant. (I'm 
gradually learning through osmosis.)

More inline.

> One, since RTP sessions are defined by shared SSRC space, not directionality of media.

OK. I thought that would be the answer, but was just checking.

> That depends exactly what 3264 allows: if the two ends use different payload types to refer to the same codec, that’s okay; but if the two ends use the same payload type to refer to different codec…

OK. That helps clarify what needs to be done.

So it means that we have to say that the appearance of a PT in an offer 
or answer binds it to the corresponding codec configuration for the 
duration of the RTP session. An answerer can still choose to use a 
different PT for the same codec configuration. But he can't use a PT 
that has already been bound.

Can we require a sender to honor the preference of the recipient in this 
regard? (For two-participant sessions - the kind we are usually setting 
up with O/A.)

But an important point to this is that this binding is scoped by the RTP 
session, not the SIP (or O/A) session. So when the RTP session changes 
(because the addr/port changes at one of the ends) then old bindings no 
longer need to be preserved.

And *that* solves the 3pcc problem, since in the 3pcc cases that matter 
the RTP session will change.

As a side question, how do the predefined PTs fit into this? My guess is 
that the predefined PTs are *not* implicitly bound. They still must be 
bound by appearing in an offer or answer. And then they are only bound 
to their default codec configuration if there is no explicit rtpmap for 
the PT.

ISTM this is starting to be clarified. But I think it is going to take 
quite a bit of careful writing to properly specify this.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Feb 2016 16:04:08 +0000

> On 26 Feb 2016, at 15:53, Paul Kyzivat <[email-masked]> wrote:
> 
> Colin,
> 
> Thanks for the clarifications. My knowledge of RTP is scant. (I'm gradually learning through osmosis.)
> 
> More inline.
> 
> So it means that we have to say that the appearance of a PT in an offer or answer binds it to the corresponding codec configuration for the duration of the RTP session. An answerer can still choose to use a different PT for the same codec configuration. But he can’t use a PT that has already been bound.

Yes.

> Can we require a sender to honor the preference of the recipient in this regard? (For two-participant sessions - the kind we are usually setting up with O/A.)

That’s one for the signalling to decide.

> But an important point to this is that this binding is scoped by the RTP session, not the SIP (or O/A) session. So when the RTP session changes (because the addr/port changes at one of the ends) then old bindings no longer need to be preserved.
> 
> And *that* solves the 3pcc problem, since in the 3pcc cases that matter the RTP session will change.

Perhaps, but remember that an RTP session is defined by a shared SSRC space, not by the addresses or ports used, so it depends how 3PCC moves the addresses. 

> As a side question, how do the predefined PTs fit into this? My guess is that the predefined PTs are *not* implicitly bound. They still must be bound by appearing in an offer or answer. And then they are only bound to their default codec configuration if there is no explicit rtpmap for the PT.

The use is defined by the signalled RTP profile. If an RTP/AVP-derived profile is used, the text in RFC 3551 applies:

   This profile reserves payload type numbers in the range 96-127
   exclusively for dynamic assignment.  Applications SHOULD first use
   values in this range for dynamic payload types.  Those applications
   which need to define more than 32 dynamic payload types MAY bind
   codes below 96, in which case it is RECOMMENDED that unassigned
   payload type numbers be used first.  However, the statically assigned
   payload types are default bindings and MAY be dynamically bound to
   new encodings if needed.  Redefining payload types below 96 may cause
   incorrect operation if an attempt is made to join a session without
   obtaining session description information that defines the dynamic
   payload types.

i.e., the fact that the m= line says RTP/AVP implies that the default static payload type mappings are valid, unless over-ridden by an a=rtpmap: line.

> ISTM this is starting to be clarified. But I think it is going to take quite a bit of careful writing to properly specify this.

Right.

Cheers,
Colin

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2016 11:28:25 -0500

> That’s one for the signalling to decide.

Would it be ok for us to say that a sender of RTP in a RTP session 
established using O/A MUST only use bindings specified in the most 
recent offer or answer from that recipient?

> Perhaps, but remember that an RTP session is defined by a shared SSRC space, not by the addresses or ports used, so it depends how 3PCC moves the addresses.

OK. Then we need more words. ISTM that at least for unicast O/A, each 
time an addr/port changes we establish a new SSRC space.

There might be exceptions to this. For instance a mixer in a star 
configuration. In principle that could be used to bring another 
participant into a preexisting RTP session. But the only way I can see 
that could work in practice is for the mixer to send the first offer, 
and to enumerate all of the existing PT mappings. And of course the new 
participant won't be aware of existing SSRCs in use either.

Again, I think this is going to be hard to specify. A *lot* more needs 
to be said than is currently in 3264.

(And multicast O/A is a whole separate question. I don't even want to 
*think* about that right now.)

> i.e., the fact that the m= line says RTP/AVP implies that the default static payload type mappings are valid, unless over-ridden by an a=rtpmap: line.

I *think* what you said confirms what I was guessing.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Feb 2016 12:04:02 -0500

On Fri, Feb 26, 2016 at 11:28 AM, Paul Kyzivat <[email-masked]>
wrote:

> established using O/A MUST only use bindings specified in the most recent
> offer or answer from that recipient?

Unfortunately this is not that simple. For instance if end point sends an
offer but have not received the answer. It does not know if the offer is
accepted yet, so it does not know if old RTP or new RTP session is used.

Another complication is that offer/answer does not always establishes a new
RTP session. For instance, when SIP session timer is used with INVITE,
INVITE with the same SDP as the latest SDP sent by this end point is often
sent and the same answer as before is received. In this case same SSRCs are
reused and RTP typically flows unaffected.

The rules that I follow in my implementations (and this might only work for
audio/video) are as follows:

1. Any offer sent by an end point is compatible with the last accepted
offer/answer. This offer is reusing the same PT for the same codec profiles
from the offer/answer exchange. If there are two PT for the same codec
profile, local PT is used for this codec profile. Any codec profile added
is not using any PT from the last offer/answer exchange.

2. Any answer is generated to use the same PT as the offer received, even
if they conflict

3. Whenever SSRC or PT changes, new jitter buffer is started. This jitter
buffer has a probation period which validates that several valid packet are
received in sequence. Once packets in jitter buffer are validated, new
codec instance is initialized based on the combination of the last
negotiated offer/answer and, if exists, the outstanding offer. There are
some extra provisions to provide smooth switch over from playback of
existing RTP stream to the new one.

This obviously disregards the MUST NOT reuse PT rule, but is quite robust
and works well in practice.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Feb 2016 12:06:57 -0500

On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins <[email-masked]> wrote:

> That depends exactly what 3264 allows: if the two ends use different
> payload types to refer to the same codec, that’s okay; but if the two ends
> use the same payload type to refer to different codecs, that problematic.
>

Why is using the same PT to refer to different codecs is problematic? Can
you point out any potential problems that this will cause from RTP
perspective?

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2016 12:20:34 -0500

On 2/26/16 12:04 PM, Roman Shpount wrote:
> On Fri, Feb 26, 2016 at 11:28 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Unfortunately this is not that simple. For instance if end point sends
> an offer but have not received the answer. It does not know if the offer
> is accepted yet, so it does not know if old RTP or new RTP session is used.

Yes. But it is using the PTs specified by the *other* end, not its own 
end. And those can be used as soon as received. It doesn't matter if an 
offer it has send was accepted. If it has sent a new offer, but not yet 
received an answer to it, then what I proposed means it is still sending 
in accord to the last offer/answer that it *received*.

(This may need some tweaking to deal with what to do *after* a re-offer 
has been sent and rejected.)

> Another complication is that offer/answer does not always establishes a
> new RTP session. For instance, when SIP session timer is used with
> INVITE, INVITE with the same SDP as the latest SDP sent by this end
> point is often sent and the same answer as before is received. In this
> case same SSRCs are reused and RTP typically flows unaffected.

The session remains, and so the PT bindings remain. But the O/A rules 
are negotiating which of those are to be used going forward. If the new 
offer no longer mentions some PTs that were previously bound, then it is 
saying that it doesn't want to receive them any more.

It is becoming clear to me that it will be necessary to define PT 
bindings - what they are, when they are established, when they are 
forgotten, and the scope within which they live. Each participant will 
need to know these bindings, and they must agree on them, except for 
well defined signaling delays. I guess this is a lot like an RTP 
session, except that it is tied to O/A signaling.

	Thanks,
	Paul

> The rules that I follow in my implementations (and this might only work
> for audio/video) are as follows:
>
> offer/answer. This offer is reusing the same PT for the same codec
> profiles from the offer/answer exchange. If there are two PT for the
> same codec profile, local PT is used for this codec profile. Any codec
> profile added is not using any PT from the last offer/answer exchange.
>
> 2. Any answer is generated to use the same PT as the offer received,
> even if they conflict
>
> 3. Whenever SSRC or PT changes, new jitter buffer is started. This
> jitter buffer has a probation period which validates that several valid
> packet are received in sequence. Once packets in jitter buffer are
> validated, new codec instance is initialized based on the combination of
> the last negotiated offer/answer and, if exists, the outstanding offer.
> There are some extra provisions to provide smooth switch over from
> playback of existing RTP stream to the new one.
>
> This obviously disregards the MUST NOT reuse PT rule, but is quite
> robust and works well in practice.
>
> Regards,
> _____________
> Roman Shpount

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Feb 2016 17:34:18 +0000

> On 26 Feb 2016, at 17:06, Roman Shpount <[email-masked]> wrote:
> 
> On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> Why is using the same PT to refer to different codecs is problematic? Can you point out any potential problems that this will cause from RTP perspective?

If I receive a packet with payload type X, how do I know which of the codecs it refers to?

You’d have to make the PT mapping per SSRC, but the SSRCs can change without signalling, so that doesn’t help unless you somehow label the RTP stream with a header extension that says what payload type space it’s using. 

The entire point of the PT is that it uniquely identifies a codec configuration.

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Feb 2016 12:40:30 -0500

On Fri, Feb 26, 2016 at 12:34 PM, Colin Perkins <[email-masked]> wrote:

> You’d have to make the PT mapping per SSRC, but the SSRCs can change
> without signalling, so that doesn’t help unless you somehow label the RTP
> stream with a header extension that says what payload type space it’s
> using.
>

Why does PT needs to be unique in both directions (entire RTP session) vs
unique in each direction? Having a unique PT in each direction is enough to
unambiguously decode the packet. SSRC might change but the packet flow
direction is well known when the packet is received.

P.S. I am, of cause, talking about unicast sessions only.
_____________
Roman Shpount

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Feb 2016 17:42:15 +0000

> On 26 Feb 2016, at 17:40, Roman Shpount <[email-masked]> wrote:
> 
> On Fri, Feb 26, 2016 at 12:34 PM, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 26 Feb 2016, at 17:06, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Why does PT needs to be unique in both directions (entire RTP session) vs unique in each direction? Having a unique PT in each direction is enough to unambiguously decode the packet. SSRC might change but the packet flow direction is well known when the packet is received.

Because there might be more than one participant in the session.

> P.S. I am, of cause, talking about unicast sessions only.

So am I. Unicast != only two participants. 

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Feb 2016 12:46:56 -0500

> So am I. Unicast != only two participants.
I see -- having PT point to different codec profiles for send and receive
breaks RTP forwarders/mixers.

Thank You,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Feb 2016 12:52:17 -0500

On Fri, Feb 26, 2016 at 12:20 PM, Paul Kyzivat <[email-masked]>
wrote:

>
> The session remains, and so the PT bindings remain. But the O/A rules are
> negotiating which of those are to be used going forward. If the new offer
> no longer mentions some PTs that were previously bound, then it is saying
> that it doesn't want to receive them any more.
>
> It is becoming clear to me that it will be necessary to define PT bindings
> - what they are, when they are established, when they are forgotten, and
> the scope within which they live. Each participant will need to know these
> bindings, and they must agree on them, except for well defined signaling
> delays. I guess this is a lot like an RTP session, except that it is tied
> to O/A signaling.
>

One other thing to keep in mind is that RTP session creation and tear down
is not time synchronized with O/A. End point might still be receiving media
packets for the previous RTP session after O/A completes. If O/A happen
often enough, several O/A exchanges can complete while old RTP sessions
established by old O/A exchanges are still running. PT should uniquely
identify codec profile for all of them. In case of SIP, O/A exchanges
typically take more time then RTP session setup/tear down, so keeping track
of the last two O/A exchanges is typically enough.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2016 13:08:01 -0500

On 2/26/16 12:34 PM, Colin Perkins wrote:
>>     That depends exactly what 3264 allows: if the two ends use
>>     different payload types to refer to the same codec, that’s okay;
>>     but if the two ends use the same payload type to refer to
>>     different codecs, that problematic.
>>
>>
>> Why is using the same PT to refer to different codecs is problematic?
>> Can you point out any potential problems that this will cause from RTP
>> perspective?
>
> without signalling, so that doesn’t help unless you somehow label the
> RTP stream with a header extension that says what payload type space
> it’s using.
>

And the entire point of O/A with RTP is for each participant to indicate 
the PT:codec-configuration it expects senders to use when sending 
packets to it. That mapping *isn't* SSRC-specific.

So for the two-participant case there doesn't seem to be a problem. Each 
participant carries one set of bindings for packets it sends, and a 
different set for the packets it receives.

If there are multiple participants it gets harder. If we allow 
conflicting bindings for each participant, then when the mixer sends out 
a packet to multiple participants it must be prepared to use different 
PTs for each receiver.

OTOH, if we try to write the O/A rules to prevent conflicting bindings, 
then it must be defined in such a way as to inform all potential senders 
of all bindings. When there are more that two participants (with a mixer 
in the middle) then there is potential for a race: two participants 
might concurrently send offers to the mixer, each establishing a new 
binding, using the *same* previously-unbound PT. Both can't be allowed 
to succeed. I don't right now see how to solve that problem.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2016 13:11:47 -0500

On 2/26/16 12:52 PM, Roman Shpount wrote:
> On Fri, Feb 26, 2016 at 12:20 PM, Paul Kyzivat <[email-masked]
>     The session remains, and so the PT bindings remain. But the O/A
>     rules are negotiating which of those are to be used going forward.
>     If the new offer no longer mentions some PTs that were previously
>     bound, then it is saying that it doesn't want to receive them any more.
>
>     forgotten, and the scope within which they live. Each participant
>     will need to know these bindings, and they must agree on them,
>     except for well defined signaling delays. I guess this is a lot like
>     an RTP session, except that it is tied to O/A signaling.
>
>
> One other thing to keep in mind is that RTP session creation and tear
> down is not time synchronized with O/A. End point might still be
> receiving media packets for the previous RTP session after O/A
> completes. If O/A happen often enough, several O/A exchanges can
> complete while old RTP sessions established by old O/A exchanges are
> still running. PT should uniquely identify codec profile for all of
> them. In case of SIP, O/A exchanges typically take more time then RTP
> session setup/tear down, so keeping track of the last two O/A exchanges
> is typically enough.

Yes, I understand that. I don't see how to solve it. It presents a hard 
problem. The new session may include a new participant that doesn't know 
the old bindings. If we require it to know them then that will require 
us to write more rules, and potentially break some existing usages.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Sat, 27 Feb 2016 04:29:03 -0500

One potential solution is to generate any offer in such a way that it will
be compatible with all the completed O/A exchanges for this end point. If
an end point receives an offer which is not compatible with existing state,
i.e. an offer which is reusing one of the PT for a different codec profile
similar, this end point must allocate new transport (use new local
address/port or new local set of candidates in case of ICE) for the answer
and consider this a start of the new session (discard all the PT use
history). If new transport cannot be allocated, for instance if responding
to an offer with ICE and existing ufrag, then offer must be refused with
488 or m line with port 0. This way end point can always uniquely map the
PT to the codec profile based on PT and local transport where the packet is
received. In case of 3pcc, an end point might get an offer which is
incompatible with its PT use history; allocate new local transport, and
handle it as a new RTP session.

What do you think?
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Feb 2016 11:10:20 -0500

On 2/27/16 4:29 AM, Roman Shpount wrote:
> One potential solution is to generate any offer in such a way that it
> will be compatible with all the completed O/A exchanges for this end
> point. If an end point receives an offer which is not compatible with
> existing state, i.e. an offer which is reusing one of the PT for a
> different codec profile similar, this end point must allocate new
> transport (use new local address/port or new local set of candidates in
> case of ICE) for the answer and consider this a start of the new session
> (discard all the PT use history). If new transport cannot be allocated,
> for instance if responding to an offer with ICE and existing ufrag, then
> offer must be refused with 488 or m line with port 0. This way end point
> can always uniquely map the PT to the codec profile based on PT and
> local transport where the packet is received. In case of 3pcc, an end
> point might get an offer which is incompatible with its PT use history;
> allocate new local transport, and handle it as a new RTP session.
>
> What do you think?

While there are probably a lot of details to work out, I like it as the 
outline of a direction to pursue.

It could get complicated for a focus. It might require the focus to 
change mixing policies for the offending participant.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Feb 2016 00:29:52 -0500

On Sat, Feb 27, 2016 at 11:10 AM, Paul Kyzivat <[email-masked]>
wrote:

> It could get complicated for a focus. It might require the focus to change
> mixing policies for the offending participant.
>

PT collisions are already a quite complicated for the conference focus.
Conference focus needs to deal with situations when multiple inbound
callers (in case of meet-me conference) use the same PT in incompatible
way. When outbound calls are placed from the focus, end points can add PT
to the answer which can also produce PT collisions. With my proposal these
collisions can be resolved using a re-INVITE from the focus which will
force new RTP sessions to be created on the clients.

>From implementation experience PT collisions do not present a real problem
in practice. All practical implementations of RTP mux that I had dealt with
either worked with specially pre-provisioned end points which all used the
same PT for the same codec profiles or conference focus implemented PT
re-mapping on each of the call legs.

Regards,
_____________
Roman Shpount

---

From: Colin Perkins <[email-masked]>
Date: Mon, 29 Feb 2016 13:27:49 +0000

> On 27 Feb 2016, at 16:10, Paul Kyzivat <[email-masked]> wrote:
> 
> While there are probably a lot of details to work out, I like it as the outline of a direction to pursue.
> 
> It could get complicated for a focus. It might require the focus to change mixing policies for the offending participant.

I expect it depends on the RTP topology in use. Some of the options in RFC 7667 treat different call legs as separate RTP sessions, whereas others treat them as a single session. That makes a difference, since PT is session scoped. 

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Feb 2016 13:28:12 +0000

Hi,

SDP Offer/Answer causes lots of problem. When I read all this it seems like we want to complicate things – which very likely will cause any more problems.

Two endpoints use SDP Offer/Answer to negotiate an “SDP session”. Can’t we try to define what rules apply within that “SDP session”? Why do we have to talk about RTP sessions etc?

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 29. helmikuuta 2016 7:30
To: Paul Kyzivat
Cc: Christer Holmberg; [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

On Sat, Feb 27, 2016 at 11:10 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

What do you think?

PT collisions are already a quite complicated for the conference focus. Conference focus needs to deal with situations when multiple inbound callers (in case of meet-me conference) use the same PT in incompatible way. When outbound calls are placed from the focus, end points can add PT to the answer which can also produce PT collisions. With my proposal these collisions can be resolved using a re-INVITE from the focus which will force new RTP sessions to be created on the clients.

From implementation experience PT collisions do not present a real problem in practice. All practical implementations of RTP mux that I had dealt with either worked with specially pre-provisioned end points which all used the same PT for the same codec profiles or conference focus implemented PT re-mapping on each of the call legs.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 10:28:35 -0500

On 2/29/16 8:28 AM, Christer Holmberg wrote:
> Hi,
>
> SDP Offer/Answer causes lots of problem. When I read all this it seems
> like we want to complicate things – which very likely will cause any
> more problems.
>
> Two endpoints use SDP Offer/Answer to negotiate an “SDP session”. Can’t
> we try to define what rules apply within that “SDP session”? Why do we
> have to talk about RTP sessions etc?

I've been trying to understand this since I first started working on sip 
(in 2002). I'm *finally* starting to understand some of the motivations 
for the words in 3264. Unfortunately those words fell far short of 
covering the concerns.

I agree that 3264 seems to have a notion of an "SDP session", that is 
different from an RTP session.

But when using RTP a consequence is that RTP sessions are being 
established and updated. Those do have rules of their own. It is 
presumably as hard or harder to change those as it is to change the O/A 
rules.

While 3264 phrases its PT rules in the context of an SDP session, they 
are pretty much scoped to an RTP session. (There is no interaction 
between the PTs of different m-lines.) AFAICT the only thing considering 
the SDP session can bring to this is to impose a rule that the PT 
bindings be retained for an m-line even when the RTP session for that 
m-line changes. I can see no downside in removing that restriction.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*Roman Shpount [mailto:[email-masked]]
> *Sent:* 29. helmikuuta 2016 7:30
> *To:* Paul Kyzivat
> *Cc:* Christer Holmberg; [email-masked]
> *Subject:* Re: [MMUSIC] Offer/Answer PT Questions - text proposal
>
> way. When outbound calls are placed from the focus, end points can add
> PT to the answer which can also produce PT collisions. With my proposal
> these collisions can be resolved using a re-INVITE from the focus which
> will force new RTP sessions to be created on the clients.
>
>  From implementation experience PT collisions do not present a real
> problem in practice. All practical implementations of RTP mux that I had
> dealt with either worked with specially pre-provisioned end points which
> all used the same PT for the same codec profiles or conference focus
> implemented PT re-mapping on each of the call legs.
>
> Regards,
>
> _____________
> Roman Shpount
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Feb 2016 19:18:26 +0000

Hi,

>> like we want to complicate things - which very likely will cause any 
>> more problems.
>>
>> Two endpoints use SDP Offer/Answer to negotiate an "SDP session". 
>> Can't we try to define what rules apply within that "SDP session"? Why 
>> do we have to talk about RTP sessions etc?
>
> I've been trying to understand this since I first started working on sip (in 2002). I'm *finally* starting to 
> understand some of the motivations for the words in 3264. Unfortunately those words fell far short of covering the concerns.
>
> I agree that 3264 seems to have a notion of an "SDP session", that is different from an RTP session.
>
> But when using RTP a consequence is that RTP sessions are being established and updated. Those do have rules of 
> their own. It is presumably as hard or harder to change those as it is to change the O/A rules.
>
> While 3264 phrases its PT rules in the context of an SDP session, they are pretty much scoped to an RTP session. 
>(There is no interaction between the PTs of different m-lines.) AFAICT the only thing considering the SDP session 
> can bring to this is to impose a rule that the PT bindings be retained for an m-line even when the RTP session for 
> that m-line changes. I can see no downside in removing that restriction.

Unless there is RTP session rules saying that the PT bindings must change in case of a new RTP session (within a given SDP session), I see no reason why we should introduce such rules within an SDP session.

(There may of course be other reasons why a new RTP session requires an O/A transaction, and maybe we need to describe that, but that is a separate issue)

Regards,

Christer

> callers (in case of meet-me conference) use the same PT in 
> incompatible way. When outbound calls are placed from the focus, end 
> points can add PT to the answer which can also produce PT collisions. 
> With my proposal these collisions can be resolved using a re-INVITE 
> from the focus which will force new RTP sessions to be created on the clients.
>
> problem in practice. All practical implementations of RTP mux that I 
> had dealt with either worked with specially pre-provisioned end points 
> which all used the same PT for the same codec profiles or conference 
> focus implemented PT re-mapping on each of the call legs.
>
> Regards,
>
> _____________
> Roman Shpount
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 16:02:41 -0500

> (There may of course be other reasons why a new RTP session requires an O/A transaction, and maybe we need to describe that, but that is a separate issue)

I'm not saying that the MUST change. Rather I'm saying that they need 
not remain. Certainly you could use the same PTs on the m-line for the 
new session. But I suggest we should make clear that there is no need to 
*remember* bindings from prior RTP sessions that shared the same m-line.

I don't see how that would break anything that currently works, and it 
provides a fix for things that might not work now.

If one implementation took this new approach, and recycled a PT in a new 
RTP session, and the other end was an old implementation that remembered 
the binding and refused the offer, then it might not work as well as if 
the new implementation remembered the old binding.

But that is just a matter of backward compatibility. We could certainly 
mention that new implementations might, when possible, attempt to 
remember and preserve old PT bindings just to avoid this problem, while 
*allowing* those bindings to be changed. Just a a nod to backward 
compatibility.

Tying this to RTP sessions will fix problems where it isn't possible to 
preserve old bindings. And it gives a rational underpinning to the rules.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Feb 2016 21:28:47 +0000

Hi,

>>>> SDP Offer/Answer causes lots of problem. When I read all this it 
>>>> seems like we want to complicate things - which very likely will 
>>>> cause any more problems.
>>>>
>>>> Can't we try to define what rules apply within that "SDP session"? 
>>>> Why do we have to talk about RTP sessions etc?
>>>
>>> I've been trying to understand this since I first started working on 
>>> sip (in 2002). I'm *finally* starting to understand some of the motivations for the words in 3264. Unfortunately those words fell far short of covering the concerns.
>>>
>>> established and updated. Those do have rules of their own. It is presumably as hard or harder to change those as it is to change the O/A rules.
>>>
>>> (There is no interaction between the PTs of different m-lines.) 
>>> AFAICT the only thing considering the SDP session can bring to this 
>>> is to impose a rule that the PT bindings be retained for an m-line even when the RTP session for that m-line changes. I can see no downside in removing that restriction.
>>
>> Unless there is RTP session rules saying that the PT bindings must change in case of a new RTP session 
>> (within a given SDP session), I see no reason why we should introduce such rules within an SDP session.
>>
>> (There may of course be other reasons why a new RTP session requires 
>> an O/A transaction, and maybe we need to describe that, but that is a 
>> separate issue)
>
> I'm not saying that the MUST change. Rather I'm saying that they need not remain. Certainly you could 
> use the same PTs on the m-line for the new session. But I suggest we should make clear that there is no need to

Why? If it's the same SDP session, we could still mandate bindings to remain. The SDP state still remains, so the previous binding information would not be "lost".

Assume that there are cases where the new RTP session would not require a new O/A transaction. The new bindings would not be signalled.

>I don't see how that would break anything that currently works, and it provides a fix for things that might not work now.

What won't work now? Why do we need to allow recycling within the same SDP session? If I've missed it, please let me know...

In any case, I think we have two separate questions:

1. What are the rules within a given RTP session?
2. Does a change of the RTP session, within the given SDP session, have an impact on the rules?

Regards,

Christer

> If one implementation took this new approach, and recycled a PT in a new RTP session, and the other end was an 
> old implementation that remembered the binding and refused the offer, then it might not work as well as if the 
> new implementation remembered the old binding.
>
> But that is just a matter of backward compatibility. We could certainly mention that new implementations might, when 
> possible, attempt to remember and preserve old PT bindings just to avoid this problem, while
>*allowing* those bindings to be changed. Just a a nod to backward compatibility.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 29 Feb 2016 21:40:04 +0000

> On 29 Feb 2016, at 21:28, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

A given RTP session has a mapping between RTP numbers and payload formats (i.e., codecs). All participants in the session are supposed to agree on that mapping, otherwise bad things can happen (trying to decode a packet with the wrong codec).

> 2. Does a change of the RTP session, within the given SDP session, have an impact on the rules?

The mapping is per RTP session. If two consecutive RTP sessions have the same mapping, that’s okay; it’s also okay if not. 

Colin

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Feb 2016 21:59:46 +0000

Hi,

...

> A given RTP session has a mapping between RTP numbers and payload formats (i.e., codecs). All 
> participants in the session are supposed to agree on that mapping, otherwise bad things can happen (trying to decode a packet with the wrong codec).

So, that means that the mapping has to be unique in both directions. I.e. no usage of PT111/VP8 in one direction and PT111/AMR-WG in the other direction.

> The mapping is per RTP session. If two consecutive RTP sessions have the same mapping, that’s okay; it’s also okay if not. 

Thanks. So, again, is there a reason why we, within an SDP session, would allow recycle of the mapping - even if the associated RTP session changes?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 17:03:42 -0500

> Why? If it's the same SDP session, we could still mandate bindings to remain. The SDP state still remains, so the previous binding information would not be "lost".

We have seen there are cases where it is *hard* to preserve the 
bindings. For instance because the updating O/A is attaching the call to 
a pre-existing RTP session, that has a different set of bindings.

> Assume that there are cases where the new RTP session would not require a new O/A transaction. The new bindings would not be signalled.

I guess in that case it doesn't matter until there is an O/A that 
proposes a change to the existing RTP session that conflicts with 
bindings that are present but that haven't yet been signaled in an O/A.

If that happens, then I guess it would be necessary to either create a 
new RTP session or else reject the SDP.

> What won't work now? Why do we need to allow recycling within the same SDP session? If I've missed it, please let me know...

I don't know where this need originally came from. I think there was 
something about compatibility with H.323. (IIRC the H.323 O/A rules are 
different.)

But again, I think the case that has been identified here is when 
connecting to a pre-existing RTP session.

> 2. Does a change of the RTP session, within the given SDP session, have an impact on the rules?

I agree that it is good to treat these as separate questions.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 17:06:45 -0500

> So, that means that the mapping has to be unique in both directions. I.e. no usage of PT111/VP8 in one direction and PT111/AMR-WG in the other direction.

I think what we have concluded earlier in this thread is that there 
can't be *conflicting* meanings in the two directions. But there can be 
multiple PTs for a given codec config, and an agreement that a different 
PT is used for each direction.

	Thanks,
	Paul