[Serusers] Routing of a certain number range to PSTN

Greger V. Teigre greger at teigre.com
Mon Nov 22 15:43:38 CET 2004


Matt,
I prefer that you copy the serusers lists. This way more people will benefit 
from problems that others have had.

To understand this, you must understand what happens in if(!t_relay()):  You 
are actually relaying (or transfering) the call based on the processing you 
have done so far.  If the call fails, it's an error where you never reached 
the onrepl_route (and not as you log: "Call NOT in usrloc"). Any answer from 
the party you relayed to should be sent back, i.e.:
        if (!t_relay()) {
                sl_reply_error();
                break;
        };


Suggested example:
1. In your main route section, add something like this:
        # Username part is our number range, route locally
        if (uri=~"sip:[0-9]*@sipout\.netlogic\.net") {
                route(1);
                break;
        };

2. Add a route 1 starting with:
        if (!lookup("location")) {
                log(1,"Not found in location");
                sl_send_reply("404", "Not found");
                break;
        };
3. Then do your test on isflagset()/force proxy, set t_on_reply for handling 
replies, and THEN call t_relay()

The best is to handle groups of requests together, i.e. your route 1 should 
handle all local and inbound traffic. The test in item 1 above should then 
match all calls from PSTN destined for your users.  You may add a test for 
src_ip or rewrite the uri.

Hope this helps.  Ser's config script is very powerful and I think you 
should think in terms of programming and flowcharts when designing a script, 
not as a config file like the cfg extension implies.

g-)



Matt Schulte wrote:
> I did have a followup question, if I may.. I can't figure out how I
> would do call routing with small IAD's (such as grandstream's,
> sipura's, snom200). Basically we're going to be sending everything to
> PSTN, no "internet" type routing. So our outbound calls are going to
> look like this:
>
> 6365551212 at proxy.netlogic.net
>
> Incoming calls will also be phone number style:
>
> 6364444141 at proxy.netlogic.net
>
> As you may or may not tell, this is a problem. I'm trying to figure
> out a way to route these calls in SER and am having no luck. This is
> my "routing" line:
>
>        if (!t_relay()) {
>                log(1, "LOG: Call NOT in usrloc\n");
>        } else if (uri=~"^sip:[0-9]*@sipout\.netlogic\.net") { # ...
> forward to gateways then;
>                                forward(206.80.76.158, 5060);
>                                log(1, "LOG: Tapping rowlf\n");
>                                break;
>                        }
> As you can see I tried an alternate address to route the calls, what
> happens is it creates a routing loop. If I try a METHOD==INVITE, then
> the NAThelper stuff breaks (per my last problem). Any suggestions? I
> was trying to make my sipura/snom send out as sipout.* but I can't
> seem to figure out how to make them do that.
>
> Thanks I hope this makes sense :/
>
> Matt
>
> -----Original Message-----
> From: Greger V. Teigre [mailto:greger at teigre.com]
> Sent: Monday, November 22, 2004 7:18 AM
> To: Matt Schulte
> Subject: Re: [Serusers] NATHelper + usrloc (+ rtpproxy?)
>
>
> Good to hear!  The uri==myself should have nothing to do with the
> client.
> It is a test for evaluating whether to To (uri) is destined for your
> server.
> The alias= statments at the beginning of ser.cfg will be used to
> determine
> this.  The alias lookup will potentially change the uri, so it is
> often used
> to detect if the INVITE is still for this server or should be
> forwarded. Regards, Greger
>
> Matt Schulte wrote:
>> This is working now, I had my t_relay/forward's below the t_on_reply
>> but they didn't work. I went back to the default nathelper.cfg and it
>> seems to work. Also to note, for some reason asterisk, sipura's, and
>> grandstream's don't seem to work with any uri==myself statements.
>> Even
>
>> if you debug sip it'll show it's going to the proper address.
>>
>> Thanks.
>>
>> -----Original Message-----
>> From: Greger V. Teigre [mailto:greger at teigre.com]
>> Sent: Friday, November 19, 2004 6:21 AM
>> To: serusers at lists.iptel.org
>> Subject: Re: [Serusers] NATHelper + usrloc (+ rtpproxy?)
>>
>>
>> Hi Matt,
>> When a non-NATed incoming call to a NATed client is processed
>> (INVITE), you must make sure that you have a  t_on_reply("1"); before
>> you call t_relay (or forward).  The INVITE will not be detected as
>> behind a NAT, but the destination is (flag is set), and the reply
>> will
>
>> take care of the rewrite.
>>    In your config, it looks like you call t_relay before setting
>> t_on_reply("1"); further down.  A forward will only forward the SIP
>> INVITE to another SIP proxy for processing.
>>    Paul (Java Rockx) just recently posted his config file with a
>> working NAThelper/RTPproxy setup. I suggest you look at the call
>> logic
>
>> found there. His config is also easy to read with a lot of nice
>>    headers I haven't tested RTP proxy between a client behind NAT and
>> Asterisk, but I believe that as long as you record-route the INVITE
>> (as you do) and handle the replies properly, it should work.
>> g-)
>>
>>> Matt Schulte wrote:
>>>> Another note to this, I moved my 'forward' and lookup statements
>>>> down
>>
>>>> below the t_onreply statement. I figured this should allow ser to
>>>> see
>>
>>>> that the client is in fact behind a NAT. It catches that now
>>>> however
>
>>>> I see this in my debug (ser):
>>>>
>>>> ser[21770]: transaction was sent to a NATED client -> fix nated
>>>> contact ser[21770]: ERROR: on_reply processing failed
>>>>
>>>> Could the last error be a/the problem? Come on I know someone else
>>>> has had this problem. Please help!
>>>> NOTE: I just tested this out on Asterisk (as a client behind NAT)
>>>> and
>>
>>>> got the same results. It's simply not changing the RTP IP address..
>>>>
>>>> --snippet--
>>>>
>>>> onreply_route[1] {
>>>>     # NATed transaction ?
>>>>     if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
>>>>         log(1, "transaction was sent to a NATED client -> fix nated
>>>> contact\n");
>>>>         fix_nated_contact();
>>>>         force_rtp_proxy();
>>>>     # otherwise, is it a transaction behind a NAT and we did not
>>>>     # know at time of request processing ? (RFC1918 contacts)
>>>>         } else if (nat_uac_test("1")) {
>>>>         fix_nated_contact();
>>>>     };
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Matt Schulte
>>>> Sent: Thursday, November 18, 2004 8:09 AM
>>>> To: serusers at lists.iptel.org
>>>> Subject: [Serusers] NATHelper + usrloc (+ rtpproxy?)
>>>>
>>>>
>>>> All,
>>>>
>>>> This is my first post to this list so go easy on me. :-) I'm rather
>>>> new to Ser, in fact I just installed it for the first time early in
>>>> the week. I'm working on the NAThelper module to get traversal
>>>> working, I have outbound (sip phone -> NATout -> ser) working just
>>>> peachy, RTP works in both directions hooray. The question is I'm
>>>> having problems getting RTP inbound, the ring of course goes
>>>> through,
>>
>>>> and RTP from the NAT'd side of course works fine however getting
>>>> back
>>
>>>> through the NAT (from outside) for RTP in this sense fails. Let me
>>>> explain the setup:
>>>>
>>>> I'm using the registrar, NAThelper, usrloc, and of course
>>>> (Portaone's) RTPproxy modules. The current SIP phone is an SNOM
>>>> (yes
>
>>>> yes, I know..). The "endpoint" is Asterisk. When I do a sip debug
>>>> on
>
>>>> Asterisk, I see the RTP request however it's coming from the NAT'd
>>>> fake address:
>>>>
>>>> v=0
>>>> o=root 780961119 780961119 IN IP4 192.168.1.101
>>>> s=call
>>>> c=IN IP4 192.168.1.101
>>>> t=0 0
>>>> m=audio 10004 RTP/AVP 0
>>>> a=rtpmap:0 pcmu/8000
>>>> a=sendrecv
>>>>
>>>>
>>>> I have an idea of what to fix just not sure how to fix it.
>>>> Obviously
>
>>>> we need it to goto RTPproxy, since this is "backwards" how would I
>>>> get it to recognize the correct IP?
>>>>
>>>> See my config below, most of it is ripped off of the NAThelper.cfg
>>>> example. :-) Thanks all..
>>>>
>>>> NOTE: All calls are destined for ${SIPDOMAIN}, in this case, the
>>>> machines hostname. This is normal and intentional :-)
>>>>
>>>> # ---- SNIPPAGE ----
>>>> modparam("rr", "enable_full_lr", 1)
>>>>
>>>> # !! Nathelper
>>>> modparam("registrar", "nat_flag", 6)
>>>> modparam("nathelper", "natping_interval", 30) # Ping interval 30 s
>>>> modparam("nathelper", "ping_nated_only", 1)   # Ping only clients
>>>> behind NAT
>>>> # main routing logic
>>>>
>>>> route{
>>>>
>>>> # 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;
>>>>         };
>>>>         # !! Nathelper
>>>>         # Special handling for NATed clients; first, NAT test is
>>>>         # executed: it looks for via!=received and RFC1918
>>>>         addresses # in Contact (may fail if line-folding is used);
>>>>         also, # the received test should, if completed, should
>>>>         check all # vias for rpesence of received
>>>>         if (nat_uac_test("3")) {
>>>>                 # Allow RR-ed requests, as these may indicate that
>>>>                 # a NAT-enabled proxy takes care of it; unless it
>>>>                 is # a REGISTER
>>>>                 log("LOG: Caught uac test 3 \n");
>>>>                 if (method == "REGISTER" || !
>>>> search("^Record-Route:")) {
>>>>                     log("LOG: Someone trying to register from
>>>> private
>>
>>>> IP, rewriting\n");
>>>>
>>>>                     # This will work only for user agents that
>>>> support symmetric
>>>>                     # communication. We tested quite many of them
>>>> and
>>
>>>> majority is
>>>>                     # smart enough to be symmetric. In some phones
>>>> it
>>
>>>> takes a configuration
>>>>                     # option. With Cisco 7960, it is called
>>>> NAT_Enable=Yes, with kphone it is
>>>>                     # called "symmetric media" and "symmetric
>>>> signalling".
>>>>
>>>>                     fix_nated_contact(); # Rewrite contact with
>>>> source IP of signalling
>>>>                     if (method == "INVITE") {
>>>>                         log("LOG: fix nated sdp\n");
>>>>                         fix_nated_sdp("1"); # Add direction=active
>>>> to
>>
>>>> SDP
>>>>                     };
>>>>                     force_rport(); # Add rport parameter to topmost
>>>>                     Via setflag(6);    # Mark as NATed
>>>>                 };
>>>>         };
>>>>
>>>>         # 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") 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==myself) {
>>>>                 # mark routing logic in request
>>>>                 append_hf("P-hint: outbound\r\n");
>>>>                 route(1);
>>>>                 break;
>>>>         };
>>>>
>>>>
>>>>         if (uri==myself) {
>>>>
>>>>                 if (method=="REGISTER") {
>>>>                         log("LOG: Caught register, registering user
>>>> in local db\n");
>>>>                         save("location");
>>>>                         break;
>>>>                 };
>>>>
>>>>                 lookup("aliases");
>>>>                 if (!uri==myself) {
>>>>                         append_hf("P-hint: outbound alias\r\n");
>>>>                         route(1);
>>>>                         break;
>>>>                 };
>>>>                 log("LOG: Caught uri myself\n");
>>>>                 # native SIP destinations are handled using our
>>>> USRLOC DB
>>>>                 #if (!lookup("location")) {
>>>>                 #       sl_send_reply("404", "Do what now");
>>>>                 #       break;
>>>>                 #};
>>>>         };
>>>>         append_hf("P-hint: usrloc applied\r\n");
>>>>         route(1);
>>>>
>>>> }
>>>>
>>>> route[1]
>>>> {
>>>>         # !! Nathelper
>>>>         if
>>>> (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" &&
>>>>             !search("^Route:")){ sl_send_reply("479", "We don't
>>>> forward to private IP addresses");
>>>>             break;
>>>>         };
>>>>         # if client or server know to be behind a NAT, enable relay
>>>>         if (isflagset(6)) {
>>>>                 log("LOG: Caught NAT flag 6 forcing rtp proxy\n");
>>>>             force_rtp_proxy();
>>>>         };
>>>>         if (method=="REGISTER") {
>>>>                 break;
>>>>                 log("LOG: Caught Register down in our call routing,
>>>> breaking\n");
>>>>         };
>>>>
>>>> #### Below is mostly my own doing ####
>>>>         if (method=="INVITE")   {
>>>>                 log("LOG: Caught INVITE \n");
>>>>                 if (lookup("location")) {
>>>>                         log ("LOG: Caught registered invite,
>>>> sending
>
>>>> there\n");
>>>>                         # NOTE forcing rtp maybe bad idea for ALL
>>>> users, this is
>>>>                         # a quick fix (which doesn't work anyway!)
>>>>                         #force_rtp_proxy();
>>>>                         #forward(uri:host, uri:port); #nor does
>>>>                         this t_relay();
>>>>                         break;
>>>>                 } else if (uri=~"^sip:[0-9]*@") { # ... forward to
>>>> asterisk;
>>>>                         forward(xxx.xxx.xxx.xxx, 5060);
>>>>                         log("LOG: Tapping rowlf\n");
>>>>                         break;
>>>>                 };
>>>>         };
>>>> #### ####
>>>>
>>>>         t_on_reply("1");
>>>>
>>>>         if (!t_relay()) {
>>>>                 sl_reply_error();
>>>>         };
>>>> }
>>>>
>>>> # !! Nathelper
>>>> onreply_route[1] {
>>>>     # NATed transaction ?
>>>>     if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
>>>>         fix_nated_contact();
>>>>         force_rtp_proxy();
>>>>     # otherwise, is it a transaction behind a NAT and we did not
>>>>     # know at time of request processing ? (RFC1918 contacts)
>>>>     } else if (nat_uac_test("1")) {
>>>>         fix_nated_contact();
>>>>     };
>>>> }
>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers 




More information about the sr-users mailing list