[Serusers] SER and NAT

Adrian Georgescu ag at ag-projects.com
Fri Jun 4 10:20:38 CEST 2004


On Jun 3, 2004, at 10:32 PM, XeloQ Communications wrote:

> Hello Adrian,
>
> Thanks for your answers. They were very clarifying. I test in my lab
> test  environment where i do not have any firewalls or other possible
> problem initiators.
>
> The ser.cfg example that comes with the source with mediaproxy  does  
> not
> allow non nated EP's to register. Is it possible for you to update the
> example config file so non nated ep's can also register

Its there in ser.cfg at line 30

> and do not use
> mediaproxy when traffic is between non nated ep's.

We did not use such configuration yet. If you make it work please let  
me know your tested configuration to update the documentation.

>
> NATed    -- NATed mediaproxy
> Public C -- NATed mediaproxy.
> Public C -- Public C no mediaproxy.
>
> Please just hint me in the correct direction.
>
> Here is my current ser.cfg It is not working the way i want like
> mentioned above. .
>
> #
> # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
> #
> # simple quick-start config script
> #
>
> # ----------- global configuration parameters ------------------------
>
> #debug=3         # debug level (cmd line: -dddddddddd)
> #fork=yes
> #log_stderror=no	# (cmd line: -E)
>
> /* Uncomment these lines to enter debugging mode
> debug=7
> fork=no
> log_stderror=yes
> */
>
> check_via=no	# (cmd. line: -v)
> dns=no           # (cmd. line: -r)
> rev_dns=no      # (cmd. line: -R)
> #port=5060
> #children=4
> fifo="/tmp/ser_fifo"
>
> # ------------------ module loading ----------------------------------
>
> # Uncomment this if you want to use SQL database
> loadmodule "/usr/local/lib/ser/modules/mysql.so"
>
> loadmodule "/usr/local/lib/ser/modules/sl.so"
> loadmodule "/usr/local/lib/ser/modules/tm.so"
> loadmodule "/usr/local/lib/ser/modules/rr.so"
> loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
> loadmodule "/usr/local/lib/ser/modules/usrloc.so"
> loadmodule "/usr/local/lib/ser/modules/registrar.so"
> loadmodule "/usr/local/lib/ser/modules/textops.so"
> loadmodule "/usr/local/lib/ser/modules/domain.so"
> loadmodule "/usr/local/lib/ser/modules/mediaproxy.so"
>
>
> # Uncomment this if you want digest authentication
> # mysql.so must be loaded !
> #loadmodule "/usr/local/lib/ser/modules/auth.so"
> #loadmodule "/usr/local/lib/ser/modules/auth_db.so"
>
> # ----------------- setting module-specific parameters ---------------
>
> # -- usrloc params --
>
> #modparam("usrloc", "db_mode",   0)
>
> #modparam("domain", "db_url", "sql:ser:heslo at localhost/ser") //now  
> using
> default
>
> # Uncomment this if you want to use SQL database
> # for persistent storage and comment the previous line
> #modparam("usrloc", "db_mode", 1)
>
> # -- auth params --
> # Uncomment if you are using auth module
> #
> #modparam("auth_db", "calculate_ha1", yes)
> #
> # If you set "calculate_ha1" parameter to yes (which true in this
> config),
> # uncomment also the following parameter)
> #
> #modparam("auth_db", "password_column", "password")
>
> # -- rr params --
> # add value to ;lr param to make some broken UAs happy
> modparam("rr", "enable_full_lr", 1)
>
> # -------------------------  request routing logic -------------------
>
> # main routing logic
>
> modparam("mediaproxy", "natping_interval", 60)
>
> route{
>     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;
>     };
>
>         if (client_nat_test("3")) {
>         if (method == "REGISTER" || ! search("^Record-Route:")) {
> 	        fix_contact();
>             force_rport();
> 	};
>
>
>     if (method=="INVITE") {
>         use_media_proxy();
>         t_on_reply("1");
>     };
>  };
>
>      if (method=="REGISTER") {
>
> # Uncomment this if you want to use digest authentication
> #	if (!www_authorize("200.84.12.12", "subscriber")) {
> #	www_challenge("200.84.12.12", "0");
> #	break;
> #	};
>
> 	save("location");
> 	break;
> 	};
>
> 	# native SIP destinations are handled using our USRLOC DB
> 	if (!lookup("location")) {
> 			sl_send_reply("404", "Not Found");
> 			break;
> 	};
>
>
>
>
>     if (method == "BYE" || method == "CANCEL") {
>         end_media_session();
>     };
>
>     if (loose_route()) {
>         t_relay();
>         break;
>     };
>
>    if (method == "INVITE") {
>         record_route();
>     };
>
>
>
>     if (!t_relay()) {
>         sl_reply_error();
>     };
> }
>
> onreply_route[1] {
>
>     if (status=~"(183)|2[0-9][0-9]") {
>         if (client_nat_test("1")) {
>             fix_contact();
>         };
>         use_media_proxy();
>     };
>
>     if (status=~"[3-4]0[0-9]") {
>         end_media_session();
>         break;
>     };
> }
>
>
>
>
>
>
>
> On Fri, 2004-06-04 at 00:48, Adrian Georgescu wrote:
>> Tjapko,
>>
>> See answers inline.
>>
>> On Jun 4, 2004, at 12:16 AM, Tjapko ITS Consult at ncy wrote:
>>
>>> Thanks a lot,
>>>
>>> Still I am lost. Mediaproxy works fine when Nated Ep's are calling  
>>> out
>>> to
>>> PSTN or not NAted Ep's but I can't call to any NATed EP with te  
>>> example
>>> ser.cfg that comes with mediaproxy.
>>>
>>
>> The examples from the documentation are used in production platforms.
>> They do work.
>>
>>> Mediaproxy is trying hard and doesn't give any error message but in  
>>> the
>>> sessions.py and the log I can see that the destination address for  
>>> the
>>> NAted
>>> IP (EP) is missing.
>>
>> It could be that your end points are behind a blocked firewall. You  
>> may
>> start calls from inside to a public gateway but nobody from outside
>> could initiate connections to inside.
>>
>>> I read the readme and tried everything possible but unfortunately
>>> without
>>> the desired result.
>>>
>>> Nathelper seems clear on this using the modparam ("registrar",
>>> "natflag",
>>> 6).
>>
>> The set of such flag is not mandatory.
>>
>>> Like the example in the answer from Klaus, registration from any  
>>> nated
>>> ep
>>> will be flagged. Calling to any nated EP will be easy because the
>>> destination address is flagged and saved during registration and the
>>> t_on_reply will check if the flag is set and subsequently force proxy
>>> on the
>>> recorded address. At least this is how I understand it.
>>>
>>> Studying the readme for mediaproxy tells that nat_uac_test() has to  
>>> be
>>> replaced with client_nat_test() but according the readme the only
>>> difference
>>> between the 2 is that the latter function will NOT check if the SDP
>>> body has
>>> private IP's.
>>>
>>> How can I use mediaproxy so that when calling to an NATed EP
>>> mediaproxy will
>>> be able to generate the correct destination address. Does anybody  
>>> has a
>>> snippet from a succesfull ser.cfg for me that I can study. The  
>>> comment
>>> from
>>> Adrian to replace fixed_nated_contact with fixed_contact I understand
>>> but
>>> not in relation with the setflag mentioned in the same snippet. IMHO
>>> setflag
>>> is a nathelper modparam. There must be something else that I  
>>> overlook.
>>>
>>
>> Your location table might contain private IP addresses, did you check?
>> Make sure you save the rewritten contacts during REGISTER:
>>
>>      if (client_nat_test("3")) {
>>          if (method == "REGISTER" || ! search("^Record-Route:")) {
>>              force_rport();
>>              fix_contact();
>>          };
>>      };
>>
>>
>>> Another issue that I like confirmed is that the readme states that  
>>> the
>>> Nated
>>> EP should have outbound proxy server configured for a symmetric EP  
>>> not
>>> an
>>> a-symmetric EP. . Is this true?
>>>
>>> To make a long story short...How can call TO a NATed EP with
>>> mediaproxy so
>>> it knows the correct destination address and is it neccesary to
>>> configure
>>> outbound proxy for a symmetric NAted EP's.
>>
>> Just set the outbound proxy to be the same as the SIP Proxy.
>>
>>>
>>> My gateway provider tells me to drop all this and use a STUN server  
>>> in
>>> stead. :-(
>>>
>>
>> STUN will not cross your NAT for both signaling and media, it will  
>> just
>> give the UA the information of how it looks from the outside world.  
>> Try
>> it anyway as you will gain more experience, chose what's best for your
>> network setup.
>>
>>
>>> Any comments will be appriciated,
>>>
>>
>> To wrap it up, it could be a problem with the NAT boxes depending  
>> their
>> firewall policies. Try nathelper/rtpproxy combination for a change. If
>> that works there is a problem with mediaproxy if it doesn't there is a
>> problem with your config or your network configuration.
>>
>> Try narrow it to something simple that works and then grow your
>> configuration at the same pace with the experience you are building
>> using SER.
>>
>> Adrian
>>
>>> Tjapko.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: serusers-bounces at lists.iptel.org  
>>> [mailto:serusers-bounces at lists.iptel.org]On
>>> Behalf Of Klaus Darilion
>>> Sent: Martes, 01 de Junio de 2004 07:10 p.m.
>>> To: Adrian Georgescu
>>> Cc: serusers at lists.iptel.org
>>> Subject: Re: [Serusers] SER and NAT
>>>
>>>
>>> oops, sorry. I'ver never used the mediaproxy module.
>>>
>>> klaus
>>>
>>> Adrian Georgescu wrote:
>>>> Function fix_contact() is available within mediaproxy.so with same
>>>> meaning as its nathelper.so counterpart.
>>>>
>>>> Adrian
>>>>
>>>>>
>>>>> You have to rewrite the REGISTER message before saving the
>>>> locations!
>>>>
>>>> if (nat_uac_test("2")) {
>>>> force_rport();
>>>> fix_nated_contact(); # from nathelper module
>>>> append_hf("P-Behind-NAT: Yes\r\n");
>>>> setflag(5); #natflag
>>>> .....
>>>> .....
>>>> save(location); # user with natflag set will be
>>>> # pinged to keep NAT binding alive
>>>>
>>>>
>>>> regards,
>>>> klaus
>>>> Tjapko ITS Consult at ncy wrote:
>>>>> / Hello List,
>>>> />/
>>>> />/ In my fierce battle to overcome the NAT problem I have now  
>>>> running
>>>> SER and
>>>> />/ Mediaproxy without any problem. Whenever any Nated EP like to  
>>>> call
>>>> to PSTN
>>>> />/ or a non nated EP the call goes ok. Whenever I try to call from  
>>>> a
>>>> non nated
>>>> />/ EP to a NATed EP the call does not go through.
>>>> />/
>>>> />/ It seems like that the destination address is not known by
>>>> mediaproxy so it
>>>> />/ can't forward the call to the correct EP.
>>>> />/
>>>> />/ My question is whether this problem might be caused by my  
>>>> ser.cfg
>>>> or
>>>> that
>>>> />/ this is typical SIP behaviour.
>>>> />/
>>>> />/ In other words is it possible to call to any EP that is behind
>>>> Symmetric
>>>> />/ NAT.
>>>>
>>>> /
>>>>
>>>>
>>>> -------------------------------------------------------------------- 
>>>> --
>>>> --
>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> serusers at lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>> ---
>>> Incoming mail is certified Virus Free.
>>> Checked by AVG anti-virus system (http://www.grisoft.com).
>>> Version: 6.0.693 / Virus Database: 454 - Release Date: 31/05/2004
>>>
>>> ---
>>> Outgoing mail is certified Virus Free.
>>> Checked by AVG anti-virus system (http://www.grisoft.com).
>>> Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004
>>>
>>
>




More information about the sr-users mailing list