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

[Colin Perkins <[e-mail]>]

> On 1 Mar 2016, at 18:23, Roman Shpount <[e-mail]> wrote:
> 
> On Tue, Mar 1, 2016 at 12:00 PM, Paul Kyzivat <[e-mail] <mailto:[e-mail]>> 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. 

Agree.

> 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?
> 
> 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.
> 
> 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
>  
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic



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