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

[Paul Kyzivat <[e-mail]>]

On 2/25/16 1:32 PM, Christer Holmberg wrote:
> 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...)

Sounds good.

>>> 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.

I agree about being clear. IMO we should try not to impose unnecessary 
restrictions. But if being a little stricter than necessary greatly 
simplifies the rules then it is worth considering.

>> 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.

Once you have used port zero the RTP session is *gone*. If you then 
recycle the m-line with a valid addr/port you are establishing a *new* 
RTP session, so the old bindings are gone and you start building a new set.

>>> 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.

The following from 3264 applies in this case:

    For streams marked as recvonly in the answer, the "m=" line MUST
    contain at least one media format the answerer is willing to receive
    with from amongst those listed in the offer.  The stream MAY indicate
    additional media formats, not listed in the corresponding stream in
    the offer, that the answerer is willing to receive.

So if you *only* offered PT 111:VP8, then the answer MUST include VP8. 
(Preferably with PT 111, but it could be some other PT.) It could *also* 
include PCMU. So PT 110:VP8, PT 111:PCMU would be valid.

If I can't accept VP8, then I guess I have to either reject the m-line 
or else reject the offer.

IMO the MUST is too restrictive. It ought to be SHOULD. But changing 
that is a separate issue.

	Thanks,
	Paul

> 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
>