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

[Alex Villací­s Lasso]

El 18/06/14 13:44, Alex Villací­s Lasso escribió:
> 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?
>

Is there additional information needed to make sense of this scenario?