[Serusers] NATHelper + usrloc (+ rtpproxy?)
Greger V. Teigre
greger at teigre.com
Fri Nov 19 14:02:13 CET 2004
I suggest you post the full SIP messages of a conversation that goes wrong.
It's a lot easier to see what's going on then.
g-)
Matt Schulte wrote:
> Ok, that's what I was stating actually. The fact that my invite's go
> below the t_on_reply, I'll paste my config update. Thanks for the info
> I'll search google for Java's implementation.
>
>
> ---SNIP---
> ser.cfg
>
>
> t_on_reply("1");
>
> if (method=="INVITE") {
> log(1, "LOG: Caught INVITE \n");
> if (lookup("location")) {
> log (1, "LOG: Caught registered user, sending
> there\n");
> # NOTE forcing rtp maybe bad idea for ALL
> users, this is
> # a quick fix
> #fix_nated_contact();
> #force_rtp_proxy();
> #forward(uri:host, uri:port);
> t_relay();
> break;
> } else if (uri=~"^sip:[0-9]*@") { # ... forward to
> gateways then;
> forward(xxx.xxx.xxx.xxx, 5060);
> log(1, "LOG: Tapping rowlf\n");
> break;
> };
> };
>
> if (!t_relay()) {
> sl_reply_error();
> };
> }
>
> # !! Nathelper
> onreply_route[1] {
> # NATed transaction ?
> # if (isflagset(6)) {
> # log(1, "transaction was sent to a NATED client -> fix
> nated contact\n");
> # fix_nated_contact();
> # force_rtp_proxy();
> # append_hf("P-hint: fixed NAT contact for
> response\r\n");
> # }
> 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: Greger V. Teigre [mailto:greger at axxessanywhere.com]
> Sent: Friday, November 19, 2004 6:21 AM
> To: Matt Schulte; 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