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

[Roman Shpount <[e-mail]>]

On Fri, Feb 26, 2016 at 12:34 PM, Colin Perkins <[e-mail]> wrote:

>
> On 26 Feb 2016, at 17:06, Roman Shpount <[e-mail]> wrote:
>
> On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins <[e-mail]> wrote:
>
>> That depends exactly what 3264 allows: if the two ends use different
>> payload types to refer to the same codec, that’s okay; but if the two ends
>> use the same payload type to refer to different codecs, that problematic.
>>
>
> Why is using the same PT to refer to different codecs is problematic? Can
> you point out any potential problems that this will cause from RTP
> perspective?
>
>
> If I receive a packet with payload type X, how do I know which of the
> codecs it refers to?
>
> You’d have to make the PT mapping per SSRC, but the SSRCs can change
> without signalling, so that doesn’t help unless you somehow label the RTP
> stream with a header extension that says what payload type space it’s
> using.
>
> The entire point of the PT is that it uniquely identifies a codec
> configuration.
>

Why does PT needs to be unique in both directions (entire RTP session) vs
unique in each direction? Having a unique PT in each direction is enough to
unambiguously decode the packet. SSRC might change but the packet flow
direction is well known when the packet is received.

P.S. I am, of cause, talking about unicast sessions only.
_____________
Roman Shpount