VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
a_villacis at palosant... Guest
|
Posted: Wed Jun 18, 2014 1:44 pm Post subject: [asterisk-users] Making sense of SDP for debugging of missin |
|
|
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?
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
Back to top |
|
|
a_villacis at palosant... Guest
|
Posted: Fri Jun 20, 2014 1:27 pm Post subject: [asterisk-users] Making sense of SDP for debugging of missin |
|
|
El 18/06/14 13:44, Alex Villacís Lasso escribió:
Quote: | 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?
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
Back to top |
|
|
andres at telesip.net Guest
|
Posted: Fri Jun 20, 2014 1:48 pm Post subject: [asterisk-users] Making sense of SDP for debugging of missin |
|
|
Quote: | Quote: | 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
| I suggest you capture the audio stream with tcpdump. You can then
convert the payload data to audio and verify with any program that plays
audio files if indeed your PBX is not sending audio. My guess is it is
sending the audio just fine and the problem lies at the providers end.
--
Technical Support
http://www.cellroute.net
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
Back to top |
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|