[SR-Users] Help debugging a missing ACK (is Asterisk covering up a mistake in my Kamailio config?)

Daniel-Constantin Mierla miconda at gmail.com
Mon Sep 1 12:15:11 CEST 2014


On 29/08/14 23:58, Andres wrote:
> On 8/29/14, 1:42 PM, Alex Villací­s Lasso wrote:
>> Please consider the following SIP packet exchange, as seen by a 
>> tcpdump running on 201.234.196.170. Here 198.58.101.75 initiates a 
>> call to 201.234.196.170:
>>
>> IP 198.58.101.75.5060 > 201.234.196.170.5060
>> INVITE sip:*43 at 201.234.196.170:5060 SIP/2.0
>> Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK7a792c1e;rport
>> Max-Forwards: 70
>> From: "9002" <sip:9002 at 198.58.101.75>;tag=as0bc522a9
>> To: <sip:*43 at 201.234.196.170:5060>
>> Contact: <sip:9002 at 198.58.101.75:5060>
>> Call-ID: 2c14c21f5052a74a78ca4ab736657b00 at 198.58.101.75:5060
>> CSeq: 102 INVITE
>> User-Agent: FPBX-2.8.1(1.8.20.0)
>> Date: Fri, 29 Aug 2014 18:23:17 GMT
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, 
>> INFO, PUBLISH
>> Supported: replaces, timer
>> Content-Type: application/sdp
>> Content-Length: 299
>>
>> v=0
>> o=root 521741684 521741684 IN IP4 198.58.101.75
>> s=Asterisk PBX 1.8.13.1~dfsg1-3+deb7u3
>> c=IN IP4 198.58.101.75
>> t=0 0
>> m=audio 16426 RTP/AVP 0 8 3 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:3 GSM/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=ptime:20
>> a=sendrecv
>>
>> IP 201.234.196.170.5060 > 198.58.101.75.5060
>> SIP/2.0 100 trying -- your call is important to us
>> Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK7a792c1e;rport=5060
>> From: "9002" <sip:9002 at 198.58.101.75>;tag=as0bc522a9
>> To: <sip:*43 at 201.234.196.170:5060>
>> Call-ID: 2c14c21f5052a74a78ca4ab736657b00 at 198.58.101.75:5060
>> CSeq: 102 INVITE
>> Server: kamailio (4.1.5 (x86_64/linux))
>> Content-Length: 0
>>
>>
>> IP 201.234.196.170.5060 > 198.58.101.75.5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK7a792c1e;rport=5060
>> Record-Route: 
>> <sip:127.0.0.1;r2=on;lr=on;ftag=as0bc522a9;vsf=SRoZSkpbSEZbLF1YW0dGeB8ICB8bDxsxMDEuNzU-;nat=yes>
>> Record-Route: 
>> <sip:192.168.2.18;r2=on;lr=on;ftag=as0bc522a9;vsf=SRoZSkpbSEZbLF1YW0dGeB8ICB8bDxsxMDEuNzU-;nat=yes>
>> From: "9002" <sip:9002 at 198.58.101.75>;tag=as0bc522a9
>> To: <sip:*43 at 201.234.196.170:5060>;tag=as2798a3b9
>> Call-ID: 2c14c21f5052a74a78ca4ab736657b00 at 198.58.101.75:5060
>> CSeq: 102 INVITE
>> Server: Asterisk PBX 11.12.0
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, 
>> INFO, PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:*43 at 127.0.0.1:5080;alias=127.0.0.1~5080~1>
>> Content-Type: application/sdp
>> Require: timer
>> Content-Length: 305
>>
>> v=0
>> o=root 159029581 159029581 IN IP4 201.234.196.170
>> s=Asterisk PBX 11.12.0
>> c=IN IP4 201.234.196.170
>> t=0 0
>> m=audio 18446 RTP/AVP 0 8 3 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:3 GSM/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=ptime:20
>> a=sendrecv
>> a=nortpproxy:yes
>>
>>
>> According to a strict interpretation of the SIP RFC, which address 
>> should the machine at 198.58.101.75 use to send the subsequent ACK? 
>> Which field(s) are to be used to extract said address? I am trying to 
>> understand an issue of a missing ACK between 201.234.196.17x and a 
>> different public IP, with the only difference that the other IP is 
>> not running Asterisk. For the exchange shown above, 201.234.196.170 
>> receives an ACK, but I want to know whether the packets correctly 
>> indicate the address for the ACK, or whether the Asterisk at 
>> 198.58.101.75 is compensating for a malformed packet.
>>
> Regardless of what the first hop of the ACK is going to be, the 
> Contact Field in the SIP 200 OK is telling 198.58.101.75 that the ACK 
> should be directed to 127.0.0.1 which is probably not what you want.
>
In this case, the contact in 200ok is the last hop of the ACK, because 
the 200ok includes Record-Route headers. Therefore the caller has to 
send the ACK to last Record-Route address in 200ok.

That is also private/non-routable address in internet and I expect is 
not what it is desired, considering the other endpoints work with public 
IP.

I guess the sip server is running on a natted system (e.g., 
amazon-cloud-like). You may want to add 'advertise' address to listen 
core parameter in order to use public ip in signaling packets -- see 
core cookbook for more on listen parameter.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA




More information about the sr-users mailing list