RE: [Serusers] Via RPORT for CANCEL message.

Hello list. Can anyone give me somo hints here? Is mi solution correct or maybe i'm missing something important in the configuration? Thanks! Regards, Ricardo Martinez RedVoiss -----Mensaje original----- De: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org]En nombre de Ricardo Martinez Enviado el: jueves, 17 de agosto de 2006 10:50 Para: greger(a)teigre.com CC: serusers(a)iptel.org Asunto: RV: [Serusers] Via RPORT for CANCEL message. Hello Greger and thanks for your answer I tested sending the CANCEL to route(3), and it seems to be working ok now. But now i'm facing another problem. The OK message for the BYE seems not to be routed back to the NAT'd port, instead is routed to the default port. Please check the file attached (BYE_debug.TXT). As i pointed in my first post, the calling endpoint is NAT'd. Following the BYE sequence seems to be right, it hits the loose_route section and then the route(1), but since the BYE does not contain the rport parameter in the VIA header the OK is routed back to the port advertised in the VIA header. (5061) and not to the received port. Maybe i'm doing something wrong?. I tested a new solution, but i don't know if is correct or is according to the ONSIP document. I added a client_nat_test("3") in the Call Tear Down Section- .......... # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (method=="INVITE" && client_nat_test("3")) { # INSERT YOUR IP ADDRESS HERE record_route_preset("200.100.100.246:5060;nat=yes"); } else if (method!="REGISTER") { record_route(); }; # ----------------------------------------------------------------- # Call Tear Down Section # ----------------------------------------------------------------- if (method=="BYE" || method=="CANCEL") { if (client_nat_test("3")) { force_rport(); xlog("L_INFO", "[%rm] - From:%fu ; To:%ru ; Call-ID:%ci ; Desde:%is\n - FORCE RPORT ON"); }; end_media_session(); setflag(1); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { if (has_totag() && (method=="INVITE" || method=="ACK")) { if (client_nat_test("3")||search("^Route:.*;nat=yes")){ setflag(6); use_media_proxy(); }; }; route(1); break; }; ....... Hope that someone could help me here. Thanks Regards, Ricardo Martinez.- -----Mensaje original----- De: Greger V. Teigre [mailto:greger@teigre.com] Enviado el: jueves, 17 de agosto de 2006 4:05 Para: Ricardo Martinez CC: serusers(a)iptel.org Asunto: Re: [Serusers] Via RPORT for CANCEL message. Having a quick look, you may have found a bug in the ONsip.org scripts. A CANCEL is not loose routed (a dialog has not yet been set up) and must be handled the same way as an INVITE, i.e. the only way to find the route for CANCEL is to route the CANCEL the same way you routed the INVITE. However, it seems that you have somehow has done that, as your domain has changed to @gw. in the CANCEL doing downstream (i.e. forwarded by your SER). So, CANCEL should be sent to route(3), the INVITE handler and not route(1). I'm quite sure this was correct in a previous version, we even had some discussions around how to handle it and how to describe it, but it seems that something has happened along the way. g-) Ricardo Martinez wrote: Hello. My main configuration is based on the ser.cfg from the issue 5 plus some modifications included by me. Beside that i'm using version: ser 0.9.3 (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 @(#) $Id: main.c,v 1.197 2004/12/03 19:09:31 andrei Exp $ main.c compiled on 11:03:37 Dec 22 2005 with gcc 3.2 I have a question regarding to sending a CANCEL message for an INVITE from a NAT'd endpoint. As far as i know the force_rport() command adds the received IP port to the top most via header in the SIP message, this enables subsequent SIP message to return to the proper port later on in a SIP transaction. My problem is that for a CANCEL message coming from a NAT'd endpoint this command seems not to be working. This is the scenario. NAT'd endpoint : 200.100.100.248 SER : 200.100.100.246 SER-2 : 200.100.100.36 GW : 200.100.100.69 The NAT'd endpoint send an INVITE to the proxy, but then in the middle of the transaction decide to CANCEL the request. As you can see in the "cancel_debug.txt" file included on this mail, the CANCEL message does not contain the "rport" in the Via header, so it seems to be routed back to the default sip port (5060). Is there a way to force the rport in a CANCEL? for a enpoint unable to put the rport by itself? I want to do this according to the onsip document, in a compatible way.. Anyway i made a little test including a force_rport(); in the CANCEL handler .......... # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (method=="INVITE" && client_nat_test("3")) { # INSERT YOUR IP ADDRESS HERE record_route_preset("200.100.100.246:5060;nat=yes"); } else if (method!="REGISTER") { record_route(); }; # ----------------------------------------------------------------- # Call Tear Down Section # ----------------------------------------------------------------- if (method=="BYE" || method=="CANCEL") { end_media_session(); setflag(1); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { if (has_totag() && (method=="INVITE" || method=="ACK")) { if (client_nat_test("3")||search("^Route:.*;nat=yes")){ setflag(6); use_media_proxy(); }; }; route(1); break; }; # ----------------------------------------------------------------- # 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"); }; break; }; if (method=="CANCEL") { force_rport(); route(1); break; } else if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; } else if (method=="ACK") { route(1); break; }; lookup("aliases"); if (uri!=myself) { route(4); route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); this solve my problem but it seems not to be so accurate. I hope that someone can help me Thanks! Ricardo Martinez.-