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

[Christer Holmberg <[e-mail]>]

Hi,

>> "The scope of a mapping from a particular dynamic payload type number 
>> to a codec (or codec configuration) is for a given RTP media flow direction within a session.
>
> Albrecht raised the question of terminology and of whether "RTP media flow direction" is the right term. I think the concept
> is specific to O/A. In 7656 terms I think it applies to all RTP streams with a particular PT flowing in a single direction between 
> two participants in one RTP Session.

We need to look whether there is existing terminology in 3264, in which case we should use that (or update every instance of the terminology within 3264...)

>> The same dynamic payload type number can be mapped to another codec in 
>> another RTP media flow direction within the same session. The mapping 
>> MUST NOT change to a different coded (or coded configuration) for the 
>> duration of a session. Eventhough not recommended, for a given 
>> direction, multiple dynamic payload type numbers can be mapped to the same codec (or codec configuration).
>>
>> Note that a mapping has been created once an endpoint has sent and 
>> offer or answer, describing the mapping for a given direction. Even if 
>> the offer or answer is rejected or discarded, or if RTP media 
>> associated with the mapping is never sent, the mapping MUST NOT change for the given direction within the session.
>
> The paragraph above seems overly strict. Surely it should not be necessary to retain the mapping if the entire offer is rejected. (There isn't any way to reject an answer.)

Sometimes strict is good :) But, I'm not religious about it, as long as the text is clear on when the mapping has been created.

> Similarly, if the m-line is rejected (port zero) ISTM that all bindings could be forgotten. (I guess in this case the RTP Session ends so "within the session" covers it.)

What if an m- line is disabled, using port zero in an *offer*, and later taken back in use? Are the previous mappings still valid? In my opinion they are.


>> Within an offer or answer, the mapping is for the RTP media flow 
>> direction towards the offerer/answerer, unless the media flow is 
>> indicated as 'sendonly' in which case the mapping is for the media flow direction from the offerer/answerer."
>
> ISTM that no bindings should be created for sendonly m-lines. (AFAIK the PT mentioned in a sendonly offer/answer never appears on the wire in
> RTP/RTCP.)

So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply with PT 111:PCMU? Both are associated with the same media flow direction, as the offer was sendonly.

Regards,

Christer



OTOH, as a session is modified (by additional O/As), bindings need to be retained even if sendonly is sometimes used.

	Thanks,
	Paul

> Note that the text probably needs some fine tuning, but please take a look and see whether you are ok with the approach, and whether you think the text covers the issues we've discovered.
>
> Regards,
>
> Christer
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic