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

[Paul Kyzivat <[e-mail]>]

On 2/26/16 11:04 AM, Colin Perkins wrote:

>> So it means that we have to say that the appearance of a PT in an offer or answer binds it to the corresponding codec configuration for the duration of the RTP session. An answerer can still choose to use a different PT for the same codec configuration. But he can’t use a PT that has already been bound.
>
> Yes.
>
>> Can we require a sender to honor the preference of the recipient in this regard? (For two-participant sessions - the kind we are usually setting up with O/A.)
>
> That’s one for the signalling to decide.

Would it be ok for us to say that a sender of RTP in a RTP session 
established using O/A MUST only use bindings specified in the most 
recent offer or answer from that recipient?

>> But an important point to this is that this binding is scoped by the RTP session, not the SIP (or O/A) session. So when the RTP session changes (because the addr/port changes at one of the ends) then old bindings no longer need to be preserved.
>>
>> And *that* solves the 3pcc problem, since in the 3pcc cases that matter the RTP session will change.
>
> Perhaps, but remember that an RTP session is defined by a shared SSRC space, not by the addresses or ports used, so it depends how 3PCC moves the addresses.

OK. Then we need more words. ISTM that at least for unicast O/A, each 
time an addr/port changes we establish a new SSRC space.

There might be exceptions to this. For instance a mixer in a star 
configuration. In principle that could be used to bring another 
participant into a preexisting RTP session. But the only way I can see 
that could work in practice is for the mixer to send the first offer, 
and to enumerate all of the existing PT mappings. And of course the new 
participant won't be aware of existing SSRCs in use either.

Again, I think this is going to be hard to specify. A *lot* more needs 
to be said than is currently in 3264.

(And multicast O/A is a whole separate question. I don't even want to 
*think* about that right now.)

>> As a side question, how do the predefined PTs fit into this? My guess is that the predefined PTs are *not* implicitly bound. They still must be bound by appearing in an offer or answer. And then they are only bound to their default codec configuration if there is no explicit rtpmap for the PT.
>
> The use is defined by the signalled RTP profile. If an RTP/AVP-derived profile is used, the text in RFC 3551 applies:
>
>     This profile reserves payload type numbers in the range 96-127
>     exclusively for dynamic assignment.  Applications SHOULD first use
>     values in this range for dynamic payload types.  Those applications
>     which need to define more than 32 dynamic payload types MAY bind
>     codes below 96, in which case it is RECOMMENDED that unassigned
>     payload type numbers be used first.  However, the statically assigned
>     payload types are default bindings and MAY be dynamically bound to
>     new encodings if needed.  Redefining payload types below 96 may cause
>     incorrect operation if an attempt is made to join a session without
>     obtaining session description information that defines the dynamic
>     payload types.
>
> i.e., the fact that the m= line says RTP/AVP implies that the default static payload type mappings are valid, unless over-ridden by an a=rtpmap: line.

I *think* what you said confirms what I was guessing.

	Thanks,
	Paul