Hi, I have Openser 1.1 with Mediaproxy terminating calls to a AS5350 Cisco gateway. Everything works fine, except when the PSTN party terminates the call. The cisco gateway then sends a bye message to the user-agents internal IP address instead of to the sip proxy's ip address. Here's an ngrep: 1.2.3.204=cisco gateway 1.2.3.201=openser proxy 62.1.2.122=useragent external ip 192.168.1.10 = useragent internal ip
U 1.2.3.201:5060 -> 192.168.1.10:5060 BYE sip:test@62.1.2.122:5060 SIP/2.0. Record-Route: sip:1.2.3.201;lr=on;ftag=E6EFE450-D54. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bKebda.e0002794.0. Via: SIP/2.0/UDP 1.2.3.204:5060;branch=z9hG4bKCC881474. From: sip:04766343@192.168.1.10;tag=E6EFE450-D54. To: "3227842234" sip:101002936@sip.server.com;tag=6b26b6926603729o0. Date: Tue, 23 Oct 2007 20:36:05 GMT. Call-ID: 656e89a4-6b2eb629@192.168.1.24. User-Agent: Cisco-SIPGateway/IOS-12.x. Max-Forwards: 69. Route: sip:192.168.1.10;lr=on;ftag=6b26b6926603729o0;vsf=AAAAAEVVQkRwAwABGHFFUV5SAFpCaWVuc2ludmVzdG1lbnQuY29t. Timestamp: 1193171774. CSeq: 101 BYE. Reason: Q.850;cause=16. Content-Length: 0.
So it looks to me like the Cisco is simply ignoring the record-route header. Is this a config error in the cisco, or in Openser? Pertinent bits of the openser config are:
# Record Route Section if (method=="INVITE" && client_nat_test("3")) { record_route_preset("1.2.3.201:5060;nat=yes"); } else if (method!="REGISTER") { record_route(); }; # Call Tear Down Section if (method=="BYE" || method=="CANCEL") { end_media_session(); }; # Loose Route Section if (loose_route()) { if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); exit; }; if (method=="INVITE") { if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); exit; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); exit; }; consume_credentials(); }; if (client_nat_test("3")||search("^Route:.*;nat=yes")){ setflag(6); use_media_proxy(); }; }; route(1); exit; }; # Call Type Processing Section if (!is_uri_host_local()) { if (is_from_local() || allow_trusted()) { route(4); route(1); } else { sl_send_reply("403", "Forbidden"); }; exit; }; if (method=="ACK") { route(1); exit; } else if (method=="CANCEL") { route(1); exit; } else if (method=="INVITE") { route(3); exit; } else if (method=="REGISTER") { route(2); exit; };
route[1] { # Default Message Handler t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; } route[2] { # REGISTER Message Handler # snipped } route[3] { # INVITE Message Handler if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); }; if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); exit; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); exit; }; consume_credentials(); }; lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); exit; }; route(4); route(5); exit; }; route[4] { # NAT Traversal Section if (isflagset(6) || isflagset(7)) { if (!isflagset(8)) { setflag(8); use_media_proxy(); }; }; }
route[5] { # PSTN Handler Cisco rewritehost("1.2.3.204"); route(1); } failure_route[1] { end_media_session(); } onreply_route[1] { if (status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:[ ]*0")) { use_media_proxy(); }; }; if (client_nat_test("1")) { fix_nated_contact(); }; }
Thanks for any help,
Richard
El Miércoles, 24 de Octubre de 2007, Richard Bennett escribió:
Hi, I have Openser 1.1 with Mediaproxy terminating calls to a AS5350 Cisco gateway. Everything works fine, except when the PSTN party terminates the call. The cisco gateway then sends a bye message to the user-agents internal IP address instead of to the sip proxy's ip address. Here's an ngrep: 1.2.3.204=cisco gateway 1.2.3.201=openser proxy 62.1.2.122=useragent external ip 192.168.1.10 = useragent internal ip
U 1.2.3.201:5060 -> 192.168.1.10:5060 BYE sip:test@62.1.2.122:5060 SIP/2.0. Record-Route: sip:1.2.3.201;lr=on;ftag=E6EFE450-D54. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bKebda.e0002794.0. Via: SIP/2.0/UDP 1.2.3.204:5060;branch=z9hG4bKCC881474. From: sip:04766343@192.168.1.10;tag=E6EFE450-D54. To: "3227842234" sip:101002936@sip.server.com;tag=6b26b6926603729o0. Date: Tue, 23 Oct 2007 20:36:05 GMT. Call-ID: 656e89a4-6b2eb629@192.168.1.24. User-Agent: Cisco-SIPGateway/IOS-12.x. Max-Forwards: 69. Route: sip:192.168.1.10;lr=on;ftag=6b26b6926603729o0;vsf=AAAAAEVVQkRwAwABGHFFUV5S AFpCaWVuc2ludmVzdG1lbnQuY29t. Timestamp: 1193171774. CSeq: 101 BYE. Reason: Q.850;cause=16. Content-Length: 0.
So it looks to me like the Cisco is simply ignoring the record-route header.
Could you capture the packet from Cisco to OpenSer in from of the capture you show now (that is from OpenSer to 192.168.1.10)?.
In fact, it could be useful a entire trace:
- INVITE from client to OpenSer. - INVITE from OpenSer to Cisco. - ACK - BYE from Cisco.
On Wed, 24 Oct 2007 09:42:21 +0200, Iñaki Baz Castillo ibc@aliax.net wrote:
Could you capture the packet from Cisco to OpenSer in from of the capture you show now (that is from OpenSer to 192.168.1.10)?. In fact, it could be useful a entire trace:
- INVITE from client to OpenSer.
- INVITE from OpenSer to Cisco.
- ACK
- BYE from Cisco.
Thanks Iñaki and Bogdan for looking. I had misread the trace, as you say it seems it is my openser proxy that is not handling nat correctly for the bye messages. However, it works fine when used directly from a natted useragent, like a linksys ata. The following setup is causing the problems:
UA-Linksys -> Openser-Internal-proxy/UAC -> NAT/DSL -> Openser Proxy -> Cisco gateway.
So the user agent registers with the internal Openser that is using the user agent module to send the call to the Openser proxy on the internet, that terminates the call to the cisco. When the PSTN side then ends the call the cisco sends a bye to the openser proxy, but the proxy doesn't use the external ip address when forwarding the bye on:
1.2.3.201 = Openser proxy 1.2.3.204 = Cisco gateway 62.1.2.122 = 2nd Openser proxy with user agent module external IP 192.168.1.10 = 2nd Openser proxy with user agent module internal IP 192.168.1.24 = Actual user agent internal IP.
U 62.1.2.122:5060 -> 1.2.3.201:5060 INVITE sip:0222234359@1.2.3.201:5060;transport=udp SIP/2.0. Record-Route: sip:192.168.1.10;lr=on;ftag=3682a625cb42f09fo0; vsf=AAAAAEVVQkRwAwABGHFFUV5SAFpCaWVuc2ludmVzdG1lbnQuY29t. Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK811a.687048d4.0. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 1.2.3.201:5060 -> 62.1.2.122:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK811a.687048d4.0; rport=5060;received=62.1.2.122. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 62.1.2.122:5060 -> 1.2.3.201:5060 ACK sip:0222234359@1.2.3.201:5060;transport=udp SIP/2.0. Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK811a.687048d4.0.
U 62.1.2.122:5060 -> 1.2.3.201:5060 INVITE sip:0222234359@1.2.3.201:5060;transport=udp SIP/2.0. Record-Route: sip:192.168.1.10;lr=on;ftag=3682a625cb42f09fo0; vsf=AAAAAEVVQkRwAwABGHFFUV5SAFpCaWVuc2ludmVzdG1lbnQuY29t. Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK811a.687048d4.1. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 1.2.3.201:5060 -> 62.1.2.122:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK811a.687048d4.1; rport=5060;received=62.1.2.122. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 1.2.3.201:5060 -> 1.2.3.204:5060 INVITE sip:20200222234359@1.2.3.204:5060;transport=udp SIP/2.0. Record-Route: sip:1.2.3.201:5060;nat=yes;ftag=3682a625cb42f09fo0;lr=on. Record-Route: sip:192.168.1.10;lr=on;ftag=3682a625cb42f09fo0; vsf=AAAAAEVVQkRwAwABGHFFUV5SAFpCaWVuc2ludmVzdG1lbnQuY29t. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bK811a.f3a63b41.0. Via: SIP/2.0/UDP 192.168.1.10;rport=5060;received=62.1.2.122; branch=z9hG4bK811a.687048d4.1. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 1.2.3.204:50364 -> 1.2.3.201:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bK811a.f3a63b41.0,SIP/2.0/UDP 192.168.1.10;rport=5060;received=62.1.2.122;branch=z9hG4bK811a.687048d4.1,SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 1.2.3.204:50364 -> 1.2.3.201:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bK811a.f3a63b41.0,SIP/2.0/UDP 192.168.1.10;rport=5060;received=62.1.2.122;branch=z9hG4bK811a.687048d4.1,SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 1.2.3.201:5060 -> 62.1.2.122:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 192.168.1.10;rport=5060;received=62.1.2.122;branch=z9hG4bK811a.687048d4.1,SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 1.2.3.204:50364 -> 1.2.3.201:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bK811a.f3a63b41.0,SIP/2.0/UDP 192.168.1.10;rport=5060;received=62.1.2.122;branch=z9hG4bK811a.687048d4.1,SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 1.2.3.201:5060 -> 62.1.2.122:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.1.10;rport=5060;received=62.1.2.122;branch=z9hG4bK811a.687048d4.1,SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
U 62.1.2.122:5060 -> 1.2.3.201:5060 ACK sip:20200222234359@1.2.3.204:5060 SIP/2.0. Record-Route: sip:192.168.1.10;lr=on;ftag=3682a625cb42f09fo0. Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK811a.687048d4.3. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-c009ea18.
U 1.2.3.201:5060 -> 1.2.3.204:5060 ACK sip:20200222234359@1.2.3.204:5060 SIP/2.0. Record-Route: sip:1.2.3.201;lr=on;ftag=3682a625cb42f09fo0. Record-Route: sip:192.168.1.10;lr=on;ftag=3682a625cb42f09fo0. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bK811a.f3a63b41.2. Via: SIP/2.0/UDP 192.168.1.10;received=62.1.2.122;branch=z9hG4bK811a.687048d4.3. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-c009ea18.
U 1.2.3.204:50364 -> 1.2.3.201:5060 BYE sip:test@62.1.2.122:5060 SIP/2.0. Via: SIP/2.0/UDP 1.2.3.204:5060;branch=z9hG4bKCF2C1358.
U 1.2.3.201:5060 -> 192.168.1.10:5060 BYE sip:test@62.1.2.122:5060 SIP/2.0. Record-Route: sip:1.2.3.201;lr=on;ftag=EC0DEF7C-ECF. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bKb11a.8612b353.0. Via: SIP/2.0/UDP 1.2.3.204:5060;branch=z9hG4bKCF2C1358.
At this point we get in to lots of repeated byes with the wrong IP address. The full trace is also attached, and my openser config was in the first mail in this thread,
Thanks for any pointers on handling nat for bye messages.
Richard.
El Thursday 25 October 2007 12:17:01 Richard Bennett escribió:
1.2.3.201 = Openser proxy 1.2.3.204 = Cisco gateway 62.1.2.122 = 2nd Openser proxy with user agent module external IP 192.168.1.10 = 2nd Openser proxy with user agent module internal IP 192.168.1.24 = Actual user agent internal IP.
U 62.1.2.122:5060 -> 1.2.3.201:5060 INVITE sip:0222234359@1.2.3.201:5060;transport=udp SIP/2.0. Record-Route: <sip:192.168.1.10;lr=on;ftag=3682a625cb42f09fo0;
^^^^^^^
vsf=AAAAAEVVQkRwAwABGHFFUV5SAFpCaWVuc2ludmVzdG1lbnQuY29t>. Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK811a.687048d4.0. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
The problem is in the Record-Route added by LAN OpenSer (192.168.1.10).
It should set: Record-Route: <sip:62.1.2.122:5060 SIP/2.0>
so in-dialog request from public OpenSer (1.2.3.201) would be ruted to LAN OpenSer instead of 192.168.1.10. In fact, if you run in public OpenSer: tcpdump -i any -n port 5060 you'll see UDP packets to 192.168.1.10:5060 when receiving the BYE from Cisco.
Solution: you should use in LAN OpenSer: record_route_preset("62.1.2.122:5060"); isntead of: record_route();
Check it since I've never user that function.
Regards.
On Thu, 25 Oct 2007 12:30:35 +0200, Iñaki Baz Castillo ibc@in.ilimit.es wrote:
U 62.1.2.122:5060 -> 1.2.3.201:5060 INVITE sip:0222234359@1.2.3.201:5060;transport=udp SIP/2.0. Record-Route: <sip:192.168.1.10;lr=on;ftag=3682a625cb42f09fo0;
^^^^^^^
vsf=AAAAAEVVQkRwAwABGHFFUV5SAFpCaWVuc2ludmVzdG1lbnQuY29t>. Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK811a.687048d4.0. Via: SIP/2.0/UDP 192.168.1.24:5060;branch=z9hG4bK-83909174.
The problem is in the Record-Route added by LAN OpenSer (192.168.1.10). It should set: Record-Route: <sip:62.1.2.122:5060 SIP/2.0>
That makes sense. Thanks for the pointer, I'll give it a try.
Richard.
Hi Richard,
Can you post the INVITE request/reply received by the GW?
Regards, bogdan
Richard Bennett wrote:
Hi, I have Openser 1.1 with Mediaproxy terminating calls to a AS5350 Cisco gateway. Everything works fine, except when the PSTN party terminates the call. The cisco gateway then sends a bye message to the user-agents internal IP address instead of to the sip proxy's ip address. Here's an ngrep: 1.2.3.204=cisco gateway 1.2.3.201=openser proxy 62.1.2.122=useragent external ip 192.168.1.10 = useragent internal ip
U 1.2.3.201:5060 -> 192.168.1.10:5060 BYE sip:test@62.1.2.122:5060 SIP/2.0. Record-Route: sip:1.2.3.201;lr=on;ftag=E6EFE450-D54. Via: SIP/2.0/UDP 1.2.3.201;branch=z9hG4bKebda.e0002794.0. Via: SIP/2.0/UDP 1.2.3.204:5060;branch=z9hG4bKCC881474. From: sip:04766343@192.168.1.10;tag=E6EFE450-D54. To: "3227842234" sip:101002936@sip.server.com;tag=6b26b6926603729o0. Date: Tue, 23 Oct 2007 20:36:05 GMT. Call-ID: 656e89a4-6b2eb629@192.168.1.24. User-Agent: Cisco-SIPGateway/IOS-12.x. Max-Forwards: 69. Route: sip:192.168.1.10;lr=on;ftag=6b26b6926603729o0;vsf=AAAAAEVVQkRwAwABGHFFUV5SAFpCaWVuc2ludmVzdG1lbnQuY29t.
Timestamp: 1193171774. CSeq: 101 BYE. Reason: Q.850;cause=16. Content-Length: 0.
So it looks to me like the Cisco is simply ignoring the record-route header. Is this a config error in the cisco, or in Openser? Pertinent bits of the openser config are:
# Record Route Section if (method=="INVITE" && client_nat_test("3")) { record_route_preset("1.2.3.201:5060;nat=yes"); } else if (method!="REGISTER") { record_route(); }; # Call Tear Down Section if (method=="BYE" || method=="CANCEL") { end_media_session(); }; # Loose Route Section if (loose_route()) { if ((method=="INVITE" || method=="REFER") &&
!has_totag()) { sl_send_reply("403", "Forbidden"); exit; }; if (method=="INVITE") { if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); exit; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); exit; }; consume_credentials(); }; if (client_nat_test("3")||search("^Route:.*;nat=yes")){ setflag(6); use_media_proxy(); }; }; route(1); exit; }; # Call Type Processing Section if (!is_uri_host_local()) { if (is_from_local() || allow_trusted()) { route(4); route(1); } else { sl_send_reply("403", "Forbidden"); }; exit; }; if (method=="ACK") { route(1); exit; } else if (method=="CANCEL") { route(1); exit; } else if (method=="INVITE") { route(3); exit; } else if (method=="REGISTER") { route(2); exit; };
route[1] { # Default Message Handler t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; } route[2] { # REGISTER Message Handler # snipped } route[3] { # INVITE Message Handler if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); }; if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); exit; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); exit; }; consume_credentials(); }; lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); exit; }; route(4); route(5); exit; }; route[4] { # NAT Traversal Section if (isflagset(6) || isflagset(7)) { if (!isflagset(8)) { setflag(8); use_media_proxy(); }; }; }
route[5] { # PSTN Handler Cisco rewritehost("1.2.3.204"); route(1); } failure_route[1] { end_media_session(); } onreply_route[1] { if (status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:[ ]*0")) { use_media_proxy(); }; }; if (client_nat_test("1")) { fix_nated_contact(); }; }
Thanks for any help,
Richard
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users