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

[Andres]

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.

-- 
Technical Support
http://www.cellroute.net