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.
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.
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@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
El 01/09/14 05:15, Daniel-Constantin Mierla escribió:
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@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
The test system is running inside a local network and has a local address of 192.168.2.18.
So, it is true that the remote asterisk is covering up for a mistake in my kamailio config?
El 01/09/14 10:50, Alex Villacís Lasso escribió:
El 01/09/14 05:15, Daniel-Constantin Mierla escribió:
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@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
The test system is running inside a local network and has a local address of 192.168.2.18.
So, it is true that the remote asterisk is covering up for a mistake in my kamailio config?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Maybe I should explain my setup better.
The test setup I want to run is, in a way, twice natted. The asterisk instance runs in localhost, the innermost net. The asterisk is not supposed to get its SIP signaling from anyone but Kamailio. The /etc/asterisk/sip.conf contains this:
[root@elx3 ~]# cat /etc/asterisk/sip.conf [general] context=default allowoverlap=no allowguest=no realm=asterisk srvlookup=yes tos_sip=cs3 tos_audio=ef tos_video=af41 relaxdtmf=yes trustrpid=no sendrpid=yes sendrpid=pai disallow=all allow=ulaw allow=alaw allow=gsm rtcachefriends=yes callcounter=yes alwaysauthreject=yes faxdetect=yes t38pt_udptl=yes vmexten=*97 videosupport=yes maxcallbitrate=384 nat=force_rport,comedia directmedia=no accept_outofcall_message=yes auth_message_requests=yes
;The following settings restrict Asterisk to localhost for Kamailio integration deny=0.0.0.0/0.0.0.0 permit=127.0.0.1/255.255.255.0 bindport=5080 outboundproxy=127.0.0.1 outboundproxyport=5060
#include sip_general_custom.conf #include sip_register.conf #include sip_custom.conf
The kamailio instance is the first instance of routing. It listens on all interfaces on port 5060 and routes packets from all the other interfaces to localhost and back. One of these interfaces is the local network (192.168.2.18), which routes to our gateway.
If kamailio is given a public interface, then our setup works correctly. The exchange in the first mail shows what happens when the packet is routed through our gateway (the second instance of routing, and an actual NAT). Our gateway is a linux system with a kernel module (nf_nat_sip, nf_conntrack_sip) that rewrites the headers on the fly, resulting in the packet exchange as seen in the first mail. From what I have seen, the kernel modules rewrite To, From, but not Record-Route, where an instance of the internal IP remains. If I understand correctly, the remote system tries to route to its own interpretation of 192.168.2.18, which fails.
If I add the advertised_address parameter and set it to the public IP, outgoing calls from asterisk to a registered SIP client break and get established with no audio (tested with Jitsi). I get the following exchange from 192.168.2.18:
INVITE sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Max-Forwards: 69 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com Contact: sip:anonymous@127.0.0.1:5080 Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.12.0 Date: Mon, 01 Sep 2014 16:11:44 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 277 P-hint: outbound
v=0 o=root 1851320733 1851320733 IN IP4 127.0.0.1 s=Asterisk PBX 11.12.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 18624 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 SIP/2.0 180 Ringing To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0;received=192.168.2.18,SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f,sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f CSeq: 102 INVITE Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f Contact: "avillacis" sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Content-Length: 0
SIP/2.0 200 OK To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0;received=192.168.2.18,SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f,sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f CSeq: 102 INVITE Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f Contact: "avillacis" sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Content-Type: application/sdp Content-Length: 217
v=0 o=avillacis-jitsi.org 0 0 IN IP4 192.168.3.2 s=- c=IN IP4 192.168.3.2 t=0 0 m=audio 5006 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 ACK sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.805fac86b0d1e9c1dc577d5ca12f12d3.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK2d32b799;rport=5080 Max-Forwards: 69 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Contact: sip:anonymous@127.0.0.1:5080 Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 CSeq: 102 ACK User-Agent: Asterisk PBX 11.12.0 Content-Length: 0
At the same time, I get this on the kamailio log:
WARNING: rr [loose.c:830]: after_loose(): no socket found for match second RR
If I try the incoming call from the internet, while advertised_address is enabled, I get the following exchange. I also get the exact same log message, and one-way audio.
INVITE sip:*43@201.234.196.170:5060 SIP/2.0 Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport Max-Forwards: 70 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060 Contact: sip:9003@198.58.101.75:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 INVITE User-Agent: FPBX-2.8.1(1.8.20.0) Date: Mon, 01 Sep 2014 16:46:43 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Type: application/sdp Content-Length: 301
v=0 o=root 1281221163 1281221163 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 12958 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
SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport=5060 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 INVITE Server: kamailio (4.1.5 (x86_64/linux)) Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport=5060 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- Record-Route: sip:192.168.2.18;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060;tag=as5f3239b9 Call-ID: 0398a11d3149031240ec2e70077a99fe@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 Content-Type: application/sdp Require: timer Content-Length: 277
v=0 o=root 1757515753 1757515753 IN IP4 127.0.0.1 s=Asterisk PBX 11.12.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 16396 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
ACK sip:*43@127.0.0.1:5080 SIP/2.0 Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK636e2948;rport Route: sip:192.168.2.18;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU-,sip:201.234.196.170;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- Max-Forwards: 70 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060;tag=as5f3239b9 Contact: sip:9003@198.58.101.75:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 ACK User-Agent: FPBX-2.8.1(1.8.20.0) Content-Length: 0
How can I fix the "no socket found for match second RR" error?
If you get signling routed ok but no audio, then you have problems bridging rtp stream.
Most probably you need to use rtpproxy (eventually with advertise address (there is a patch or use second parameter for rtpproxy_manage())) to bridge.
I never used sip-natting in kernel, so I am not aware how good it is. I would rather do just simple port forwarding on the firewall and let kamailio and rtpproxy to work with advertised address.
Then you can use:
listen=privateip advertise publicip
You will get rid of record routing log message about missing socket. Otherwise, you should ignore it if the sip routing is ok.
Cheers, Daniel
On 01/09/14 18:55, Alex Villacís Lasso wrote:
[...]
Maybe I should explain my setup better.
The test setup I want to run is, in a way, twice natted. The asterisk instance runs in localhost, the innermost net. The asterisk is not supposed to get its SIP signaling from anyone but Kamailio. The /etc/asterisk/sip.conf contains this:
[root@elx3 ~]# cat /etc/asterisk/sip.conf [general] context=default allowoverlap=no allowguest=no realm=asterisk srvlookup=yes tos_sip=cs3 tos_audio=ef tos_video=af41 relaxdtmf=yes trustrpid=no sendrpid=yes sendrpid=pai disallow=all allow=ulaw allow=alaw allow=gsm rtcachefriends=yes callcounter=yes alwaysauthreject=yes faxdetect=yes t38pt_udptl=yes vmexten=*97 videosupport=yes maxcallbitrate=384 nat=force_rport,comedia directmedia=no accept_outofcall_message=yes auth_message_requests=yes
;The following settings restrict Asterisk to localhost for Kamailio integration deny=0.0.0.0/0.0.0.0 permit=127.0.0.1/255.255.255.0 bindport=5080 outboundproxy=127.0.0.1 outboundproxyport=5060
#include sip_general_custom.conf #include sip_register.conf #include sip_custom.conf
The kamailio instance is the first instance of routing. It listens on all interfaces on port 5060 and routes packets from all the other interfaces to localhost and back. One of these interfaces is the local network (192.168.2.18), which routes to our gateway.
If kamailio is given a public interface, then our setup works correctly. The exchange in the first mail shows what happens when the packet is routed through our gateway (the second instance of routing, and an actual NAT). Our gateway is a linux system with a kernel module (nf_nat_sip, nf_conntrack_sip) that rewrites the headers on the fly, resulting in the packet exchange as seen in the first mail. From what I have seen, the kernel modules rewrite To, From, but not Record-Route, where an instance of the internal IP remains. If I understand correctly, the remote system tries to route to its own interpretation of 192.168.2.18, which fails.
If I add the advertised_address parameter and set it to the public IP, outgoing calls from asterisk to a registered SIP client break and get established with no audio (tested with Jitsi). I get the following exchange from 192.168.2.18:
INVITE sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Max-Forwards: 69 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com Contact: sip:anonymous@127.0.0.1:5080 Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.12.0 Date: Mon, 01 Sep 2014 16:11:44 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 277 P-hint: outbound
v=0 o=root 1851320733 1851320733 IN IP4 127.0.0.1 s=Asterisk PBX 11.12.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 18624 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 SIP/2.0 180 Ringing To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0;received=192.168.2.18,SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f,sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f CSeq: 102 INVITE Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f Contact: "avillacis" sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Content-Length: 0
SIP/2.0 200 OK To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0;received=192.168.2.18,SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f,sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f CSeq: 102 INVITE Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f Contact: "avillacis" sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Content-Type: application/sdp Content-Length: 217
v=0 o=avillacis-jitsi.org 0 0 IN IP4 192.168.3.2 s=- c=IN IP4 192.168.3.2 t=0 0 m=audio 5006 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 ACK sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.805fac86b0d1e9c1dc577d5ca12f12d3.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK2d32b799;rport=5080 Max-Forwards: 69 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Contact: sip:anonymous@127.0.0.1:5080 Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 CSeq: 102 ACK User-Agent: Asterisk PBX 11.12.0 Content-Length: 0
At the same time, I get this on the kamailio log:
WARNING: rr [loose.c:830]: after_loose(): no socket found for match second RR
If I try the incoming call from the internet, while advertised_address is enabled, I get the following exchange. I also get the exact same log message, and one-way audio.
INVITE sip:*43@201.234.196.170:5060 SIP/2.0 Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport Max-Forwards: 70 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060 Contact: sip:9003@198.58.101.75:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 INVITE User-Agent: FPBX-2.8.1(1.8.20.0) Date: Mon, 01 Sep 2014 16:46:43 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Type: application/sdp Content-Length: 301
v=0 o=root 1281221163 1281221163 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 12958 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
SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport=5060 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 INVITE Server: kamailio (4.1.5 (x86_64/linux)) Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport=5060 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- Record-Route: sip:192.168.2.18;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060;tag=as5f3239b9 Call-ID: 0398a11d3149031240ec2e70077a99fe@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 Content-Type: application/sdp Require: timer Content-Length: 277
v=0 o=root 1757515753 1757515753 IN IP4 127.0.0.1 s=Asterisk PBX 11.12.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 16396 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
ACK sip:*43@127.0.0.1:5080 SIP/2.0 Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK636e2948;rport Route: sip:192.168.2.18;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU-,sip:201.234.196.170;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- Max-Forwards: 70 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060;tag=as5f3239b9 Contact: sip:9003@198.58.101.75:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 ACK User-Agent: FPBX-2.8.1(1.8.20.0) Content-Length: 0
How can I fix the "no socket found for match second RR" error?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
El 02/09/14 05:17, Daniel-Constantin Mierla escribió:
If you get signling routed ok but no audio, then you have problems bridging rtp stream.
Most probably you need to use rtpproxy (eventually with advertise address (there is a patch or use second parameter for rtpproxy_manage())) to bridge.
I am already using rtpproxy in all my tests. All of my audio is routed correctly when I do not use advertised_address, without any log messages. However, in the original setup, when the non-Asterisk SIP trunk fails to route the ACK correctly, the Asterisk in localhost drops the call after 10 to 30 seconds.
When I introduce advertised_address into the setup, with no other changes, I get the audio issues.
I never used sip-natting in kernel, so I am not aware how good it is. I would rather do just simple port forwarding on the firewall and let kamailio and rtpproxy to work with advertised address.
I will try to negotiate this.
Then you can use:
listen=privateip advertise publicip
The private ip serves both phones in the same LAN as the Kamailio interface, and the gateway. Will the publicip advertising cause problems with the SIP clients in the LAN?
You will get rid of record routing log message about missing socket. Otherwise, you should ignore it if the sip routing is ok.
Cheers, Daniel
On 01/09/14 18:55, Alex Villacís Lasso wrote:
[...]
Maybe I should explain my setup better.
The test setup I want to run is, in a way, twice natted. The asterisk instance runs in localhost, the innermost net. The asterisk is not supposed to get its SIP signaling from anyone but Kamailio. The /etc/asterisk/sip.conf contains this:
[root@elx3 ~]# cat /etc/asterisk/sip.conf [general] context=default allowoverlap=no allowguest=no realm=asterisk srvlookup=yes tos_sip=cs3 tos_audio=ef tos_video=af41 relaxdtmf=yes trustrpid=no sendrpid=yes sendrpid=pai disallow=all allow=ulaw allow=alaw allow=gsm rtcachefriends=yes callcounter=yes alwaysauthreject=yes faxdetect=yes t38pt_udptl=yes vmexten=*97 videosupport=yes maxcallbitrate=384 nat=force_rport,comedia directmedia=no accept_outofcall_message=yes auth_message_requests=yes
;The following settings restrict Asterisk to localhost for Kamailio integration deny=0.0.0.0/0.0.0.0 permit=127.0.0.1/255.255.255.0 bindport=5080 outboundproxy=127.0.0.1 outboundproxyport=5060
#include sip_general_custom.conf #include sip_register.conf #include sip_custom.conf
The kamailio instance is the first instance of routing. It listens on all interfaces on port 5060 and routes packets from all the other interfaces to localhost and back. One of these interfaces is the local network (192.168.2.18), which routes to our gateway.
If kamailio is given a public interface, then our setup works correctly. The exchange in the first mail shows what happens when the packet is routed through our gateway (the second instance of routing, and an actual NAT). Our gateway is a linux system with a kernel module (nf_nat_sip, nf_conntrack_sip) that rewrites the headers on the fly, resulting in the packet exchange as seen in the first mail. From what I have seen, the kernel modules rewrite To, From, but not Record-Route, where an instance of the internal IP remains. If I understand correctly, the remote system tries to route to its own interpretation of 192.168.2.18, which fails.
If I add the advertised_address parameter and set it to the public IP, outgoing calls from asterisk to a registered SIP client break and get established with no audio (tested with Jitsi). I get the following exchange from 192.168.2.18:
INVITE sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Max-Forwards: 69 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com Contact: sip:anonymous@127.0.0.1:5080 Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.12.0 Date: Mon, 01 Sep 2014 16:11:44 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 277 P-hint: outbound
v=0 o=root 1851320733 1851320733 IN IP4 127.0.0.1 s=Asterisk PBX 11.12.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 18624 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 SIP/2.0 180 Ringing To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0;received=192.168.2.18,SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f,sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f CSeq: 102 INVITE Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f Contact: "avillacis" sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Content-Length: 0
SIP/2.0 200 OK To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0;received=192.168.2.18,SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f,sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f CSeq: 102 INVITE Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f Contact: "avillacis" sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Content-Type: application/sdp Content-Length: 217
v=0 o=avillacis-jitsi.org 0 0 IN IP4 192.168.3.2 s=- c=IN IP4 192.168.3.2 t=0 0 m=audio 5006 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 ACK sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.805fac86b0d1e9c1dc577d5ca12f12d3.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK2d32b799;rport=5080 Max-Forwards: 69 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Contact: sip:anonymous@127.0.0.1:5080 Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 CSeq: 102 ACK User-Agent: Asterisk PBX 11.12.0 Content-Length: 0
At the same time, I get this on the kamailio log:
WARNING: rr [loose.c:830]: after_loose(): no socket found for match second RR
If I try the incoming call from the internet, while advertised_address is enabled, I get the following exchange. I also get the exact same log message, and one-way audio.
INVITE sip:*43@201.234.196.170:5060 SIP/2.0 Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport Max-Forwards: 70 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060 Contact: sip:9003@198.58.101.75:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 INVITE User-Agent: FPBX-2.8.1(1.8.20.0) Date: Mon, 01 Sep 2014 16:46:43 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Type: application/sdp Content-Length: 301
v=0 o=root 1281221163 1281221163 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 12958 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
SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport=5060 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 INVITE Server: kamailio (4.1.5 (x86_64/linux)) Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport=5060 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- Record-Route: sip:192.168.2.18;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060;tag=as5f3239b9 Call-ID: 0398a11d3149031240ec2e70077a99fe@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 Content-Type: application/sdp Require: timer Content-Length: 277
v=0 o=root 1757515753 1757515753 IN IP4 127.0.0.1 s=Asterisk PBX 11.12.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 16396 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
ACK sip:*43@127.0.0.1:5080 SIP/2.0 Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK636e2948;rport Route: sip:192.168.2.18;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU-,sip:201.234.196.170;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- Max-Forwards: 70 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060;tag=as5f3239b9 Contact: sip:9003@198.58.101.75:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 ACK User-Agent: FPBX-2.8.1(1.8.20.0) Content-Length: 0
How can I fix the "no socket found for match second RR" error?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 02/09/14 19:05, Alex Villacís Lasso wrote:
El 02/09/14 05:17, Daniel-Constantin Mierla escribió:
If you get signling routed ok but no audio, then you have problems bridging rtp stream.
Most probably you need to use rtpproxy (eventually with advertise address (there is a patch or use second parameter for rtpproxy_manage())) to bridge.
I am already using rtpproxy in all my tests. All of my audio is routed correctly when I do not use advertised_address, without any log messages. However, in the original setup, when the non-Asterisk SIP trunk fails to route the ACK correctly, the Asterisk in localhost drops the call after 10 to 30 seconds.
This is the typical situation for missing ACK.
When I introduce advertised_address into the setup, with no other changes, I get the audio issues.
I never used sip-natting in kernel, so I am not aware how good it is. I would rather do just simple port forwarding on the firewall and let kamailio and rtpproxy to work with advertised address.
I will try to negotiate this.
Then you can use:
listen=privateip advertise publicip
The private ip serves both phones in the same LAN as the Kamailio interface, and the gateway. Will the publicip advertising cause problems with the SIP clients in the LAN?
I guess the firwall will forward properly, if the rule is on everything received on external ip and port, but has to be tested.
Better to use different ports, so you have two listen sockets, or if possible two private ips.
Cheers, Daniel
You will get rid of record routing log message about missing socket. Otherwise, you should ignore it if the sip routing is ok.
Cheers, Daniel
On 01/09/14 18:55, Alex Villacís Lasso wrote:
[...]
Maybe I should explain my setup better.
The test setup I want to run is, in a way, twice natted. The asterisk instance runs in localhost, the innermost net. The asterisk is not supposed to get its SIP signaling from anyone but Kamailio. The /etc/asterisk/sip.conf contains this:
[root@elx3 ~]# cat /etc/asterisk/sip.conf [general] context=default allowoverlap=no allowguest=no realm=asterisk srvlookup=yes tos_sip=cs3 tos_audio=ef tos_video=af41 relaxdtmf=yes trustrpid=no sendrpid=yes sendrpid=pai disallow=all allow=ulaw allow=alaw allow=gsm rtcachefriends=yes callcounter=yes alwaysauthreject=yes faxdetect=yes t38pt_udptl=yes vmexten=*97 videosupport=yes maxcallbitrate=384 nat=force_rport,comedia directmedia=no accept_outofcall_message=yes auth_message_requests=yes
;The following settings restrict Asterisk to localhost for Kamailio integration deny=0.0.0.0/0.0.0.0 permit=127.0.0.1/255.255.255.0 bindport=5080 outboundproxy=127.0.0.1 outboundproxyport=5060
#include sip_general_custom.conf #include sip_register.conf #include sip_custom.conf
The kamailio instance is the first instance of routing. It listens on all interfaces on port 5060 and routes packets from all the other interfaces to localhost and back. One of these interfaces is the local network (192.168.2.18), which routes to our gateway.
If kamailio is given a public interface, then our setup works correctly. The exchange in the first mail shows what happens when the packet is routed through our gateway (the second instance of routing, and an actual NAT). Our gateway is a linux system with a kernel module (nf_nat_sip, nf_conntrack_sip) that rewrites the headers on the fly, resulting in the packet exchange as seen in the first mail. From what I have seen, the kernel modules rewrite To, From, but not Record-Route, where an instance of the internal IP remains. If I understand correctly, the remote system tries to route to its own interpretation of 192.168.2.18, which fails.
If I add the advertised_address parameter and set it to the public IP, outgoing calls from asterisk to a registered SIP client break and get established with no audio (tested with Jitsi). I get the following exchange from 192.168.2.18:
INVITE sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Max-Forwards: 69 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com Contact: sip:anonymous@127.0.0.1:5080 Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.12.0 Date: Mon, 01 Sep 2014 16:11:44 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 277 P-hint: outbound
v=0 o=root 1851320733 1851320733 IN IP4 127.0.0.1 s=Asterisk PBX 11.12.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 18624 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 SIP/2.0 180 Ringing To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0;received=192.168.2.18,SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f,sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f CSeq: 102 INVITE Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f Contact: "avillacis" sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Content-Length: 0
SIP/2.0 200 OK To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.6bce295bab666c7aceeddfebdc70c190.0;received=192.168.2.18,SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK696d3bf6;rport=5080 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as0551c44f,sip:127.0.0.1;r2=on;lr=on;ftag=as0551c44f CSeq: 102 INVITE Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f Contact: "avillacis" sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Content-Type: application/sdp Content-Length: 217
v=0 o=avillacis-jitsi.org 0 0 IN IP4 192.168.3.2 s=- c=IN IP4 192.168.3.2 t=0 0 m=audio 5006 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 ACK sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Via: SIP/2.0/UDP 201.234.196.170;branch=z9hG4bKd5f3.805fac86b0d1e9c1dc577d5ca12f12d3.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK2d32b799;rport=5080 Max-Forwards: 69 From: "Anonymous" sip:anonymous@anonymous.invalid:5080;tag=as0551c44f To: sip:avillacis@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=d28a3a6e Contact: sip:anonymous@127.0.0.1:5080 Call-ID: 4f40ffcc123459313daf47397e18b0af@127.0.0.1:5080 CSeq: 102 ACK User-Agent: Asterisk PBX 11.12.0 Content-Length: 0
At the same time, I get this on the kamailio log:
WARNING: rr [loose.c:830]: after_loose(): no socket found for match second RR
If I try the incoming call from the internet, while advertised_address is enabled, I get the following exchange. I also get the exact same log message, and one-way audio.
INVITE sip:*43@201.234.196.170:5060 SIP/2.0 Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport Max-Forwards: 70 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060 Contact: sip:9003@198.58.101.75:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 INVITE User-Agent: FPBX-2.8.1(1.8.20.0) Date: Mon, 01 Sep 2014 16:46:43 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Type: application/sdp Content-Length: 301
v=0 o=root 1281221163 1281221163 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 12958 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
SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport=5060 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 INVITE Server: kamailio (4.1.5 (x86_64/linux)) Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK587b52bc;rport=5060 Record-Route: sip:201.234.196.170;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- Record-Route: sip:192.168.2.18;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060;tag=as5f3239b9 Call-ID: 0398a11d3149031240ec2e70077a99fe@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 Content-Type: application/sdp Require: timer Content-Length: 277
v=0 o=root 1757515753 1757515753 IN IP4 127.0.0.1 s=Asterisk PBX 11.12.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 16396 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
ACK sip:*43@127.0.0.1:5080 SIP/2.0 Via: SIP/2.0/UDP 198.58.101.75:5060;branch=z9hG4bK636e2948;rport Route: sip:192.168.2.18;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU-,sip:201.234.196.170;r2=on;lr=on;ftag=as69ee0744;vsf=SBoZSkpbSEZaLF1YW0dGeB8ICB8bDxsxMDEuNzU- Max-Forwards: 70 From: "9003" sip:9003@198.58.101.75;tag=as69ee0744 To: sip:*43@201.234.196.170:5060;tag=as5f3239b9 Contact: sip:9003@198.58.101.75:5060 Call-ID: 0398a11d3149031240ec2e70077a99fe@198.58.101.75:5060 CSeq: 102 ACK User-Agent: FPBX-2.8.1(1.8.20.0) Content-Length: 0
How can I fix the "no socket found for match second RR" error?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users