Daniel Tryba
2017-Jun-29 13:32 UTC
[asterisk-users] 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?
Richard Mudgett
2017-Jun-29 16:55 UTC
[asterisk-users] DMTF payload bug in 13.14.1 with pjsip and direct_media?
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>
Daniel Tryba
2017-Jun-29 19:19 UTC
[asterisk-users] DMTF payload bug in 13.14.1 with pjsip and direct_media?
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-25166I 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).
Maybe Matching Threads
- Grandstream firmware update DMTF Payload Type
- [RFC] Replacing inalloca with llvm.call.setup and preallocated
- Asterisk switching bridge to native_rtp even with direct_media=no
- Asterisk switching bridge to native_rtp even with direct_media=no
- [RFC] Replacing inalloca with llvm.call.setup and preallocated