On Thu, Jun 29, 2017 at 8:32 AM, Daniel Tryba <dan...@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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users