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

[Roman Shpount <[e-mail]>]

On Thu, Feb 25, 2016 at 1:23 PM, Christer Holmberg <
[e-mail]> wrote:

> >>"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.
> >>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).
> >
> > I think MUST NOT is too strict for this rule and SHOULD NOT should be
> sufficient. In current implementation this
> > rule is often ignored. The worst thing that can happen is a small media
> disruption, but with the careful
> > implementation, even that will not occur in most use cases.
>
> There may also be implementations that DO implement the rule. SHOULD NOT
> means that endpoints have to be prepared to handle it.
>

I guess what I am trying to say is these implementations really should not
be enforcing this rule. There is no technical reason for strict enforcement
and this will break things during the interop.


> Is there really a reason why we should allow it?
>

It is impossible to implement 3pcc with this rule in place.
_____________
Roman Shpount