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

[Colin Perkins <[e-mail]>]

> On 29 Feb 2016, at 21:28, Christer Holmberg <[e-mail]> 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.
>>> 
>>> 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
>> *remember* bindings from prior RTP sessions that shared the same m-line.
> 
> 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?

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




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



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