Alex Villacís Lasso
2014-Jun-18 18:44 UTC
[asterisk-users] Making sense of SDP for debugging of missing audio in SIP trunk
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?
Alex Villacís Lasso
2014-Jun-20 18:27 UTC
[asterisk-users] Making sense of SDP for debugging of missing audio in SIP trunk
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?