gmane.comp.telephony.pbx.asterisk.devel

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

headers

Mark Lynch | 19 Aug 01:32

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

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

headers

Mark Lynch | 19 Aug 09:41

Re: Curly Asterisk <-> Voxbone problem

Voxbone have send me some more details on what they are seeing when a call is made.

The good machine is setting the following
c=IN IP4 203.206.181.174.

whereas the bad machine is setting:
c=IN IP4 81.201.82.39.

Which seems very wrong. I've tried pretty much everything I can think of - any clever ideas I could try before I rebuild the machine with i386 version?

-- Message from voxbone --

Now looking at the traces I took for both the good equipment 203.206.181.174 vs the bad equipment 63.138.188.91, it seems your are telling your equipment to send RTP to our SBC server. Here is the 200 OK messages you are sending to us:

Good equipment 203.206.181.174

U 203.206.181.174:5060 -> 81.201.82.39:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 81.201.82.39:5060;branch=z9hG4bK0caef7a1b9d235f5282b5358e028689d;received=81.201.82.39.
From: "anonymous" <sip:0 <at> voxbone.com>;tag=37387.
To: <sip:61390015580 <at> 203.206.181.174>;tag=as4e5b9cf8.
Call-ID: 73192f5a181daa0d4f28e96c4fb077e2 <at> 81.201.82.39.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Contact: <sip:61390015580 <at> 203.206.181.174>.
Content-Type: application/sdp.
Content-Length: 268.
.
v=0.
o=root 4719 4719 IN IP4 203.206.181.174.
s=session.
c=IN IP4 203.206.181.174.
t=0 0.
m=audio 10892 RTP/AVP 8 0 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

Bad Equipment:

U 63.138.188.91:5060 -> 81.201.82.39:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 81.201.82.39:5060;branch=z9hG4bK955740fe5bd279f8512f98257acde109;received=81.201.82.39.
From: "anonymous" <sip:0 <at> voxbone.com>;tag=86815.
To: <sip:61280147490 <at> 63.138.188.91>;tag=as587bc4c0.
Call-ID: 0889d6eabd1218a4bb8052349b347f71 <at> 81.201.82.39.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Contact: <sip:61280147490 <at> 63.138.188.91>.
Content-Type: application/sdp.
Content-Length: 263.
.
v=0.
o=root 6299 6299 IN IP4 63.138.188.91.
s=session.
c=IN IP4 81.201.82.39.
t=0 0.
m=audio 16674 RTP/AVP 8 0 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

Please look at the c=IN IP4 section, (connection information), for the good equipment your are telling us to send audio to 203.206.181.174 while on the bad equipment you are telling us to send audio to 81.201.82.39 which RTP is not supported. Please make the appropriate changes on your side. Thank you.

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