Re: [MMUSIC] Offer/Answer PT Questions

On 2/24/16 5:13 PM, Drage, Keith (Nokia - GB) wrote:
> 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.

I have never tried to understand the declarative use (other than in 
OPTIONS, which clearly *isn't* describing a session.) It is my 
impression that SAP hasn't been used for a very long time.

If somebody who understands and cares about it would like to help then 
maybe we can see that we don't break that.

	Thanks,
	Paul

> Keith
>
>
>
>
>
> -----Original Message-----
> From: EXT Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: 23 February 2016 15:37
> To: Drage, Keith (Nokia - GB); EXT Colin Perkins; Roman Shpount
> Cc: mmusic@ietf.org; 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:mmusic-bounces@ietf.org] *On Behalf Of *EXT
>> Colin Perkins
>> *Sent:* 23 February 2016 10:29
>> *To:* Roman Shpount
>> *Cc:* mmusic@ietf.org; Paul Kyzivat; Christer Holmberg
>> *Subject:* Re: [MMUSIC] Offer/Answer PT Questions
>>
>>      On 22 Feb 2016, at 19:52, Roman Shpount <roman@telurix.com
>>      <mailto:roman@telurix.com>> 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/
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>