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?