asterisk users - Jun 2017 - DMTF payload bug in 13.14.1 with pjsip and direct_media?

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?

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>

On Thu, Jun 29, 2017 at 11:55:51AM -0500, Richard Mudgett
wrote:
> > 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
I was looking DTMF related problems and found none. Looks like it is a
more general issue related to all capabilities. Thank you for pointing
this out. 

Seeing the history of the bugs the problem and the full fix is larger
than I initially thought. Maybe a quick stopgap is to just not try to
setup direct media if there are numeric differences between call legs
(this would help me since most call would be direct media, I'll try to
look into this is I have the time to look into this and find out if I
have enough knowlegde to try something).