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

[Paul Kyzivat <[e-mail]>]

On 2/25/16 6:19 PM, Colin Perkins wrote:
> Hi,
>
>> On 25 Feb 2016, at 14:17, Christer Holmberg <[e-mail]> wrote:
>>
>> Hi,
>>
>> I put together some text:
>>
>> "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.
>
> I think this conflicts with various RTP-related RFCs and drafts, although whether this conflict causes practical problems is unclear. RFC 3551 indicates that the binding between RTP payload type and RTP payload format is per RTP session, not per sender within an RTP session:
>
>     mechanisms for defining dynamic payload type bindings have been
>     specified in the Session Description Protocol (SDP) and in other
>     protocols such as ITU-T Recommendation H.323/H.245.  These mechanisms
>     associate the registered name of the encoding/payload format, along
>     with any additional required parameters, such as the RTP timestamp
>     clock rate and number of channels, with a payload type number.  This
>     association is effective only for the duration of the RTP session in
>     which the dynamic payload type binding is made.  This association
>     applies only to the RTP session for which it is made, thus the
>     numbers can be re-used for different encodings in different sessions
>     so the number space limitation is avoided.
>
> (note: reuse in different sessions, not different participants within a session) and:

Does a sendrecv m-line established via O/A create one or two RTP sessions?

If one, then it seems this conflicts with 3264 allowing the two ends to 
use different PTs for the same codec configuration.

It always seemed to me that the original intent was to require the same 
PT number on both ends (perhaps because of what you quote), and that 
allowing the two ends to be different was an afterthought. If so, it may 
be that rfc3551 should have been updated.

Is there any *technical* difficulty when the two ends use different PTs? 
(E.g. does it screw up rtcp reports?)

We are starting to get to the meat of the issue. The question is: what 
needs to be fixed?

	Thanks,
	Paul