Re: [MMUSIC] Offer/Answer PT Questions

Hi,

I have to say that I don't understand the connection with declarative use either.

First, declarative use is not a negotiation - there is no offer and answer.

Second, if I send a declarative SDP now, and a second one later, there are no rules saying that the second one has to be dependent on the first one. The number of m- lines can be different, properties associated with the m- lines can be different, PT/codec mappings can be different. Etc etc etc etc.

We are not trying to change the basic SDP semantics - we are trying to clarify the semantics and rules associated with Offer/Answer.

Regards,

Christer 

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 25 February 2016 00:54
To: mmusic@ietf.org
Subject: 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
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic