Re: [MMUSIC] Offer/Answer PT Questions

["Drage, Keith (Nokia - GB)" <[e-mail]>]

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

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

Keith





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

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

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

	Thanks,
	Paul

> Regards
>
> Keith
>
> *From:*mmusic [mailto:[e-mail]] *On Behalf Of *EXT 
> Colin Perkins
> *Sent:* 23 February 2016 10:29
> *To:* Roman Shpount
> *Cc:* [e-mail]; Paul Kyzivat; Christer Holmberg
> *Subject:* Re: [MMUSIC] Offer/Answer PT Questions
>
>     On 22 Feb 2016, at 19:52, Roman Shpount <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
> …
>
> One thing that bothered me here is that PT cannot be reused for the 
> duration of the session. It is probably safe to reuse the PT after 
> session modification if PT is no longer used. I always felt that 
> dynamic PT reuse criteria were much stricter then realistically possible or needed.
>
> …
>
> I think the most important criteria here is that there should be no 
> ambiguity regarding how an RTP packet with particular PT should be 
> decoded. If it is guaranteed that there are no packets sent between 
> Alice and Bob with PT 111 over some reasonable time interval (couple 
> of network round trip times), then PT 111 can be safely reused. If, in 
> this scenario Bob's end point knows that it was not sending anything 
> with payload 111 recently, then it can safely reuse this payload. 
> Alice could not be sending anything with payload 111 since Bob did not 
> accept it previously. On the other hand, Bob must not reuse PT 100 
> for, let's say, CN, since there are packets with this payload in 
> flight and this will create decoding ambiguity. To conclude, an end 
> point should be able to safely reuse any PT that it is not currently 
> accepting or was not sending or accepting for at least a few network round trip intervals.
>
> No objection in principle, but it’s not as simple as “a few network RTTs”:
>
> No ambiguity in decoding means that the packets need to have been 
> played out, so the codec state for that PT can be discarded. Some 
> systems can have large (multi-second) playout buffers.
>
> Any packets referring to the old PT also need to be gone. Formats like 
> RFC 6354 allow large offsets between streams, referenced by PT (the 
> example in Section 5 has a 5.1 second offset).
>
> --
>
> Colin Perkins
>
> https://csperkins.org/
>