[asterisk-dev] Curly Asterisk <-> Voxbone problem

[Mark Lynch]

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 <sip%3A61390015580 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 <sip%3A61390015580 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080819/50b26b3e/attachment.htm