RE: [Serusers] udp error

see recent Jan's post: -- an example configuration file including nathelper support is in the CVS in sip_router/etc/nathelper.cfg. Note that it requires unstable branch and all the stuff is experimental.

Jan. --

At 02:01 AM 11/7/2003, Stephen Miles wrote:

Hi Jiri,

Thanks for that, makes a lot of sence. I did think thats what we were doing so here is my config file for you to have a look at.

Could you go through it and tell me where I am going wrong?

Thanks much,

Stephen

route{ loose_route(); force_rport(); fix_nated_contact(); # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; };

   # we record-route all messages -- to make sure that
   # subsequent messages will go through our proxy; that's
   # particularly good if upstream and downstream entities
   # use different transport protocol
   if(method=="REGISTER") {
     setflag(1); # remember this is ATA
     force_rport();
     fix_nated_contact();
     log("LOG: In NAT clause\n");
     #fix_nated_sdp("3");
   };
   if (!method=="REGISTER") record_route();

   # subsequent messages withing a dialog should take the
   # path determined by record-routing
   if (loose_route()) {
           # mark routing logic in request
           append_hf("P-hint: rr-enforced\r\n");
           route(1);
           break;
   };
   if (uri=~"portal.commverge.co.nz") {
          if (method=="REGISTER") {
             # Uncomment this if you want to use digest authentication
             if (!www_authorize("portal.commverge.co.nz", "subscriber")) {
               www_challenge("portal.commverge.co.nz", "0");
               break;
             };
             save("location");
             break;
           };
           # native SIP destinations are handled using our USRLOC DB
           if (!lookup("location")) {
             forward(202.180.125.200,5060);
             break;
           };
           # user on-line...forward to his current destination
           forward(uri:host,uri:port);
           break;
   };
   if (uri=~"202.180.83.14") {
     log("LOG: In Portal clause!\n");
     rewritehostport("portal.commverge.co.nz:5060");
     log("LOG: Out of Portal clause!\n");
   };

   if (!lookup("location")) {
      forward(202.180.125.200,5060);
      break;
   };
   # user on-line...forward to his current destination
   forward(uri:host,uri:port);
   break;

}

route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }

-----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Friday, 7 November 2003 12:42 p.m. To: Stephen Miles Subject: RE: [Serusers] udp error

At 12:15 AM 11/7/2003, Stephen Miles wrote:

...

Hi Jiri,

SIP support is not turned on on our pix so it is just acting as a nat device, much the same as a linux box or standard router.

Than you will need RTP relay. Otherwise the media from public internet to your natted client will be dropped by the nat box. Also, you will have to configure ser to send replies symmetricaly (as opposed to address advertised in Via). Use force_rport for that.

...

What is happening though is that the firewall (pix in this case, cisco 827 in others) is not forwarding/natting the same port as the original request. e.i 192.168.18.12 sends sip message to portal on port 5060, firewall gets that and nats it but uses the next avalible port to send out on so the portal (our sip proxy running ser) gets the request from firewall:next_avalible_port, not firewall:5060. It seems that ser doesn't realise this and thats why we get the error, if I set my softphone (X-Lite) to use the next port the firewall is going to use (from watching logs etc) is works. Sortphone sends register as 192.168.18.12:65389 and the firewall does the same firewall:65389 and it works against ser, phone registers and calls can be make.

SIP servers are supposed to reply to port number advertised in rquest's topmost via header field.

...

I hope this makes more sence. If not please let me know as this could be a bit of a show stopper for us using ser and we would very much like to.

Nevertheless, the rtp relay workaround along with SER configured in a nat-friendly manner should help you out.

-jiri

-- Jiri Kuthan http://iptel.org/~jiri/