[asterisk-users] DMTF payload bug in 13.14.1 with pjsip and direct_media?

[Richard Mudgett]

On Thu, Jun 29, 2017 at 8:32 AM, Daniel Tryba <daniel at tryba.nl> wrote:

> While trying to use direct_media I'm seeing RTP payload mismatches after
> succesful reinvites.
>
> Initial INVITE from endpoint A to asterisk has rfc4733 DMTF
> m=audio 35648 RTP/AVP 9 8 111 96
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
>
> From asterisk to upstream U:
> m=audio 14338 RTP/AVP 9 8 111 18 0 101
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
>
> So the payload types in the RTP streams from A and to U differ. This
> works fine when asterisk is relaying media.
>
> With direct_media=yes there are reinvites sent from asterisk to both A
> and U. The invite to A contains:
> c=IN IP4 ipaddrofU
> m=audio 33142 RTP/AVP 8 96
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
>
> And the invite to U contains:
> c=IN IP4 ipaddrofA
> m=audio 35648 RTP/AVP 9 8 111 101
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
>
> Both sides respond with a 200 OK and asterisk is not
> relaying/transcoding the media anymore. At this moment DTMF send from A
> isn't getting recognized by U, which IMHO is totally understandable
> since U doesn't know about payload 96.
>
> To me this looks like a bug in asterisk. Either asterisk should use the
> same rtp payloads for telephone-events on both call legs during inital
> callsetup or asterisk should come to the conclusion there is an
> incompatible "codec" on both legs so it shouldn't switch to direct
> media.
>
> Has anyone else seen this issue?
>

This is an old issue.  One of the latest issues is:

https://issues.asterisk.org/jira/browse/ASTERISK-25166

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20170629/b84b09f9/attachment.html>