Mark Lynch | 19 Aug 01:30

Curly Asterisk <-> Voxbone problem

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

_______________________________________________
--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

Gmane