28 Aug
2013
28 Aug
'13
9:09 a.m.
I think I found my missing ACKs! Can anyone tell me why they work be
being sent to the loopback interface? The destination address is
still the external (eth0) IP.
--
Marc Soda, Sr. Systems Engineer
*CoreDial, LLC* | www.coredial.com
1787 Sentry Parkway West, Building 16, Suite 100, Blue Bell, PA 19422
Office: (215) 297-4400 x203 | Fax: (215) 297-4401 | Email:
msoda(a)coredial.com
- - - - -
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
28 Aug
28 Aug
9:20 a.m.
If it is eth0 of the same server, then is the kernel sending via
loopback interface at it detects the destination is itself.
You should paste here ngrep with the sip traffic from invite to bye in
order to give more hints about what is going wrong there.
Cheers,
Daniel
On 8/28/13 3:09 PM, Marc Soda wrote:
I think I found my missing ACKs! Can anyone tell me
why they work be being sent to the loopback interface? The destination address is still
the external (eth0) IP.
--
Marc Soda, Sr. Systems Engineer
*CoreDial, LLC* | www.coredial.com <http://www.coredial.com>
1787 Sentry Parkway West, Building 16, Suite 100, Blue Bell, PA 19422
Office: (215) 297-4400 x203 | Fax: (215) 297-4401 | Email:
msoda(a)coredial.com <mailto:msoda@coredial.com>
- - - - -
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
2:22 p.m.
Thanks, I appreciate it.
In this setup the there are 2 endpoints (700 and 701) peered up to an
Asterisk server (172.16.60.6) via a Kamailio proxy (172.16.60.20). 700
(172.16.60.28) is calling 701 (172.16.3.65). When 701 answers the OK is
sent to the proxy and then to Asterisk. Asterisk is then ACKing the OK.
The ACK is being sent to the proxy and then the proxy should be sending it
back to the endpoint. It is not. The ACK is being sent to the proxy and
then the proxy is sending to itself again, via the loopback interface. I
believe loose_route() should be re-writing the destination to be the
endpoint, but it not.
Trace:
U 172.16.60.28:54936 -> 172.16.60.20:5060
INVITE sip:701@eng-reg1.example.com SIP/2.0.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport;branch=z9hG4bKPjBsmwQX-oWu6srxf09JRx98W5IklAwE44.
Max-Forwards: 70.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>.
Contact: <sip:sip700_tbs@172.16.60.28:54936;ob>.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 INVITE.
Route: <sip:eng-reg1.example.com;transport=udp;lr>.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Session-Expires: 1800.
Min-SE: 90.
User-Agent: CSipSimple_mecha-15/r2272.
Proxy-Authorization: Digest username="sip700_tbs",
realm="sip700_tbs",
nonce="Uh39eVId/E2Vxz5hgWC/7jMNGAf7rxrV",
uri="sip:701@eng-reg1.example.com",
response="8a74a8727baa45df84ea1374cb6668f2",
cnonce="EYGYpa1zWmEXcOMighUzGZ20cY2HJ7AJ", qop=auth, nc=00000001.
Content-Type: application/sdp.
Content-Length: 340.
.
v=0.
o=- 3586685645 3586685645 IN IP4 172.16.60.28.
s=pjmedia.
c=IN IP4 172.16.60.28.
t=0 0.
m=audio 4004 RTP/AVP 99 0 8 101.
c=IN IP4 172.16.60.28.
a=rtcp:4005 IN IP4 172.16.60.28.
a=sendrecv.
a=rtpmap:99 SILK/24000.
a=fmtp:99 useinbandfec=0.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
U 172.16.60.20:5060 -> 172.16.60.28:54936
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport=54936;branch=z9hG4bKPjBsmwQX-oWu6srxf09JRx98W5IklAwE44.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 INVITE.
Server: kamailio (4.0.3 (x86_64/linux)).
Content-Length: 0.
.
U 172.16.60.20:5060 -> 172.16.60.6:5060
INVITE sip:701@eng-reg1.example.com SIP/2.0.
Record-Route:
<sip:172.16.60.20;lr=on;ftag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P;nat=yes>.
Via: SIP/2.0/UDP 172.16.60.20;branch=z9hG4bKe51f.d2338795.0.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport=54936;branch=z9hG4bKPjBsmwQX-oWu6srxf09JRx98W5IklAwE44.
Max-Forwards: 16.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>.
Contact: <sip:sip700_tbs@172.16.60.28:54936;ob>.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 INVITE.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Session-Expires: 1800.
Min-SE: 90.
User-Agent: CSipSimple_mecha-15/r2272.
Content-Type: application/sdp.
Content-Length: 340.
.
v=0.
o=- 3586685645 3586685645 IN IP4 172.16.60.28.
s=pjmedia.
c=IN IP4 172.16.60.28.
t=0 0.
m=audio 4004 RTP/AVP 99 0 8 101.
c=IN IP4 172.16.60.28.
a=rtcp:4005 IN IP4 172.16.60.28.
a=sendrecv.
a=rtpmap:99 SILK/24000.
a=fmtp:99 useinbandfec=0.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
U 172.16.60.6:5060 -> 172.16.60.20:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
172.16.60.20;branch=z9hG4bKe51f.d2338795.0;received=172.16.60.20;rport=5060.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport=54936;branch=z9hG4bKPjBsmwQX-oWu6srxf09JRx98W5IklAwE44.
Record-Route:
<sip:172.16.60.20;lr=on;ftag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P;nat=yes>.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 INVITE.
Server: Asterisk1.8.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Session-Expires: 1800;refresher=uas.
Contact: <sip:701@172.16.60.6:5060>.
Content-Length: 0.
.
U 172.16.60.6:5060 -> 172.16.60.20:5060
INVITE sip:sip701_tbs@172.16.60.20:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.16.60.6:5060;branch=z9hG4bK0919ead7;rport.
Max-Forwards: 70.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20:5060>.
Contact: <sip:700@172.16.60.6:5060>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk1.8.
Date: Wed, 28 Aug 2013 13:34:03 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 263.
.
v=0.
o=root 1276916964 1276916964 IN IP4 172.16.60.6.
s=Asterisk PBX 1.8.15-cert2.
c=IN IP4 172.16.60.6.
t=0 0.
m=audio 21930 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.
U 172.16.60.20:5060 -> 172.16.60.6:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 172.16.60.6:5060;branch=z9hG4bK0919ead7;rport=5060.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20:5060>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
CSeq: 102 INVITE.
Server: kamailio (4.0.3 (x86_64/linux)).
Content-Length: 0.
.
U 172.16.60.20:5060 -> 172.16.3.65:5060
INVITE sip:sip701_tbs@172.16.3.65:5060 SIP/2.0.
Record-Route: <sip:172.16.60.20;lr=on;ftag=as5e1a80d8;nat=yes>.
Via: SIP/2.0/UDP 172.16.60.20;branch=z9hG4bK9381.d7d662b.0.
Via: SIP/2.0/UDP 172.16.60.6:5060;branch=z9hG4bK0919ead7;rport=5060.
Max-Forwards: 16.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20:5060>.
Contact: <sip:700@172.16.60.6:5060>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk1.8.
Date: Wed, 28 Aug 2013 13:34:03 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 263.
.
v=0.
o=root 1276916964 1276916964 IN IP4 172.16.60.6.
s=Asterisk PBX 1.8.15-cert2.
c=IN IP4 172.16.60.6.
t=0 0.
m=audio 21930 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.
U 172.16.3.65:5060 -> 172.16.60.20:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP
172.16.60.20;received=172.16.60.20;branch=z9hG4bK9381.d7d662b.0.
Via: SIP/2.0/UDP 172.16.60.6:5060;rport=5060;branch=z9hG4bK0919ead7.
Record-Route: <sip:172.16.60.20;lr;ftag=as5e1a80d8;nat=yes>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20
;tag=64c37e7e-19b8-46ae-ad0d-f2a4abe667bc.
CSeq: 102 INVITE.
Contact: <sip:sip701_tbs@172.16.60.20:5060>.
Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE,
INFO, REGISTER, OPTIONS, MESSAGE.
Content-Length: 0.
.
U 172.16.60.20:5060 -> 172.16.60.6:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 172.16.60.6:5060;rport=5060;branch=z9hG4bK0919ead7.
Record-Route: <sip:172.16.60.20;lr;ftag=as5e1a80d8;nat=yes>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20
;tag=64c37e7e-19b8-46ae-ad0d-f2a4abe667bc.
CSeq: 102 INVITE.
Contact: <sip:sip701_tbs@172.16.60.20:5060;alias=172.16.3.65~5060~1>.
Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE,
INFO, REGISTER, OPTIONS, MESSAGE.
Content-Length: 0.
.
U 172.16.60.6:5060 -> 172.16.60.20:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP
172.16.60.20;branch=z9hG4bKe51f.d2338795.0;received=172.16.60.20;rport=5060.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport=54936;branch=z9hG4bKPjBsmwQX-oWu6srxf09JRx98W5IklAwE44.
Record-Route:
<sip:172.16.60.20;lr=on;ftag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P;nat=yes>.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>;tag=as7e09c7c3.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 INVITE.
Server: Asterisk1.8.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Session-Expires: 1800;refresher=uas.
Contact: <sip:701@172.16.60.6:5060>.
Content-Length: 0.
.
U 172.16.60.20:5060 -> 172.16.60.28:54936
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport=54936;branch=z9hG4bKPjBsmwQX-oWu6srxf09JRx98W5IklAwE44.
Record-Route:
<sip:172.16.60.20;lr=on;ftag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P;nat=yes>.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>;tag=as7e09c7c3.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 INVITE.
Server: Asterisk1.8.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Session-Expires: 1800;refresher=uas.
Contact: <sip:701@172.16.60.6:5060>.
Content-Length: 0.
.
U 172.16.3.65:5060 -> 172.16.60.20:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
172.16.60.20;received=172.16.60.20;branch=z9hG4bK9381.d7d662b.0.
Via: SIP/2.0/UDP 172.16.60.6:5060;rport=5060;branch=z9hG4bK0919ead7.
Record-Route: <sip:172.16.60.20;lr;ftag=as5e1a80d8;nat=yes>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20
;tag=64c37e7e-19b8-46ae-ad0d-f2a4abe667bc.
CSeq: 102 INVITE.
Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE,
INFO, REGISTER, OPTIONS, MESSAGE.
Contact: <sip:sip701_tbs@172.16.60.20:5060>.
Supported: replaces, 100rel.
Content-Type: application/sdp.
Content-Length: 200.
.
v=0.
o=dresden 3586685646 1 IN IP4 172.16.3.65.
s=sflphone.
c=IN IP4 172.16.3.65.
t=0 0.
m=audio 41394 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
a=sendrecv.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
U 172.16.60.20:5060 -> 172.16.60.6:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 172.16.60.6:5060;rport=5060;branch=z9hG4bK0919ead7.
Record-Route: <sip:172.16.60.20;lr;ftag=as5e1a80d8;nat=yes>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20
;tag=64c37e7e-19b8-46ae-ad0d-f2a4abe667bc.
CSeq: 102 INVITE.
Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE,
INFO, REGISTER, OPTIONS, MESSAGE.
Contact: <sip:sip701_tbs@172.16.60.20:5060;alias=172.16.3.65~5060~1>.
Supported: replaces, 100rel.
Content-Type: application/sdp.
Content-Length: 200.
.
v=0.
o=dresden 3586685646 1 IN IP4 172.16.3.65.
s=sflphone.
c=IN IP4 172.16.3.65.
t=0 0.
m=audio 41394 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
a=sendrecv.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
=====
This ACK is never being sent back to the endpoint that answered the call
(172.16.3.65):
=====
U 172.16.60.6:5060 -> 172.16.60.20:5060
ACK sip:sip701_tbs@172.16.60.20:5060;alias=172.16.3.65~5060~1 SIP/2.0.
Via: SIP/2.0/UDP 172.16.60.6:5060;branch=z9hG4bK70890881;rport.
Route: <sip:172.16.60.20;lr;ftag=as5e1a80d8;nat=yes>.
Max-Forwards: 70.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20:5060
;tag=64c37e7e-19b8-46ae-ad0d-f2a4abe667bc.
Contact: <sip:700@172.16.60.6:5060>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
CSeq: 102 ACK.
User-Agent: Asterisk1.8.
Content-Length: 0.
.
U 172.16.60.6:5060 -> 172.16.60.20:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
172.16.60.20;branch=z9hG4bKe51f.d2338795.0;received=172.16.60.20;rport=5060.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport=54936;branch=z9hG4bKPjBsmwQX-oWu6srxf09JRx98W5IklAwE44.
Record-Route:
<sip:172.16.60.20;lr=on;ftag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P;nat=yes>.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>;tag=as7e09c7c3.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 INVITE.
Server: Asterisk1.8.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Session-Expires: 1800;refresher=uas.
Contact: <sip:701@172.16.60.6:5060>.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=root 115762304 115762304 IN IP4 172.16.60.6.
s=Asterisk PBX 1.8.15-cert2.
c=IN IP4 172.16.60.6.
t=0 0.
m=audio 24198 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.
U 172.16.60.20:5060 -> 172.16.60.28:54936
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport=54936;branch=z9hG4bKPjBsmwQX-oWu6srxf09JRx98W5IklAwE44.
Record-Route:
<sip:172.16.60.20;lr=on;ftag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P;nat=yes>.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>;tag=as7e09c7c3.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 INVITE.
Server: Asterisk1.8.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Session-Expires: 1800;refresher=uas.
Contact: <sip:701@172.16.60.6:5060>.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=root 115762304 115762304 IN IP4 172.16.60.6.
s=Asterisk PBX 1.8.15-cert2.
c=IN IP4 172.16.60.6.
t=0 0.
m=audio 24198 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.
=====
This is the ACK that shows up on the loopback interface (I believe it
should be going to 172.16.3.65):
=====
U 172.16.60.20:5060 -> 172.16.60.20:5060
ACK sip:172.16.60.20;lr;ftag=as5e1a80d8;nat=yes SIP/2.0.
Via: SIP/2.0/UDP 172.16.60.20;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 172.16.60.6:5060;branch=z9hG4bK70890881;rport=5060.
Max-Forwards: 16.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20:5060
;tag=64c37e7e-19b8-46ae-ad0d-f2a4abe667bc.
Contact: <sip:700@172.16.60.6:5060>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
CSeq: 102 ACK.
User-Agent: Asterisk1.8.
Content-Length: 0.
.
U 172.16.60.28:54936 -> 172.16.60.20:5060
ACK sip:701@172.16.60.6:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport;branch=z9hG4bKPjK4X6qtfWQUXsbgPP8D6j-bxR0KBd7r-x.
Max-Forwards: 70.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>;tag=as7e09c7c3.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 ACK.
Route: <sip:172.16.60.20;lr;ftag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P;nat=yes>.
Content-Length: 0.
.
U 172.16.60.20:5060 -> 172.16.60.6:5060
ACK sip:701@172.16.60.6:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.16.60.20;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 172.16.60.28:54936
;rport=54936;branch=z9hG4bKPjK4X6qtfWQUXsbgPP8D6j-bxR0KBd7r-x.
Max-Forwards: 16.
From: <sip:sip700_tbs@eng-reg1.example.com
;tag=bmiDmchqpEnJnCFuHdLZNICQ-DisG41P.
To:
<sip:701@eng-reg1.example.com>;tag=as7e09c7c3.
Call-ID: BUDvyYQczBQPRIOhj7t7FodP7675QPGi.
CSeq: 13862 ACK.
Content-Length: 0.
.
29 Aug
29 Aug
3:53 a.m.
Hello,
On 8/28/13 8:22 PM, Marc Soda wrote:
Thanks, I appreciate it.
In this setup the there are 2 endpoints (700 and 701) peered up to an
Asterisk server (172.16.60.6) via a Kamailio proxy (172.16.60.20).
700 (172.16.60.28) is calling 701 (172.16.3.65). When 701 answers
the OK is sent to the proxy and then to Asterisk. Asterisk is then
ACKing the OK. The ACK is being sent to the proxy and then the proxy
should be sending it back to the endpoint. It is not. The ACK is
being sent to the proxy and then the proxy is sending to itself again,
via the loopback interface. I believe loose_route() should be
re-writing the destination to be the endpoint, but it not.
what device is at 701?
The 200ok receved from it has the contact address
with the IP of kamailio:
U 172.16.3.65:5060 -> 172.16.60.20:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
172.16.60.20;received=172.16.60.20;branch=z9hG4bK9381.d7d662b.0.
Via: SIP/2.0/UDP 172.16.60.6:5060;rport=5060;branch=z9hG4bK0919ead7.
Record-Route: <sip:172.16.60.20;lr;ftag=as5e1a80d8;nat=yes>.
Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060.
From: "Alpha" <sip:700@172.16.60.6>;tag=as5e1a80d8.
To: <sip:sip701_tbs@172.16.60.20>;tag=64c37e7e-19b8-46ae-ad0d-f2a4abe667bc.
CSeq: 102 INVITE.
Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL,
UPDATE, INFO, REGISTER, OPTIONS, MESSAGE.
*Contact: <sip:sip701_tbs@172.16.60.20:5060>*.
.....
It should be its IP address, otherwise Kamailio doesn't know where to
sent requests within dialog.
It seems there is a NAT between your kamailio and 701, as kamailio adds
alias parameter to Contact in 200ok. That can be used to route the ack,
like:
handle_ruri_alias();
$ru = $du;
$du = $null;
Do the above for the ACK before calling loose_route(). Then it will get
out of kamailio, but might not solve the overall routing, if the 701 is
not at next hop or it doesn't like the r-uri, because it is not what it
has set.
The best is to ask for the proper fix on 701 device.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
10:58 a.m.
On Thu, Aug 29, 2013 at 3:53 AM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
what device is at 701? The 200ok receved from it has
the contact address
with the IP of kamailio:
SFLPhone
It seems there is a NAT between your kamailio and
701, as kamailio adds
alias parameter to Contact in 200ok. That can be used to route the ack,
like:
handle_ruri_alias();
$ru = $du;
$du = $null;
There is no NAT in this scenario, although NAT support is enabled as we
will have to deal with it. Should I still use handle_ruri_alias()?
Thanks,
Marc
12:19 p.m.
I ended up doing this right before the call to loose_route():
if ((is_method("ACK") || is_method("BYE")) &&
!isdsturiset()) {
handle_ruri_alias();
if ($du != $null) {
$ru = $du;
$du = $null;
}
}
Thanks a lot Daniel!
On Thu, Aug 29, 2013 at 10:58 AM, Marc Soda <msoda(a)coredial.com> wrote:
On Thu, Aug 29, 2013 at 3:53 AM, Daniel-Constantin
Mierla <
miconda(a)gmail.com> wrote:
--
Marc Soda, Sr. Systems Engineer
*CoreDial, LLC* | www.coredial.com
1787 Sentry Parkway West, Building 16, Suite 100, Blue Bell, PA 19422
Office: (215) 297-4400 x203 | Fax: (215) 297-4401 | Email:
msoda(a)coredial.com
- - - - -
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
what device is at 701? The 200ok receved from it
has the contact address
with the IP of kamailio:
SFLPhone
It seems there is a NAT between your kamailio
and 701, as kamailio adds
alias parameter to Contact in 200ok. That can be used to route the ack,
like:
handle_ruri_alias();
$ru = $du;
$du = $null;
There is no NAT in this scenario, although NAT support is enabled as we
will have to deal with it. Should I still use handle_ruri_alias()?
Thanks,
Marc
4150
days inactive
4151
days old
5 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Marc Soda