19 Aug 01:30
Curly Asterisk <-> Voxbone problem
From: Mark Lynch <mark <at> learnosity.com>
Subject: Curly Asterisk <-> Voxbone problem
Newsgroups: gmane.comp.telephony.pbx.asterisk.devel
Date: 2008-08-18 23:32:11 GMT
Subject: Curly Asterisk <-> Voxbone problem
Newsgroups: gmane.comp.telephony.pbx.asterisk.devel
Date: 2008-08-18 23:32:11 GMT
Hi All,
I've been pulling my hair out over this problem and hopefully someone on this list will be able to help.
Here is the situation:
Staging:
I've had an asterisk staging machine set up for a couple of months in preparation for going live with a project. It is running Ubuntu Server 8.04 x86 with asterisk 1.4.17-dfsg.2ubuntu1
It is connected via voxbone to the PSTN network and everything is working fine.
Production:
I have just installed our production box which is on a different network but is connected straight to the internet - no firewalls etc.
It is running Ubuntu Server 8.04 amd64 with asterisk 1.4.17-dfsg.2ubuntu1 and an identical configuration (I copied all the files across directly as part of debugging this problem)
I can connect to this box via sip - and I can see the call happening but the rtp is going to the wrong destination.
I have be working with voxbone to try to resolve this but it looks like the asterisk server on the production machine is not responding correctly with it's RTP streams. The voxbone number is part of their new configuration where the SIP connection comes from a central SBC server (81.201.82.39) but the RTP is transmitted to and from the local POP - in snippet below from working server (81.201.84.141).
When connections are coming to the Production box it is incorrectly sending the RTP traffic to the sip originating box, i.e.81.201.82.39 instead 81.201.84.141 and so no audio is working.
NOTE: I am using the exact same voxbone number - I have reconfigured it between tests to see if it was a problem with their new configuration but my staging machine seems to work perfectly but the production one does not.
Questions from this are:
- Could this be a problem with the AMD64 build or is this very unlikely.
- How can I get more information to debug this better?
- Could this possibly be a bug in asterisk only on AMD64 builds?
I've attached some traces from the calls below:
RTP data flow from working server:
17.328338 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19838, Time=32000
17.348335 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19839, Time=32160
17.368336 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19840, Time=32320
17.388337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19841, Time=32480
17.408337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19842, Time=32640
17.428337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19843, Time=32800
But the RTP data from the production (non working) server sends the RTP to 81.201.82.39
9.673564 81.201.82.39 -> 63.138.188.91 SIP/SDP Request: INVITE sip:61390015580 <at> 63.138.188.91, with session description
9.673961 63.138.188.91 -> 81.201.82.39 SIP Status: 100 Trying
9.674207 63.138.188.91 -> 81.201.82.39 SIP/SDP Status: 200 OK, with session description
9.918465 81.201.82.39 -> 63.138.188.91 SIP Request: ACK sip:61390015580 <at> 63.138.188.91
10.716189 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34349, Time=160
10.735624 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34350, Time=320
10.755612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34351, Time=480
10.775612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34352, Time=640
10.795612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34353, Time=800
10.799790 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.815611 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34354, Time=960
10.818728 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.835608 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34355, Time=1120
10.839226 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.855605 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34356, Time=1280
10.859224 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.875612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34357, Time=1440
10.879217 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.895612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34358, Time=1600
10.899216 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.915610 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34359, Time=1760
10.935609 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34360, Time=1920
10.955611 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34361, Time=2080
Any help or suggestions greatly appreciated.
Thanks,
Mark
--
OnScreen and Voice Learning and Assessment
www.learnosity.com
I've been pulling my hair out over this problem and hopefully someone on this list will be able to help.
Here is the situation:
Staging:
I've had an asterisk staging machine set up for a couple of months in preparation for going live with a project. It is running Ubuntu Server 8.04 x86 with asterisk 1.4.17-dfsg.2ubuntu1
It is connected via voxbone to the PSTN network and everything is working fine.
Production:
I have just installed our production box which is on a different network but is connected straight to the internet - no firewalls etc.
It is running Ubuntu Server 8.04 amd64 with asterisk 1.4.17-dfsg.2ubuntu1 and an identical configuration (I copied all the files across directly as part of debugging this problem)
I can connect to this box via sip - and I can see the call happening but the rtp is going to the wrong destination.
I have be working with voxbone to try to resolve this but it looks like the asterisk server on the production machine is not responding correctly with it's RTP streams. The voxbone number is part of their new configuration where the SIP connection comes from a central SBC server (81.201.82.39) but the RTP is transmitted to and from the local POP - in snippet below from working server (81.201.84.141).
When connections are coming to the Production box it is incorrectly sending the RTP traffic to the sip originating box, i.e.81.201.82.39 instead 81.201.84.141 and so no audio is working.
NOTE: I am using the exact same voxbone number - I have reconfigured it between tests to see if it was a problem with their new configuration but my staging machine seems to work perfectly but the production one does not.
Questions from this are:
- Could this be a problem with the AMD64 build or is this very unlikely.
- How can I get more information to debug this better?
- Could this possibly be a bug in asterisk only on AMD64 builds?
I've attached some traces from the calls below:
RTP data flow from working server:
17.328338 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19838, Time=32000
17.348335 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19839, Time=32160
17.368336 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19840, Time=32320
17.388337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19841, Time=32480
17.408337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19842, Time=32640
17.428337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19843, Time=32800
But the RTP data from the production (non working) server sends the RTP to 81.201.82.39
9.673564 81.201.82.39 -> 63.138.188.91 SIP/SDP Request: INVITE sip:61390015580 <at> 63.138.188.91, with session description
9.673961 63.138.188.91 -> 81.201.82.39 SIP Status: 100 Trying
9.674207 63.138.188.91 -> 81.201.82.39 SIP/SDP Status: 200 OK, with session description
9.918465 81.201.82.39 -> 63.138.188.91 SIP Request: ACK sip:61390015580 <at> 63.138.188.91
10.716189 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34349, Time=160
10.735624 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34350, Time=320
10.755612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34351, Time=480
10.775612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34352, Time=640
10.795612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34353, Time=800
10.799790 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.815611 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34354, Time=960
10.818728 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.835608 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34355, Time=1120
10.839226 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.855605 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34356, Time=1280
10.859224 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.875612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34357, Time=1440
10.879217 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.895612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34358, Time=1600
10.899216 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
10.915610 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34359, Time=1760
10.935609 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34360, Time=1920
10.955611 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34361, Time=2080
Any help or suggestions greatly appreciated.
Thanks,
Mark
--
OnScreen and Voice Learning and Assessment
www.learnosity.com
_______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RSS Feed