RE: [Serusers] udp error - sr-users

12 Nov 2003

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/ 