Problem with SIP trunk & NAT, read all the posts I could fin

[vitchie]

Hi guys

I'm really having a hard time getting my SIP trunk to provider to work. It is getting natted through a Mikrotik Router with the SIP helper switched off. I'm not sure if the problem is NAT related or codec related. I get 2 way audio on the one call, then next call only 1 way. No really pattern. Here is an extract from CLI SIP Debug

196.28.95.12 is my provider's IP
192.168.3.32 is my asterisk server's ip
192.168.3.20 is the Atcom AT640P handset trying to make the call.

<------------->
[2012-06-29 00:47:09] VERBOSE[5542] chan_sip.c: --- (8 headers 0 lines) ---
[2012-06-29 00:47:09] VERBOSE[5542] chan_sip.c: list_route: no route
[2012-06-29 00:47:09] VERBOSE[5586] app_dial.c: -- SIP/MWEB-00000007 is ringing
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c:
<--- SIP read from UDP:196.28.95.12:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5060;received=41.133.161.26;branch=z9hG4bK1544db9f;rport=5060
From: "27100070561" ;tag=as7882c23a
To: ;tag=jxqd4p6sf76rjvux.i
Call-ID: 0b4f0ae4267c77051c3f84051afeac26@sip.mweb.net
CSeq: 103 INVITE
Contact: "Anonymous"
Content-Type: application/sdp
Server: Sippy
Content-Length: 196

v=0
o=Sippy 166232648 1 IN IP4 196.28.95.12
s=-
t=0 0
m=audio 14012 RTP/AVP 0 101
c=IN IP4 196.28.95.12
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
<------------->
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: --- (10 headers 10 lines) ---
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: Found RTP audio format 0
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: Found RTP audio format 101
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: Found audio description format PCMU for ID 0
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: Found audio description format telephone-event for ID 101
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x4 (ulaw)
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: Peer audio RTP is at port 196.28.95.12:14012
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: list_route: hop:
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: set_destination: Parsing for address/port to send to
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: set_destination: set destination to 196.28.95.12:5060
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: Transmitting (NAT) to 196.28.95.12:5060:
ACK sip: 0800414141@196.28.95.12:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK34da7a42;rport
Max-Forwards: 70
From: "27100070561" ;tag=as7882c23a
To: ;tag=jxqd4p6sf76rjvux.i
Contact:
Call-ID: 0b4f0ae4267c77051c3f84051afeac26@sip.mweb.net
CSeq: 103 ACK
User-Agent: FPBX-2.10.0rc1(1.8.11)
Content-Length: 0

---
[2012-06-29 00:47:12] VERBOSE[5586] app_dial.c: -- SIP/MWEB-00000007 answered SIP/001-00000006
[2012-06-29 00:47:12] VERBOSE[5586] chan_sip.c: Audio is at 16026
[2012-06-29 00:47:12] VERBOSE[5586] chan_sip.c: Adding codec 0x4 (ulaw) to SDP
[2012-06-29 00:47:12] VERBOSE[5586] chan_sip.c: Adding codec 0x8 (alaw) to SDP
[2012-06-29 00:47:12] VERBOSE[5586] chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP
[2012-06-29 00:47:12] VERBOSE[5586] chan_sip.c:
<--- Reliably Transmitting (no NAT) to 192.168.3.20:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.3.20:5060;branch=z9hG4bK12911154352360027890;received=192.168.3.20;rport=5060
From: Study ;tag=279814915
To: " 0800414141" ;tag=as1a70942f
Call-ID: 106951818227569-20832660225131@192.168.3.20
CSeq: 2 INVITE
Server: FPBX-2.10.0rc1(1.8.11)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact:
Content-Type: application/sdp
Content-Length: 265

v=0
o=root 1373573186 1373573186 IN IP4 192.168.3.32
s=Asterisk PBX 1.8.11-cert1
c=IN IP4 192.168.3.32
t=0 0
m=audio 16026 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

<------------>
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c:
<--- SIP read from UDP:192.168.3.20:5060 --->
ACK sip: 0800414141@192.168.3.32:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.20:5060;branch=z9hG4bK306571853116117059
From: Study ;tag=279814915
To: "0800414141" ;tag=as1a70942f
Call-ID: 106951818227569-20832660225131@192.168.3.20
CSeq: 2 ACK
Max-Forwards: 70
User-Agent: Voip Phone 1.0
Content-Length: 0

<------------->
[2012-06-29 00:47:12] VERBOSE[5542] chan_sip.c: --- (9 headers 0 lines) ---
[2012-06-29 00:47:18] VERBOSE[5542] chan_sip.c: Really destroying SIP dialog '20d21dd2607dfddd19de9a695ed45ec6@192.168.3.32' Method: REGISTER
[2012-06-29 00:47:18] VERBOSE[5542] chan_sip.c: Really destroying SIP dialog '453572874edc81056e12d24b05e68e50@192.168.13.2:5060' Method: OPTIONS
[2012-06-29 00:47:18] VERBOSE[5542] chan_sip.c: Really destroying SIP dialog '04f1ba6e3ef050cb35348ece4186e4c7@192.168.3.32' Method: REGISTER
[2012-06-29 00:47:21] VERBOSE[5542] chan_sip.c:
<--- SIP read from UDP:192.168.3.20:5060 --->
REGISTER sip:192.168.3.32 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.20:5060;branch=z9hG4bK2486058092197811944;rport
From: Study ;tag=162145220
To: Study
Call-ID: 103891470664-159592744717996@192.168.3.20
CSeq: 583 REGISTER
Contact:
Max-Forwards: 70
Expires: 60
Supported: path
User-Agent: Voip Phone 1.0
Content-Length: 0

<------------->

[david55]

Without the outging INVITE, it is difficult to tell.

I don't like the number of empty fields in Contact, From and To headers, but both sides seem happy with that.

There is generally a direction associated with one way audio!

[vitchie]

It works intermittently

Here is a log of a successful call:

https://www.dropbox.com/s/7pvzsgtsnrra1 ... orking.txt

And here is an unsuccessful call shortly afterwards

https://www.dropbox.com/s/d2lmgauy99a92 ... orking.txt

[david55]

You are transmitting 127.0.0.1 (local loop back) as your SIP contact and RTP media address. That is very broken.

One guess might be that you have defined externhost, but then have a /etc/hosts entry mapping it to 127.0.0.1. I think we need to see sip.conf and any line in /etc/hosts that references 127.0.0.1.

Note that 127.0.0.1 should not appear in sip.conf.

[vitchie]

Thanks David, i removed the 127.0.0.1 entry for my ddns domain from etc/hosts. Can you look at the debug traces above from dropbox, there are details from 1 successful call and another unsuccessful one.

Really appreciate your help!

[david55]

If you have two different IP addresses, DNS is likely to choose them randomly, or on a round robin basis.

[vitchie]

I only have one public IP, it changes max once a day, and it definitely didn't change between these 2 calls.

[david55]

You already said that you had two addresses. One of them was 127.0.0.1, which should never appear on a public DNS server.