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@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@198.58.101.75>;tag=as0bc522a9
To: <sip:*43@201.234.196.170:5060>
Contact: <sip:9002@198.58.101.75:5060>
Call-ID: 2c14c21f5052a74a78ca4ab736657b00@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@198.58.101.75>;tag=as0bc522a9
To: <sip:*43@201.234.196.170:5060>
Call-ID: 2c14c21f5052a74a78ca4ab736657b00@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@198.58.101.75>;tag=as0bc522a9
To: <sip:*43@201.234.196.170:5060>;tag=as2798a3b9
Call-ID: 2c14c21f5052a74a78ca4ab736657b00@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@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