15 Nov
2007
15 Nov
'07
5:43 p.m.
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.-
15 Nov
15 Nov
6:06 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Andres
Technical Support
http://www.telesip.net
6:08 p.m.
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Andres
Technical Support
http://www.telesip.net
6:19 p.m.
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:57 p.m.
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(a)lists.iptel.org
Asunto: Re: [Serusers] ACK Problem : Not routed to NAT'd port
--
Andres
Technical Support
http://www.telesip.net
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8:14 p.m.
Andres wrote:
--
Andres
Technical Support
http://www.telesip.net
Ricardo Martinez wrote:
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.
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")).
6204
days inactive
6204
days old
5 comments
3 participants
participants (3)
-
Andres -
Kostas Marneris -
Ricardo Martinez