[asterisk-users] Making sense of SDP for debugging of missing audio in SIP trunk

[Alex Villací­s Lasso]

I am debugging an intermittent issue of missing audio on calls that come from a SIP provider into our asterisk-11.10 installation. Sometimes, incoming calls from this provider work correctly, with audio streaming in both directions. Other times, with the 
same setup, the calling party is unable to hear the IVR recording from the asterisk installation, although in fact the streaming is supposed to have started. When debugging with tcpdump, I have seen that all the successful calls have SDP negotiation that 
look like this:

(inside INVITE request body from SIP carrier)
v=0
o=msw.chance4minutes.net 1234 0 IN IP4 38.126.208.46
s=sip call
c=IN IP4 38.126.208.46
t=0 0
m=audio 30552 RTP/AVP 18 0 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

(inside 200 OK response body from asterisk)
v=0
o=root 835643920 835643920 IN IP4 201.234.196.171
s=Asterisk PBX 11.10.0
c=IN IP4 201.234.196.171
t=0 0
m=audio 12112 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=nortpproxy:yes


In contrast, all failing calls have SDP negotiation that looks like this:

(inside INVITE request body from SIP carrier)
v=0
o=msw.chance4minutes.net 1234 0 IN IP4 38.126.208.46
s=sip call
c=IN IP4 38.126.208.46
t=0 0
m=audio 30534 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=sendrecv

(inside 200 OK response body from asterisk)
v=0
o=root 1719775538 1719775538 IN IP4 201.234.196.171
s=Asterisk PBX 11.10.0
c=IN IP4 201.234.196.171
t=0 0
m=audio 11678 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendrecv
a=nortpproxy:yes

Apart from this, I see RTP packets being exchanged in both directions in both scenarios.

 From what I can see, the SIP provider sends packets that differ in that the following four properties are present in the successful case and missing in the failing case:
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=maxptime:20

What can I deduce from this? Is there some configuration on my asterisk that can be tweaked so the failing requests can be handled properly?