[asterisk-dev] Dynamic Payloads

[Kevin Harwell]

Alexander, thanks for the reply!

I'm going to move forward with using the original static values as defaults
in order to hopefully minimize any issues.

Currently what I am thinking is when a dynamic payload type needs an
assignment it will first check to see if a default value exists for it. If
so, then use that unless another dynamic payload type has already claimed
it (which hopefully won't happen too often).

On Thu, Mar 16, 2017 at 4:31 AM, Alexander Traud <pabstraud at compuserve.com>
wrote:

> > Is there any advantage to falling back to [the currently used] numbers
> as defaults for a given format?
>
> If the remote party cares about a dynamic RTP payload type number but
> ignores its "=rtpmap:", this is a software bug for sure [1][2][3].
> Consequently, you are asking whether SIP/SDP implementations are known
> which are still in use and contain such a software bug.
>
> Yes, I know such an implementation, released last year by a company in the
> SIP market since day one. If I use another number in the range 96-127, I
> face no audio on incoming calls at that phone (and then it must be
> restarted to continue to do any audio). I have to use exactly the type
> number expected by that phone. This bug was reported and is confirmed.
> Although this is a severe bug, a resolution is questionable. Therefore,
> yes, I see an advantage.
>
> [1] <https://tools.ietf.org/html/rfc4566#section-5.14> sub-field <fmt>
> [2] <https://tools.ietf.org/html/rfc4566#section-6> attribute =rtpmap:
> [3] <https://tools.ietf.org/html/rfc4566#section-8.2.3>
>
>
>
-- 

Kevin Harwell
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170316/73c1f8a6/attachment.html>