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

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Mar 2016 11:32:57 +0000

Hi,

1. What are the rules within a given RTP session?

>>> 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.
>
> I think what we have concluded earlier in this thread is that there can't be *conflicting* meanings in the two directions. 

Ok. 

> But there can be multiple PTs for a given codec config,

Do we want to recommend against changing the PT for a given codec, unless there is a good reason for it?

> and an agreement that a different PT is used for each direction.

I guess you mean that a different PT *CAN* be used for each direction?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Mar 2016 12:00:16 -0500

> Do we want to recommend against changing the PT for a given codec, unless there is a good reason for it?

I don't know. I guess Colin has said that there is *some* cost in RTP 
(in RTCP messages I suppose) to having multiple PTs for the same codec. 
But that should apply to the end introducing the alternative PT too, so 
we might just assume that each end makes its own judgement.

OTOH, based on this analysis, maybe we can conclude that there is no 
valid reason to do this, and so impose SHOULD NOT or MUST NOT on the 
practice.

> I guess you mean that a different PT *CAN* be used for each direction?

What I mean is that a different one MAY be introduced in an offer or 
answer, and that when sending to a particular participant, other 
participants MUST use one of the PTs mentioned in the most recent offer 
or answer by the target participant, even if there are other PTs that 
have been bound to codecs in this RTP session.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Mar 2016 13:23:55 -0500

On Tue, Mar 1, 2016 at 12:00 PM, Paul Kyzivat <[email-masked]> wrote:

> I don't know. I guess Colin has said that there is *some* cost in RTP (in
> RTCP messages I suppose) to having multiple PTs for the same codec. But
> that should apply to the end introducing the alternative PT too, so we
> might just assume that each end makes its own judgement.
>
> OTOH, based on this analysis, maybe we can conclude that there is no valid
> reason to do this, and so impose SHOULD NOT or MUST NOT on the practice.

I think the only cost is that you will run out of PT space.

> participants MUST use one of the PTs mentioned in the most recent offer or
> answer by the target participant, even if there are other PTs that have
> been bound to codecs in this RTP session.
>

Different PT (and different codecs) can be used in different directions.
Each party is supposed to use one of the PT from the remote party and use
the last SDP received from the remote party to map PT to codec profile when
encoding.

What really bugs me about this discussion is that it is extremely difficult
to determine when RTP session is started or stopped based on O/A exchanges.
Because of this it is difficult to determine when it is safe to reuse PT
for something else just by looking at O/A.

My proposal was extremely simple and based on three principals:

1. When end point sends an offer it MUST allocate PT in such a way that
this end point can unambiguously decode received RTP. If RTP packet with
given PT can be received, this PT cannot be reused for a different codec
profile

2. When end point receives an offer it always honor the PT assignments in
this offer even if they conflict with current PT assignments

3. If end point receives an offer and this offer conflicts with current PT
assignments, end point allocates new local transport, starts new RTP
session, forgets the existing PT assignment history and responds to this
offer as if it was a new call.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Mar 2016 14:06:07 -0500

On 3/1/16 1:23 PM, Roman Shpount wrote:

> What really bugs me about this discussion is that it is extremely
> difficult to determine when RTP session is started or stopped based on
> O/A exchanges. Because of this it is difficult to determine when it is
> safe to reuse PT for something else just by looking at O/A.

Well, can we assume that if the addr/port changes at one of the ends 
then this is to be a new RTP session?

Are there cases where nothing in the SDP changes but a new RTP session 
is established? (Or can we require signaling in this case?)

Maybe we need to start using the a=connection attribute with RTP to 
indicate change of RTP session. :-)

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Mar 2016 14:16:05 -0500

On Tue, Mar 1, 2016 at 2:06 PM, Paul Kyzivat <[email-masked]> wrote:

> Well, can we assume that if the addr/port changes at one of the ends then
> this is to be a new RTP session?
>

I saw end points that will update the remote addr/port but will continue
using the same RTP SSRC and sequence numbers.

Are there cases where nothing in the SDP changes but a new RTP session is
> established? (Or can we require signaling in this case?)
>

There are quite a few end points which will start a new RTP session
unsolicited.

> indicate change of RTP session. :-)

This will not be backwards compatible and will break a lot of things.

So far, there have been no relationship between O/A exchanges and RTP
sessions. Sometimes RTP sessions start without O/A exchange and sometimes
the same RTP session continues through O/A exchange. What we need is a
non-ambiguous way to decode RTP packets not the complete RTP session life
time management. This will mean we need to specify when new RTP session
MUST start (when conflict is detected). It does not require anything more.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Mar 2016 14:32:08 -0500

*If* it is really the case that there is no relationship between O/A and 
the lifetime of RTP sessions, then we have some work to do to sort out 
what the relationship is between what is in the O/A and what is in the 
RTP session.

IIUC, in the case where the is no RTP session prior an offer, the O/A 
must at least establish some initial PT bindings for the session-to-be.

(I have a feeling that what we are discussing is quite fundamental, and 
I find it shocking if it hasn't been considered in the past.)

Colin - your insight would be helpful here.

	Thanks,
	Paul

On 3/1/16 2:16 PM, Roman Shpount wrote:
> On Tue, Mar 1, 2016 at 2:06 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Are there cases where nothing in the SDP changes but a new RTP
>     session is established? (Or can we require signaling in this case?)
>
> sessions. Sometimes RTP sessions start without O/A exchange and
> sometimes the same RTP session continues through O/A exchange. What we
> need is a non-ambiguous way to decode RTP packets not the complete RTP
> session life time management. This will mean we need to specify when new
> RTP session MUST start (when conflict is detected). It does not require
> anything more.
> _____________
> Roman Shpount
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 14:47:55 +0000

Hi,

> *If* it is really the case that there is no relationship between O/A and the lifetime of RTP sessions, then 
> we have some work to do to sort out what the relationship is between what is in the O/A and what is in the RTP session.
>
> IIUC, in the case where the is no RTP session prior an offer, the O/A must at least establish some initial PT bindings for the session-to-be.
>
> (I have a feeling that what we are discussing is quite fundamental, and I find it shocking if it hasn't been considered in the past.)

I still don't get it... :)

When you negotiate an SDP session, unless you use BUNDLE, each m- line is associated with a different RTP session. You negotiate what PT bindings you are going to use within that SDP session.

If some SDP properties change - due to a RTP session change or whatever else - then a new O/A exchange is obviously needed. Nothing new about that.

But, as has been indicated, the change of RTP session does not automatically mandate new PT bindings, so I don't see why we need to consider RTP sessions when we talk about PT bindings.

Regards,

Christer

On 3/1/16 2:16 PM, Roman Shpount wrote:
> I saw end points that will update the remote addr/port but will 
> continue using the same RTP SSRC and sequence numbers.
>
> session life time management. This will mean we need to specify when 
> new RTP session MUST start (when conflict is detected). It does not 
> require anything more.
> _____________
> Roman Shpount
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 10:43:26 -0500

> But, as has been indicated, the change of RTP session does not automatically mandate new PT bindings, so I don't see why we need to consider RTP sessions when we talk about PT bindings.

The problem is that we have two goals that in some cases seem to conflict.

On one hand you want to manage O/A state. For the most part that 
includes the results of the most recent successful O/A exchange (the 
resulting local and remote SDP), and possibly another offer that is in 
progress. But based on 3264 it also seems to include, for each m-line, 
all the PT bindings ever made for the duration of this O/A session.

OTOH, it seems to be necessary for the PT bindings for an m-line to be 
consistent with the PT bindings of the RTP session currently in effect 
for that m-line. If that RTP session can change arbitrarily, then it 
potentially can be replaced by one that is inconsistent with the PT 
bindings of the O/A session.

Somehow that inconsistency needs to be resolved.

I have proposed that every time the RTP session changes the PT bindings 
for that line in the O/A session also change. You don't like that. Do 
you have another way to resolve the conflict?

(Note: after thinking about it more, I think that having the O/A 
bindings change when the RTP session changes doesn't have to depend on 
any explicit O/A signaling of the RTP session change. It is sufficient 
that the implementation be aware of the change, and that it initiate 
signaling if the PT bindings mentiond in the most recent O/A are no 
longer valid.)

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 11:02:55 -0500

On Wed, Mar 2, 2016 at 10:43 AM, Paul Kyzivat <[email-masked]> wrote:

>>> the lifetime of RTP sessions, then
>>> we have some work to do to sort out what the relationship is between
>>> what is in the O/A and what is in the RTP session.
>>>
>> When you negotiate an SDP session, unless you use BUNDLE, each m- line is
>> associated with a different RTP session. You negotiate what PT bindings you
>> are going to use within that SDP session.
>>
>> If some SDP properties change - due to a RTP session change or whatever
>> else - then a new O/A exchange is obviously needed. Nothing new about that.
>>
>> But, as has been indicated, the change of RTP session does not
>> automatically mandate new PT bindings, so I don't see why we need to
>> consider RTP sessions when we talk about PT bindings.
>>
>
> On one hand you want to manage O/A state. For the most part that includes
> the results of the most recent successful O/A exchange (the resulting local
> and remote SDP), and possibly another offer that is in progress. But based
> on 3264 it also seems to include, for each m-line, all the PT bindings ever
> made for the duration of this O/A session.
>
> consistent with the PT bindings of the RTP session currently in effect for
> that m-line. If that RTP session can change arbitrarily, then it

The problem is that if you have multiple O/A exchanges happening in rapid
succession, you can get RTP packets for any of the previous O/A exchanges.
This means you can have a new RTP session being set up for any of the
recent O/A exchanges. Unless you have an additional way to demultiplex,
such as using a different local transport, ssrc or mid, you will need to
map the received RTP packet to a particular O/A exchange. The only way left
is PT.

In reality this means you need to track last successful O/A, O/A in
progress, and all the successful O/A exchanges that completed recently for
which it is still possible to receive RTP packets. In most cases, O/A
exchange typically takes a lot longer then media flow setup, so that you
can limit the history to  last successful O/A and O/A in progress. On the
other hand, if ICE with TURN and DTLS are used, you can have multiple RTP
session setups in progress when corresponding O/A exchanges have already
completed.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 11:32:11 -0500

On 3/2/16 11:02 AM, Roman Shpount wrote:
> On Wed, Mar 2, 2016 at 10:43 AM, Paul Kyzivat <[email-masked]
>             *If* it is really the case that there is no relationship
>             between O/A and the lifetime of RTP sessions, then
>             we have some work to do to sort out what the relationship is
>             between what is in the O/A and what is in the RTP session.
>
>             IIUC, in the case where the is no RTP session prior an
>             offer, the O/A must at least establish some initial PT
>             bindings for the session-to-be.
>
>             (I have a feeling that what we are discussing is quite
>             fundamental, and I find it shocking if it hasn't been
>             considered in the past.)
>
>
>         When you negotiate an SDP session, unless you use BUNDLE, each
>         m- line is associated with a different RTP session. You
>         negotiate what PT bindings you are going to use within that SDP
>         session.
>
>         If some SDP properties change - due to a RTP session change or
>         whatever else - then a new O/A exchange is obviously needed.
>         Nothing new about that.
>
>         automatically mandate new PT bindings, so I don't see why we
>         need to consider RTP sessions when we talk about PT bindings.
>
>
>     resulting local and remote SDP), and possibly another offer that is
>     in progress. But based on 3264 it also seems to include, for each
>     m-line, all the PT bindings ever made for the duration of this O/A
>     session.
>
>     OTOH, it seems to be necessary for the PT bindings for an m-line to
>     be consistent with the PT bindings of the RTP session currently in
>     effect for that m-line. If that RTP session can change arbitrarily,
>     then it potentially can be replaced by one that is inconsistent with
>     the PT bindings of the O/A session.
>
> The problem is that if you have multiple O/A exchanges happening in
> rapid succession, you can get RTP packets for any of the previous O/A
> exchanges. This means you can have a new RTP session being set up for
> any of the recent O/A exchanges. Unless you have an additional way to
> demultiplex, such as using a different local transport, ssrc or mid, you
> will need to map the received RTP packet to a particular O/A exchange.
> The only way left is PT.
>
> progress, and all the successful O/A exchanges that completed recently
> for which it is still possible to receive RTP packets. In most cases,
> O/A exchange typically takes a lot longer then media flow setup, so that
> you can limit the history to  last successful O/A and O/A in progress.
> On the other hand, if ICE with TURN and DTLS are used, you can have
> multiple RTP session setups in progress when corresponding O/A exchanges
> have already completed.

I agree with you, at least in principle.

The question is: how much of this do we need to deal with in a normative 
way? At some point we may want to simply expect the implementer to avoid 
shooting himself in the foot.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 16:38:10 +0000

Hi,

…

>The problem is that if you have multiple O/A exchanges happening in rapid succession, you can get
>RTP packets for any of the previous O/A exchanges. This means you can have a new RTP session
>being set up for any of the recent O/A exchanges. Unless you have an additional way to demultiplex,
>such as using a different local transport, ssrc or mid, you will need to map the received RTP packet
>to a particular O/A exchange. The only way left is PT.

Which means that PT bindings, once they have been signalled, will “survive” subsequent O/A transactions, meaning that a given PT value must not be bound to another codec in a subsequent O/A. Which is what I believe the current 3264 text says – the question was whether it’s per SDP session or per direction within the SDP session.

Regards,

Christer

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 2 Mar 2016 16:58:57 +0000

Greetings from the land of Folks who deploy equipment and manage networks,

Where are we?

Thanks,

Martin

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, March 02, 2016 11:32 AM
To: Roman Shpount <[email-masked]>
Cc: [email-masked]; Christer Holmberg <[email-masked]>
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

On 3/2/16 11:02 AM, Roman Shpount wrote:
> demultiplex, such as using a different local transport, ssrc or mid, 
> you will need to map the received RTP packet to a particular O/A exchange.
> The only way left is PT.
>
> O/A exchange typically takes a lot longer then media flow setup, so 
> that you can limit the history to  last successful O/A and O/A in progress.
> multiple RTP session setups in progress when corresponding O/A 
> exchanges have already completed.

The question is: how much of this do we need to deal with in a normative way? At some point we may want to simply expect the implementer to avoid shooting himself in the foot.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 12:04:10 -0500

> Greetings from the land of Folks who deploy equipment and manage networks,

We are still trying to figure out what was originally intended, why, and 
what really makes sense. This turns out not to be easy to answer.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 12:44:21 -0500

On Wed, Mar 2, 2016 at 11:38 AM, Christer Holmberg <
[email-masked]> wrote:

> Which means that PT bindings, once they have been signalled, will
> “survive” subsequent O/A transactions, meaning that a given PT value must
> not be bound to another codec in a subsequent O/A. Which is what I believe
> the current 3264 text says – the question was whether it’s per SDP session
> or per direction within the SDP session.
>
>
> If we want to support RTP forwarders it is per entire SDP session and not
per direction in the session.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 12:54:08 -0500

> Greetings from the land of Folks who deploy equipment and manage networks,

I actually also develop network equipment, deploy and manage networks. In
that capacity, I am trying to follow the principal where I am trying to
always generate what is compliant and accept anything reasonable (even
non-compliant to the letter of the specification). So, if you can make your
equipment generate offers which are compatible with all the previous O/A
exchanges in the session and accept any offer even if it has a conflicting
PT assignment then you should be in good shape. You can deal with offers
with conflicting PT by assigning a new local transport in the answer and
making sure none of the conflicting RTP packets will be received by the old
session.

If you are waiting for the normative answer then:

a. Offer from Bob in your original example is non compliant with RFC 3264
since PT assignment is per session and not per direction

b. Requirements in RFC 3264 are most likely non-implementable if third
party call control is used, so they need to be adjusted

c. The exact nature of how RFC 3264 needs to adjusted is a complicated
issue. It will take a few months to get an answer that will satisfy
everybody (or at least majority) and then write it up in a draft.

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 21:58:56 +0000

Hi,

IF we agree that the PT binding is per session, and not per direction, we can update that part of 3264, because THAT’s what causing Martin’s issue.

Then we can spend months working on other things that also may need to be solved.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 02 March 2016 19:54
To: DOLLY, MARTIN C <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; [email-masked]; Christer Holmberg <[email-masked]>
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

On Wed, Mar 2, 2016 at 11:58 AM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:
Greetings from the land of Folks who deploy equipment and manage networks,

Where are we?

I actually also develop network equipment, deploy and manage networks. In that capacity, I am trying to follow the principal where I am trying to always generate what is compliant and accept anything reasonable (even non-compliant to the letter of the specification). So, if you can make your equipment generate offers which are compatible with all the previous O/A exchanges in the session and accept any offer even if it has a conflicting PT assignment then you should be in good shape. You can deal with offers with conflicting PT by assigning a new local transport in the answer and making sure none of the conflicting RTP packets will be received by the old session.

a. Offer from Bob in your original example is non compliant with RFC 3264 since PT assignment is per session and not per direction

b. Requirements in RFC 3264 are most likely non-implementable if third party call control is used, so they need to be adjusted

c. The exact nature of how RFC 3264 needs to adjusted is a complicated issue. It will take a few months to get an answer that will satisfy everybody (or at least majority) and then write it up in a draft.

_____________
Roman Shpount

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Mar 2016 22:01:54 +0000

> On 1 Mar 2016, at 18:23, Roman Shpount <[email-masked]> wrote:
> 
> On Tue, Mar 1, 2016 at 12:00 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
> I don't know. I guess Colin has said that there is *some* cost in RTP (in RTCP messages I suppose) to having multiple PTs for the same codec. But that should apply to the end introducing the alternative PT too, so we might just assume that each end makes its own judgement.
> 
> OTOH, based on this analysis, maybe we can conclude that there is no valid reason to do this, and so impose SHOULD NOT or MUST NOT on the practice.
> 

Agree.

> What I mean is that a different one MAY be introduced in an offer or answer, and that when sending to a particular participant, other participants MUST use one of the PTs mentioned in the most recent offer or answer by the target participant, even if there are other PTs that have been bound to codecs in this RTP session.
> 
> Different PT (and different codecs) can be used in different directions. Each party is supposed to use one of the PT from the remote party and use the last SDP received from the remote party to map PT to codec profile when encoding.

This I’m not sure I agree with. An RTP session is bi-directional, and the PT mapping has to be consistent in both directions. This doesn’t mean that the A->B flows has to use the same PT to identify a codec as the B->A flow uses, but they can’t use the same PT to identify different codecs. 

> What really bugs me about this discussion is that it is extremely difficult to determine when RTP session is started or stopped based on O/A exchanges. Because of this it is difficult to determine when it is safe to reuse PT for something else just by looking at O/A.
> 
> 1. When end point sends an offer it MUST allocate PT in such a way that this end point can unambiguously decode received RTP. If RTP packet with given PT can be received, this PT cannot be reused for a different codec profile
> 
> 2. When end point receives an offer it always honor the PT assignments in this offer even if they conflict with current PT assignments
> 
> 3. If end point receives an offer and this offer conflicts with current PT assignments, end point allocates new local transport, starts new RTP session, forgets the existing PT assignment history and responds to this offer as if it was a new call.
> 
> Regards,
> _____________
> Roman Shpount
>  

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Mar 2016 22:03:29 +0000

> On 1 Mar 2016, at 19:06, Paul Kyzivat <[email-masked]> wrote:
> Well, can we assume that if the addr/port changes at one of the ends then this is to be a new RTP session?

The RTP session is tied to the shared SSRC space. If the same SSRCs are valid after the change, it’s the same RTP session.

> Are there cases where nothing in the SDP changes but a new RTP session is established? (Or can we require signaling in this case?)
> 
> Maybe we need to start using the a=connection attribute with RTP to indicate change of RTP session. :-)
> 
> 	Thanks,
> 	Paul
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Mar 2016 22:05:10 +0000

> On 1 Mar 2016, at 19:32, Paul Kyzivat <[email-masked]> wrote:
> 
> *If* it is really the case that there is no relationship between O/A and the lifetime of RTP sessions, then we have some work to do to sort out what the relationship is between what is in the O/A and what is in the RTP session.
> 

I don’t have good insights here. I’ve long had the impression there are conflicts between the o/a rules and the RTP rules, but I’m insufficiently familiar with o/a to identify or resolve them.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 22:23:55 +0000

Hi,

>> *If* it is really the case that there is no relationship between O/A and the lifetime of RTP sessions, then we have 
>> some work to do to sort out what the relationship is between what is in the O/A and what is in the RTP session.
>> 

What started this discussion was the uncertainty whether the same PT could be used for *different* codecs, per direction. The answer to that seem to be no: you can use different PTs for the same codec, but you cannot use the same PT for different codecs.

Also, I have also heard that a new RTP session does NOT require new PT bindings.

So, I may have missed something, but I fail to see any conflicts...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 17:24:17 -0500

> I don’t have good insights here. I’ve long had the impression there are conflicts between the o/a rules and the RTP rules, but I’m insufficiently familiar with o/a to identify or resolve them.

And I have begun to suspect those conflicts too, but I’m insufficiently 
familiar with *rtp* to identify or resolve them.

I guess we need to find somebody fluent in both, or else keep talking 
till we understand each other. Maybe Roman fits the bill. I suspect that 
Jonathan Lennox does, but he seems to have been quiet recently, so I 
suspect he is busy.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Mar 2016 22:28:36 +0000

> On 2 Mar 2016, at 22:23, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

I agree with that answer.

> Also, I have also heard that a new RTP session does NOT require new PT bindings.

Again, I agree. The PT binding as per RTP session: if you start a new RTP session, you can use different PT values, but you’re not required to do so (and generally don’t, since the static PT assignments are re-used).

> So, I may have missed something, but I fail to see any conflicts...

In that case, good! As I say, I’m insufficiently familiar with o/a to know for sure.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 17:32:32 -0500

> The RTP session is tied to the shared SSRC space. If the same SSRCs are valid after the change, it’s the same RTP session.

Fine. But how do the participants in the O/A session discover that the 
SSRC space has changed?

In general I assume that the O/A is what tells them this sort of stuff. 
I guess it can also be learned via RTCP. But if the one end decides to 
switch to a new RTP session, without signaling this change via O/A, I 
assume that things will be messed up until a bunch of RTCP stuff has 
been exchanged. That doesn't seem graceful.

So, while mechanically it is possible to make such a change without 
signaling it, in practice it seems like a bad idea.

But I also don't see how to signal a change in RTP session via O/A. 
Superficially, it seems like changing the addr/port is *likely* to mean 
you have a new RTP session. But that isn't *necessarily* true. It could 
be you are simply changing to a different path to the same target.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Mar 2016 22:41:49 +0000

> On 2 Mar 2016, at 22:32, Paul Kyzivat <[email-masked]> wrote:
> 
> Fine. But how do the participants in the O/A session discover that the SSRC space has changed?

I don’t know - I’d always thought the lifetimes were aligned. That is, the o/a exchange set of a set of parallel RTP sessions (one per media, unless bundle is used) that had lifetime matching the o/a session. 

Perhaps that works, perhaps not. For the simple cases I expect it does work. For cases with middleboxes and multiple participants, I expect things get rapidly complex. But, anything to do with middleboxes and RTP gets complex, because we have multiple topologies many of which don’t really conform to how RTP handles sessions (this is what RFC 7667 tries to sort out).

> In general I assume that the O/A is what tells them this sort of stuff. I guess it can also be learned via RTCP. But if the one end decides to switch to a new RTP session, without signaling this change via O/A, I assume that things will be messed up until a bunch of RTCP stuff has been exchanged. That doesn't seem graceful.
> 
> So, while mechanically it is possible to make such a change without signaling it, in practice it seems like a bad idea.
> 
> But I also don't see how to signal a change in RTP session via O/A. Superficially, it seems like changing the addr/port is *likely* to mean you have a new RTP session. But that isn't *necessarily* true. It could be you are simply changing to a different path to the same target.
> 
> 	Thanks,
> 	Paul
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 17:42:41 -0500

>> So, I may have missed something, but I fail to see any conflicts...

I think I agree with all of the above. As long as the RTP session change 
is to a *new* one.

But suppose you are switched to another preexisting RTP session. It is 
new to you, but it isn't new, and has existing RTP bindings. And those 
might conflict with ones you had in your old RTP session.

If you knew this was a new RTP session you could forget your old 
bindings, and start over.

This sort of thing could happen if you are connecting to a conference 
server. First you are connected to an IVR to authenticate. That is your 
first RTP session. After that you are transferred into the conference. 
That is your 2nd RTP session.

If this is done via REFER, then you will see it as a new SIP and O/A 
session, and so will start out with an empty set of PT bindings.

But if this is done via 3pcc, or a media relay, then we have the problem.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 17:46:15 -0500

On Wed, Mar 2, 2016 at 5:32 PM, Paul Kyzivat <[email-masked]> wrote:

>> The RTP session is tied to the shared SSRC space. If the same SSRCs are
>> valid after the change, it’s the same RTP session.
>>
>

I think they cannot. End point will know that new RTP session started after
the initial O/A exchange but even that is not given since they can be added
to an existing RTP session using 3pcc.

In general I assume that the O/A is what tells them this sort of stuff. I
> guess it can also be learned via RTCP. But if the one end decides to switch
> to a new RTP session, without signaling this change via O/A, I assume that
> things will be messed up until a bunch of RTCP stuff has been exchanged.
> That doesn't seem graceful.
>

This cannot be learned from O/A or RTCP. This is an ephemeral concept. New
parties can join and leave RTP session and this can be detected using RTCP
and RTP, but there is no indication that entire RTP session started or
stopped.

> signaling it, in practice it seems like a bad idea.

Adding new parties to running RTP sessions without signaling happens quite
routinely. Imagine a new party being added to RTP mixer. It can start
forwarding RTP to the other parties without any signaling.

> Superficially, it seems like changing the addr/port is *likely* to mean you
> have a new RTP session. But that isn't *necessarily* true. It could be you
> are simply changing to a different path to the same target.
>

You also need to deal with situations where only one party changes
addr/port. The other party continues to use the same SSRC, sequence
numbers, etc.

Addr/port change can also mean just IP path fail over when end point
migrates to a different network or DHCP lease expires.
_____________
Roman Shpount

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 2 Mar 2016 22:46:37 +0000

Now that I see thread of agreement on a few points, who dis agrees

And Paul, no tangents 

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards 
AT&T
Cell: 609-903-3360
Email: [email-masked]

> On Mar 2, 2016, at 5:28 PM, Colin Perkins <[email-masked]> wrote:
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 17:56:28 -0500

On Wed, Mar 2, 2016 at 5:24 PM, Paul Kyzivat <[email-masked]> wrote:

>
> I guess we need to find somebody fluent in both, or else keep talking till
> we understand each other. Maybe Roman fits the bill. I suspect that

I have some familiarity with both O/A and RTP, but mostly in context of
Audio/Video implementations. I have also dealt with couple of RTP
mixers/forwarders but I cannot claim I've seen all possible variations here.

The problem we are facing is that O/A provides no clear indication of when
RTP session starts and ends. It obviously starts after initial setup and
ends when call completes, but it is unclear if RTP session starts or ends
somewhere in the middle. It can also be ambiguous for the parties
participating in O/A, especially in cases of 3pcc. In case of 3pcc one
party might think that it is a completely new session and another think it
is a session update. I think now most end points try to be conservative and
assume that RTP session runs for the entire duration of the O/A session
with session updates not starting new sessions.

My suggestion is to state that RTP session starts with initial O/A exchange
and ends when the call ends. On top of this, if end point detects a PT
collision on an offer, it should forget the old PT assignment history,
allocate new local transport and start the new RTP session.

It is either this or special SDP attribute that states this is a new RTP
session. Or it can be both -- attribute to force the new RTP session or
automatically starting new RTP session on conflict. In fact this will be
very similar to dtls-connection attribute we just defined and tries to
solve the same problem (not sending ambiguous content over the same
transport).

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 18:04:46 -0500

On Wed, Mar 2, 2016 at 4:58 PM, Christer Holmberg <
[email-masked]> wrote:

> IF we agree that the PT binding is per session, and not per direction, we
> can update that part of 3264, because THAT’s what causing Martin’s issue.
>

RFC 3264 might be slightly ambiguous about the answer since it does not
even define the "session", but it never states that binding is per
direction. It states that binding MUST NOT change for the duration of a
session with no direction mentioned in this restriction. This mean we might
need a clarification but not necessarily an update.

Bigger problem is that this requirement is unimplementable with 3pcc and
routinely ignored. This is definitely a problem and needs an update to
resolve.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Mar 2016 07:14:39 +0000

Hi,

>> RFC 3264 might be slightly ambiguous about the answer since it does not even define the "session", but it never states that binding is per direction. It states
>> that binding MUST NOT change for the duration of a session with no direction mentioned in this restriction. This mean we might need a clarification but not necessarily an update.

Well, technically it is an update to RFC 3264, even if the new text only clarifies existing text :)

>Bigger problem is that this requirement is unimplementable with 3pcc and routinely ignored. This is definitely a problem and needs an update to resolve.

But then, is it a good idea to say that the PT binding is for the whole O/A session? What preventing us from saying that it is per direction? The fact that it would conflict with the RTP session definition?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Mar 2016 09:51:55 +0000

Hi,

...

>But suppose you are switched to another preexisting RTP session. It is new to you, but it isn't new, and has existing RTP bindings. And those might conflict with ones you had in your old RTP session.
>
>If you knew this was a new RTP session you could forget your old bindings, and start over.
>
>This sort of thing could happen if you are connecting to a conference server. First you are connected to an IVR to authenticate. That is your first RTP session. After that you are transferred into the conference. 
>If this is done via REFER, then you will see it as a new SIP and O/A session, and so will start out with an empty set of PT bindings.
>

So, then, perhaps we should allow PT re-binding within an O/A session, in case the underlying RTP session etc changes?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 3 Mar 2016 11:19:51 -0500

On Thu, Mar 3, 2016 at 2:14 AM, Christer Holmberg <
[email-masked]> wrote:

> >> IF we agree that the PT binding is per session, and not per direction,
> we can update that part of 3264, because THAT’s what causing Martin’s issue.
> >>
> direction. It states
> >> that binding MUST NOT change for the duration of a session with no
> direction mentioned in this restriction. This mean we might need a
> clarification but not necessarily an update.
>

The biggest problem with RFC 3264 is coming from the fact that term
"session" is not even defined and things like RTP session are not even
mentioned.

> But then, is it a good idea to say that the PT binding is for the whole
> O/A session? What preventing us from saying that it is per direction? The
> fact that it would conflict with the RTP session definition?
>

If there are more then two parties in the RTP session, i.e. if one of the
parties in O/A is an RTP forwarder, the same PT cannot possibly be assigned
to different codecs in different directions. This is why PT binding is per
O/A session.
_____________
Roman Shpount

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 3 Mar 2016 16:20:05 +0000

> On Mar 2, 2016, at 5:24 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> And I have begun to suspect those conflicts too, but I’m insufficiently familiar with *rtp* to identify or resolve them.
> 
> I guess we need to find somebody fluent in both, or else keep talking till we understand each other. Maybe Roman fits the bill. I suspect that Jonathan Lennox does, but he seems to have been quiet recently, so I suspect he is busy.

Hi — yes, I’ve been fairly busy, but I’ll try to respond.

RTP (in its full RFC 3550 generality) and SDP Offer/Answer certainly do have conflicts.  Basically, the problem is that offer/answer assumes that each end of a negotiation specifies its own view of a session, with fairly wide latitude to specify its own preferences, whereas RTP assumes a single session view shared by all participants.

As a consequence of this, there are a number of RTP topologies that can’t be negotiated through SDP Offer/Answer, unless both sides of the negotiation know (through some out-of-band means) that that’s what they’re trying to do.

I wrote a draft back in 2012 on the topic — draft-lennox-avtcore-rtp-topo-offer-answer-00 — with the intention of indicating that RTP should relax some of its constraints for offer/answer-only use cases, but I don’t think I convinced anybody.  Nonetheless, the draft is still probably useful for pointing out some of the mismatches between the two models.

Other than the PT negotiation problem, already discussed, the other major issue is bandwidth.  Offer/Answer lets each side set its bandwidth independently, but RTP assumes a single global session bandwidth.  In particular, RTCP member timeouts are based on the RTCP bandwidth, and it’s not clear how these should be computed when session bandwidths are asymmetric.

(I don’t think this last point is a flaw in Offer/Answer — asymmetric bandwidths are a very common real-world use case which need to be supported.  Instead, I think this is something that RTP needs to figure out.  This will become even more relevant as RMCAT-type bandwidth discovery mechanisms mean that the endpoints have no a priori way of knowing even the order of magnitude of available bandwidth to expect.)

---

From: Roman Shpount <[email-masked]>
Date: Thu, 3 Mar 2016 11:29:56 -0500

On Thu, Mar 3, 2016 at 4:51 AM, Christer Holmberg <
[email-masked]> wrote:

> So, then, perhaps we should allow PT re-binding within an O/A session, in
> case the underlying RTP session etc changes?
>

Yes, we should allow re-binding. This is what I was saying all along. The
only thing you need to do when re-bind PT is to change local transport or
mid so that you can decode incoming RTP packets using the right PT mapping.

To reiterate:

1. RTP session can start before the O/A session in cases of 3pcc and RTP
mixers.

2. It can continue after O/A session ends in cases 3pcc and RTP mixers

3. O/A session can migrate from one RTP session to another in case 3pcc or
RTP forwarders.

4. End point participating in O/A session does not always have access to
previous history of the RTP session it participates in and has no way to
determine when RTP session changes.

Most importantly, all of the above is irrelevant to solve the problem in
hand. Solution should be that O/A session should operate as if O/A session
is an RTP session until it encounters a conflict. If conflict is
encountered (since it is unavoidable in some architectures such as 3pcc and
RTP mixers), a recovery mechanism should be provided (allocate new local
transport and start the new RTP session).
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Mar 2016 13:58:16 -0500

On 3/3/16 11:29 AM, Roman Shpount wrote:
> On Thu, Mar 3, 2016 at 4:51 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     So, then, perhaps we should allow PT re-binding within an O/A
>     session, in case the underlying RTP session etc changes?
>
>
> Yes, we should allow re-binding. This is what I was saying all along.
> The only thing you need to do when re-bind PT is to change local
> transport or mid so that you can decode incoming RTP packets using the
> right PT mapping.
>
> To reiterate:
>
> 3. O/A session can migrate from one RTP session to another in case 3pcc
> or RTP forwarders.
>
> hand. Solution should be that O/A session should operate as if O/A
> session is an RTP session until it encounters a conflict. If conflict is
> encountered (since it is unavoidable in some architectures such as 3pcc
> and RTP mixers), a recovery mechanism should be provided (allocate new
> local transport and start the new RTP session).

So I think you are suggesting that the PTs be bound to an 
[m-line,local-addr,local-port,remote-addr,remote-port] tuple. Any time 
the the local/remote-addr or local/remote-port changes for an m-line, 
the old bindings can be forgotten. And this is regardless of whether 
there is a new RTP session or not.

Is that right?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Mar 2016 14:08:24 -0500

On 3/2/16 5:56 PM, Roman Shpount wrote:

> My suggestion is to state that RTP session starts with initial O/A
> exchange and ends when the call ends. On top of this, if end point
> detects a PT collision on an offer, it should forget the old PT
> assignment history, allocate new local transport and start the new RTP
> session.

I see what you are trying to do. Assigning a new local transport allows 
the end point to disambiguate late packets sent prior to the O/A from 
those sent via the new O/A.

But it doesn't necessarily start a new RTP session - not if the other 
end thinks it is still the old RTP session.

ISTM the problem is that the notion of an RTP session seems to be an 
abstract one. The actual embodiment of it is as a database distributed 
among all the participants. I guess it is loosely synchronized. (I don't 
know enough about RTP here.)

If one participant forgets all of the state for the RTP session, will it 
eventually all get filled in? If so, will it get filled in soon enough 
to properly interpret the stuff it is receiving?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Mar 2016 14:24:21 -0500

On 3/3/16 11:19 AM, Roman Shpount wrote:

>     But then, is it a good idea to say that the PT binding is for the
>     whole O/A session? What preventing us from saying that it is per
>     direction? The fact that it would conflict with the RTP session
>     definition?
>
>
> If there are more then two parties in the RTP session, i.e. if one of
> the parties in O/A is an RTP forwarder, the same PT cannot possibly be
> assigned to different codecs in different directions. This is why PT
> binding is per O/A session.

Based on our earlier discussions in this thread there seems to be an 
intermediate position. There can be separate *requested* bindings by 
each participant, as long as they don't conflict. So this can result in 
PTa and PTb bound to codec1, with participant A requesting PTa and 
participant B requesting PTb.

So then this serves to say that each participant is requesting which of 
the bindings are to be used when sending toward it.

This can work for unicast, but not for multicast. And for unicast 
conferences it might be slightly inefficient in that when packets are 
being sent to multiple participants the PT may need to be rewritten in each.

Then there is the question of whether this will help anything. Will 
those that want to use differing PTs be able to comply with the 
uniqueness requirement?

Maybe we need to investigate the root cause. Precisely why is it that 
some answerers feel a need to use a different PT than that found in the 
offer? What else is going on in their implementation? Is it still a real 
problem? Or is it just a historical artifact?

(Obviously some implementations still request this. Do they *need* to, 
or do they simply want to?)

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 3 Mar 2016 14:47:50 -0500

On Thu, Mar 3, 2016 at 2:08 PM, Paul Kyzivat <[email-masked]> wrote:

> the end point to disambiguate late packets sent prior to the O/A from those
> sent via the new O/A.
>
> But it doesn't necessarily start a new RTP session - not if the other end
> thinks it is still the old RTP session.
>
> eventually all get filled in? If so, will it get filled in soon enough to
> properly interpret the stuff it is receiving?

This is no different then new participant joining an existing RTP session.
Joining an existing session as a result of 3pcc is the most likely cause
for this conflict and treating it as a new session is the best way to
resolve this.

In practice I want to restrict this even more:

1. If end point has the PT assignment history based on O/A session it
should honor this history when generating an offer

2. If end point receives an offer that has no conflicting PT assignments,
end point should generate an answer with PT assignments based on the O/A
session history

3. If end point receives an offer which has conflicting PT assignments
(normally as a result of 3pcc connecting this end point with another
session), end point should discard O/A PT assignment history, assign new
local transport (new local addr/port or whole new set of candidates in case
of ICE), and generate an answer as if it was an initial offer in the
session.

4. If end point receives an answer with conflicting PT assignment (normally
as a result of 3pcc sending an offer to a new end point which added PT to
the answer in a way incompatible with the O/A session history), end point
should discard O/A PT assignment history and treat the just completed O/A
exchange as an exchange that started a new session. Since PT assignment
conflict in the answer should only occur if communicating with a new end
point, sending media to this new end point using PT which was assigned to a
different codec profile in this session should not present problems.

With this we achieve backwards interop, since this end point works
according to existing RFC 3264 rules unless something else breaks these
rules. If the rules are broken, end point detects that this is a new
session and recovers.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Mar 2016 15:11:43 -0500

On 3/3/16 2:47 PM, Roman Shpount wrote:
> On Thu, Mar 3, 2016 at 2:08 PM, Paul Kyzivat <[email-masked]
>     I see what you are trying to do. Assigning a new local transport
>     allows the end point to disambiguate late packets sent prior to the
>     O/A from those sent via the new O/A.
>
>     But it doesn't necessarily start a new RTP session - not if the
>     other end thinks it is still the old RTP session.
>
>     abstract one. The actual embodiment of it is as a database
>     distributed among all the participants. I guess it is loosely
>     synchronized. (I don't know enough about RTP here.)
>
>     If one participant forgets all of the state for the RTP session,
>     will it eventually all get filled in? If so, will it get filled in
>     soon enough to properly interpret the stuff it is receiving?
>
>
> This is no different then new participant joining an existing RTP
> session. Joining an existing session as a result of 3pcc is the most
> likely cause for this conflict and treating it as a new session is the
> best way to resolve this.
>
> 2. If end point receives an offer that has no conflicting PT
> assignments, end point should generate an answer with PT assignments
> based on the O/A session history
>
> local transport (new local addr/port or whole new set of candidates in
> case of ICE), and generate an answer as if it was an initial offer in
> the session.
>
> 4. If end point receives an answer with conflicting PT assignment
> (normally as a result of 3pcc sending an offer to a new end point which
> added PT to the answer in a way incompatible with the O/A session
> history), end point should discard O/A PT assignment history and treat
> the just completed O/A exchange as an exchange that started a new
> session. Since PT assignment conflict in the answer should only occur if
> communicating with a new end point, sending media to this new end point
> using PT which was assigned to a different codec profile in this session
> should not present problems.
>

This seems plausible. But I want to understand some details.

ISTM we are talking about *two* PT assignment histories:
- The O/A PT binding history for this m-line
- The RTP PT binding within the RTP stack for this m-line.

Are you thinking of these as distinct, or one and the same thing?

Note that the O/A bindings will include endpoint-preferences. AFAIK 
those are not part of RTP stack state.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 3 Mar 2016 15:35:20 -0500

On Thu, Mar 3, 2016 at 3:11 PM, Paul Kyzivat <[email-masked]> wrote:

> Note that the O/A bindings will include endpoint-preferences. AFAIK those
> are not part of RTP stack state.
>

I was talking about O/A PT binding history for this m-line.

Normally end point should be prepared to receive any PT it advertised
through O/A. So, to have a non-ambiguous PT decoding map, end point must
keep track for all the assignments in the O/A session even if no RTP with
this PT was ever sent or received.

Not sure what you mean by preferences. If you mean the codec profile
relative preference, then this can be changed by O/A at any time as long as
PT assignment stays the same.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Mar 2016 17:01:52 -0500

On 3/3/16 3:35 PM, Roman Shpount wrote:
> On Thu, Mar 3, 2016 at 3:11 PM, Paul Kyzivat <[email-masked]
> keep track for all the assignments in the O/A session even if no RTP
> with this PT was ever sent or received.

ISTM that we are working with two sets of rules: O/A rules and RTP 
rules. I gather that in general a participant in an RTP session might 
expected to be able to send, receive and understand media with any of 
the PTs bound within the RTP session.

OTOH, according to O/A rules a participant should expect that media will 
only arrive using PTs from the most recent offer or answer by this 
participant. (With an exception for late arriving messages sent based on 
a prior offer or answer.) And that participant is also constrained to 
send according to those rules.

So I guess we are constraining implementations to implement in a way 
that is simultaneously compliant to both sets of rules.

> relative preference, then this can be changed by O/A at any time as long
> as PT assignment stays the same.

It was probably a bad word choice, but I couldn't think of a better one. 
I meant that of all the PT bindings in the RTP session, the ones on the 
most recent sdp of a participant are to be the only ones to be used when 
sending to that participant. Hence the participant, via its offer or 
answer, is signaling which PTs it wishes (prefers) to have used.

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 4 Mar 2016 12:28:42 +0000

My assumption is that the term “session” in RFC 3264 is inherited from RFC 3261 when used in the context of SIP. That definition is as follows:

      Session: From the SDP specification: "A multimedia session is a
         set of multimedia senders and receivers and the data streams
         flowing from senders to receivers.  A multimedia conference is
         an example of a multimedia session." (RFC 2327 [1]) (A session
         as defined for SDP can comprise one or more RTP sessions.)  As
         defined, a callee can be invited several times, by different
         calls, to the same session.  If SDP is used, a session is
         defined by the concatenation of the SDP user name, session id,
         network type, address type, and address elements in the origin
         field.

I’d note that we have definitions of both “multimedia session” and “communication session” in RFC 7656. My assumption is that the definition above relates to “communication session”.

Given that we have a currently open revision of the SDP specification, it might be worth making a more robust definition by reference in that document.

Note that RFC 7656 also gives the definition of RTP session.

Regards

Keith

From: mmusic [mailto:[email-masked]] On Behalf Of EXT Roman Shpount
Sent: 03 March 2016 16:20
To: Christer Holmberg
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

The biggest problem with RFC 3264 is coming from the fact that term "session" is not even defined and things like RTP session are not even mentioned.

If there are more then two parties in the RTP session, i.e. if one of the parties in O/A is an RTP forwarder, the same PT cannot possibly be assigned to different codecs in different directions. This is why PT binding is per O/A session.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 Mar 2016 13:18:19 -0500

On 3/4/16 7:28 AM, Drage, Keith (Nokia - GB) wrote:
> My assumption is that the term “session” in RFC 3264 is inherited from
> RFC 3261 when used in the context of SIP. That definition is as follows:
>
> I’d note that we have definitions of both “multimedia session” and
> “communication session” in RFC 7656. My assumption is that the
> definition above relates to “communication session”.

I'll agree that one or the other of the above was probably intended. In 
any case I have some difficulty distinguishing between the two.

Looking to 3264 for answers, I find the following in the introduction:

    ... Unlike multicast,
    where there is a global view of the session that is used by all
    participants, unicast sessions involve two participants, and a
    complete view of the session requires information from both
    participants, and agreement on parameters between them.

    As an example, a multicast session requires conveying a single
    multicast address for a particular media stream.  However, for a
    unicast session, two addresses are needed - one for each participant.
    As another example, a multicast session requires an indication of
    which codecs will be used in the session.  However, for unicast, the
    set of codecs needs to be determined by finding an overlap in the set
    supported by each participant.

    As a result, even though SDP has the expressiveness to describe
    unicast sessions, it is missing the semantics and operational details
    of how it is actually done.  In this document, we remedy that by
    defining a simple offer/answer model based on SDP.  In this model,
    one participant in the session generates an SDP message that
    constitutes the offer - the set of media streams and codecs the
    offerer wishes to use, along with the IP addresses and ports the
    offerer would like to use to receive the media.  The offer is
    conveyed to the other participant, called the answerer.  The answerer
    generates an answer, which is an SDP message that responds to the
    offer provided by the offerer.  The answer has a matching media
    stream for each stream in the offer, indicating whether the stream is
    accepted or not, along with the codecs that will be used and the IP
    addresses and ports that the answerer wants to use to receive media.

 From this, I am inclined to think that "multimedia session" is the 
intended meaning of "session".

Also, note that the above speaks specifically of *two* participants. I 
interpret this as meaning that it was written without consideration for 
multimedia sessions involving participants other than the offerer and 
the answerer.

I think we all agree that we now have common cases of O/A being used to 
join more than two participants into a multimedia session. But since it 
doesn't adequately consider this situation we have considerable 
ambiguity about how that should work. And work will be required to fix this.

> Given that we have a currently open revision of the SDP specification,
> it might be worth making a more robust definition by reference in that
> document.

Agreed.

	Thanks,
	Paul

> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *EXT Roman
> Shpount
> *Sent:* 03 March 2016 16:20
> *To:* Christer Holmberg
> *Cc:* Paul Kyzivat; [email-masked]
> *Subject:* Re: [MMUSIC] Offer/Answer PT Questions - text proposal
>
> On Thu, Mar 3, 2016 at 2:14 AM, Christer Holmberg
>      >> IF we agree that the PT binding is per session, and not per
>     direction, we can update that part of 3264, because THAT’s what
>     causing Martin’s issue.
>      >>
>      >> RFC 3264 might be slightly ambiguous about the answer since it
>     does not even define the "session", but it never states that binding
>     is per direction. It states
>      >> that binding MUST NOT change for the duration of a session with
>     no direction mentioned in this restriction. This mean we might need
>     a clarification but not necessarily an update.
>
>      >Bigger problem is that this requirement is unimplementable with
>     3pcc and routinely ignored. This is definitely a problem and needs
>     an update to resolve.
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 4 Mar 2016 14:13:07 -0500

> Note that RFC 7656 also gives the definition of RTP session.
I think RFC 7656 ignores existence of RTP mixers which makes large number
of its definitions, including RTP session, inaccurate.

Regards,
_____________
Roman Shpount

---

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Mar 2016 11:49:45 +0000

> On 4 Mar 2016, at 19:13, Roman Shpount <[email-masked]> wrote:
> 
> On Fri, Mar 4, 2016 at 7:28 AM, Drage, Keith (Nokia - GB) <[email-masked] <mailto:[email-masked]>> wrote:
> I think RFC 7656 ignores existence of RTP mixers which makes large number of its definitions, including RTP session, inaccurate.

To me, the definition of an RTP session in Section 2.2.2 of RFC 7656 looks accurate even accounting for RTP Mixers (as RTP mixer is defined in RFC 3550). 

Many RTP topologies use middleboxes that are not RFC 3550 compliant, so don’t fit with this definition of an RTP Session, but that’s a problem with they way those middleboxes are defined. RFC 7667 tries to identify some of these issues.

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

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Mon, 7 Mar 2016 01:00:54 +0000

This is my understanding as well.

It would be good to know what the starting point for Roman’s RTP mixers is – what does he think they conform to?

Keith

From: EXT Colin Perkins [mailto:[email-masked]]
Sent: 06 March 2016 11:50
To: Roman Shpount
Cc: Drage, Keith (Nokia - GB); [email-masked]; Paul Kyzivat; Christer Holmberg
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

On 4 Mar 2016, at 19:13, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Mar 4, 2016 at 7:28 AM, Drage, Keith (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
Note that RFC 7656 also gives the definition of RTP session.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Mar 2016 14:34:21 -0500

On Sun, Mar 6, 2016 at 8:00 PM, Drage, Keith (Nokia - GB) <
[email-masked]> wrote:

> *From:* EXT Colin Perkins [mailto:[email-masked]]
> *Sent:* 06 March 2016 11:50
> *To:* Roman Shpount
> *Cc:* Drage, Keith (Nokia - GB); [email-masked]; Paul Kyzivat; Christer
> Holmberg
> To me, the definition of an RTP session in Section 2.2.2 of RFC 7656 looks
> accurate even accounting for RTP Mixers (as RTP mixer is defined in RFC
> 3550).
>
>
>
> Many RTP topologies use middleboxes that are not RFC 3550 compliant, so
> don’t fit with this definition of an RTP Session, but that’s a problem with
> they way those middleboxes are defined. RFC 7667 tries to identify some of
> these issues.
>
I think I misread the RFC 7656 RTP Session definition as only containing
two SSRC at any give time. This was my mistake. RFC 7656 RTP Session
definition is correct.

Sorry for confusion and note to increase coffee intake on Fridays.
_____________
Roman Shpount