Hello list. I'm facing a problem with my SER configuration and a call to a NAT'd endpoint. When I call a NAT'd endpoint registered in my SER proxy, the call is established, but the last ACK message is not properly routed by SER. You can see this in the next messsage flow.
100.100.100.50 : Callee 100.100.100.99 : SER 100.100.100.231 : Called
U 100.100.100.50:5060 -> 100.100.100.99:5060 INVITE sip:008991000404@sip.mydomain.com SIP/2.0. Via: SIP/2.0/UDP 100.100.100.50;rport;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000010f. Contact: sip:551100000121@100.100.100.50;user=phone.
U 100.100.100.99:5060 -> 100.100.100.50:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000 010f.
U 100.100.100.99:5060 -> 100.100.100.231:62447 INVITE sip:551100000684@100.100.100.231;user=phone SIP/2.0. Record-Route: sip:100.100.100.99;ftag=979715625143;lr=on. Via: SIP/2.0/UDP 100.100.100.99;branch=z9hG4bKe4c7.150a3f81.0. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000 010f. Contact: sip:551100000121@100.100.100.50;user=phone.
U 100.100.100.231:62447 -> 100.100.100.99:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 100.100.100.99;branch=z9hG4bKe4c7.150a3f81.0,SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000 010f.
(The call is answered)
U 100.100.100.231:62447 -> 100.100.100.99:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.99;branch=z9hG4bKe4c7.150a3f81.0,SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000 010f. Contact: sip:551100000684@100.100.100.231;user=phone.
U 100.100.100.99:5060 -> 100.100.100.50:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000 010f. Contact: sip:551100000684@100.100.100.231;user=phone.
U 100.100.100.50:5060 -> 100.100.100.99:5060 ACK sip:551100000684@100.100.100.231;user=phone SIP/2.0. Via: SIP/2.0/UDP 100.100.100.50;rport;branch=z9hG4bK404c94810000005a43b2b7f00000182a00000112. Route: sip:100.100.100.99;ftag=979715625143;lr=on.
U 100.100.100.99:5060 -> 100.100.100.231:5060 ACK sip:551100000684@100.100.100.231;user=phone SIP/2.0. Record-Route: sip:100.100.100.99;ftag=979715625143;lr=on. Via: SIP/2.0/UDP 100.100.100.99;branch=0. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7f00000182a0000 0112.
U 100.100.100.231:62447 -> 100.100.100.99:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.99;branch=z9hG4bKe4c7.150a3f81.0,SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000 010f. Contact: sip:551100000684@100.100.100.231;user=phone.
U 100.100.100.99:5060 -> 100.100.100.50:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000 010f. Contact: sip:551100000684@100.100.100.231;user=phone.
U 100.100.100.50:5060 -> 100.100.100.99:5060 ACK sip:551100000684@100.100.100.231;user=phone SIP/2.0. Via: SIP/2.0/UDP 100.100.100.50;rport;branch=z9hG4bK404c94810000005a43b2b7f000001d6e00000114. Route: sip:100.100.100.99;ftag=979715625143;lr=on. .
U 100.100.100.99:5060 -> 100.100.100.231:5060 ACK sip:551100000684@100.100.100.231;user=phone SIP/2.0. Record-Route: sip:100.100.100.99;ftag=979715625143;lr=on. Via: SIP/2.0/UDP 100.100.100.99;branch=0. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7f000001d6e0000 0114.
(.........)
(Timeout and the call is released)
U 100.100.100.231:62447 -> 100.100.100.99:5060 BYE sip:551100000121@100.100.100.50;user=phone SIP/2.0. Via: SIP/2.0/UDP 192.168.1.20;rport;branch=z9hG4bKc0a801140000002643b2a9be000036e10000001f.
Route: sip:100.100.100.99;ftag=979715625143;lr=on. .
U 100.100.100.99:5060 -> 100.100.100.50:5060 BYE sip:551100000121@100.100.100.50;user=phone SIP/2.0. Record-Route: sip:100.100.100.99;ftag=93794163011;lr=on. Via: SIP/2.0/UDP 100.100.100.99;branch=z9hG4bK15c7.924c3535.0. Via: SIP/2.0/UDP 192.168.1.20;received=100.100.100.231;rport=62447;branch=z9hG4bKc0a801140000 002643b2a9be000036e10000001f.
U 100.100.100.50:5060 -> 100.100.100.99:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.99;branch=z9hG4bK15c7.924c3535.0,SIP/2.0/UDP 192.168.1.20;rport=62447;received=100.100.100.231;branch=z9hG4bKc0a801140000 002643b2a9be000036e10000001f.
U 100.100.100.99:5060 -> 100.100.100.231:62447 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.1.20;rport=62447;received=100.100.100.231;branch=z9hG4bKc0a801140000 002643b2a9be000036e10000001f.
I don't understand why the the ACK message is routed to port 5060 and not to the port 62447 like the INVITE or the final OK. Is this maybe a configuration problem?. My ser.cfg is based on the onsip.org configuration documents plus some modifications by me.
Can someone help me here Thanks in advance Ricardo Martinez.-
I don't understand why the the ACK message is routed to port 5060 and not to the port 62447 like the INVITE or the final OK. Is this maybe a configuration problem?.
Its probably a config issue. When the call is answered, your SER has to rewrite the Contact with the right port
U 100.100.100.99:5060 -> 100.100.100.50:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000
010f. Contact: sip:551100000684@100.100.100.231;user=phone.
If not, then the ACK is not going to go to the right port (62447).
This will normally be accomplished by your onreply_route.
For example: onreply_route[1] { fix_nated_contact(); };
My ser.cfg is based on the onsip.org configuration documents plus some modifications by me.
Can someone help me here Thanks in advance Ricardo Martinez.-
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Andres.. Thanks for your reply.. that's the weird part.. my configuration is based on the "Getting Started document"... so .. in my onreply_route i have :
if (client_nat_test("1")) { fix_nated_contact(); };
i don't understand why is not working...
Ricardo.-
-----Mensaje original----- De: Andres [mailto:andres@telesip.net] Enviado el: jueves, 15 de noviembre de 2007 12:07 Para: Ricardo Martinez CC: serusers@lists.iptel.org Asunto: Re: [Serusers] ACK Problem : Not routed to NAT'd port
I don't understand why the the ACK message is routed to port 5060 and not to the port 62447 like the INVITE or the final OK. Is this maybe a configuration problem?.
Its probably a config issue. When the call is answered, your SER has to rewrite the Contact with the right port
U 100.100.100.99:5060 -> 100.100.100.50:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000
010f. Contact: sip:551100000684@100.100.100.231;user=phone.
If not, then the ACK is not going to go to the right port (62447).
This will normally be accomplished by your onreply_route.
For example: onreply_route[1] { fix_nated_contact(); };
My ser.cfg is based on the onsip.org configuration documents plus some modifications by me.
Can someone help me here Thanks in advance Ricardo Martinez.-
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Try force_rport() at your onreply_route onreply_route[1] { if (nat_uac_test("9")) { force_rport(); fix_nated_contact(); fix_nated_sdp("3"); } }
Hope this helps you, Kostas
Ricardo Martinez wrote:
Hi Andres.. Thanks for your reply.. that's the weird part.. my configuration is based on the "Getting Started document"... so .. in my onreply_route i have :
if (client_nat_test("1")) { fix_nated_contact(); };i don't understand why is not working...
Ricardo.-
-----Mensaje original----- De: Andres [mailto:andres@telesip.net] Enviado el: jueves, 15 de noviembre de 2007 12:07 Para: Ricardo Martinez CC: serusers@lists.iptel.org Asunto: Re: [Serusers] ACK Problem : Not routed to NAT'd port
I don't understand why the the ACK message is routed to port 5060 and not to the port 62447 like the INVITE or the final OK. Is this maybe a configuration problem?.
Its probably a config issue. When the call is answered, your SER has to rewrite the Contact with the right port
U 100.100.100.99:5060 -> 100.100.100.50:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000
010f. Contact: sip:551100000684@100.100.100.231;user=phone.
If not, then the ACK is not going to go to the right port (62447).
This will normally be accomplished by your onreply_route.
For example: onreply_route[1] { fix_nated_contact(); };
My ser.cfg is based on the onsip.org configuration documents plus some modifications by me.
Can someone help me here Thanks in advance Ricardo Martinez.-
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Ricardo Martinez wrote:
Hi Andres.. Thanks for your reply.. that's the weird part.. my configuration is based on the "Getting Started document"... so .. in my onreply_route i have :
if (client_nat_test("1")) {
Maybe this nat_test is not evaluating to true. Are you sure you know what client_nat_test("1") checks for? Put some LOG message in there to see if it is hitting the statemenet as true. Try with a client_nat_test("19") and see what happens. (actually in our version it is nat_uac_test("19")).
fix_nated_contact(); };i don't understand why is not working...
Ricardo.-
-----Mensaje original----- De: Andres [mailto:andres@telesip.net] Enviado el: jueves, 15 de noviembre de 2007 12:07 Para: Ricardo Martinez CC: serusers@lists.iptel.org Asunto: Re: [Serusers] ACK Problem : Not routed to NAT'd port
I don't understand why the the ACK message is routed to port 5060 and not to the port 62447 like the INVITE or the final OK. Is this maybe a configuration problem?.
Its probably a config issue. When the call is answered, your SER has to rewrite the Contact with the right port
U 100.100.100.99:5060 -> 100.100.100.50:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 100.100.100.50;rport=5060;branch=z9hG4bK404c94810000005a43b2b7ee000053dc0000
010f. Contact: sip:551100000684@100.100.100.231;user=phone.
If not, then the ACK is not going to go to the right port (62447).
This will normally be accomplished by your onreply_route.
For example: onreply_route[1] { fix_nated_contact(); };
My ser.cfg is based on the onsip.org configuration documents plus some modifications by me.
Can someone help me here Thanks in advance Ricardo Martinez.-
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Andres wrote:
Ricardo Martinez wrote:
Hi Andres.. Thanks for your reply.. that's the weird part.. my configuration is based on the "Getting Started document"... so .. in my onreply_route i have :
if (client_nat_test("1")) {Maybe this nat_test is not evaluating to true. Are you sure you know what client_nat_test("1") checks for? Put some LOG message in there to see if it is hitting the statemenet as true. Try with a client_nat_test("19") and see what happens. (actually in our version it is nat_uac_test("19")).
Ah.. I see that this client_nat_test is for mediaproxy and that it only goes up to 7. Not sure if that is going to help. Maybe you should try the nathelper test instead which is what we use (nat_uac_test("19")). It is very thorough.
-
Andres -
Kostas Marneris -
Ricardo Martinez