[Serusers] Rewriting URI in the Contact field

Jiri Kuthan jiri at iptel.org
Tue Jan 14 09:46:00 CET 2003


Few more notes on this construct:

a it takes two servers in series; the first one in chain makes the
  NAT fixing job, the other one acts as proxy/registrar; the reason is
  the NAT changes to a request are only used to generate outoging request 
  and do not   affect registrar; thus, you first need to send the updated
  request out; one could still have only one server running (be it easier
  or not) with a routing policy, which makes the request pass the same 
  server in two rounds -- first one de-natifying, the second real one

b it takes generating symmetric replies and accepting rport in relayed
  replies -- I think that is a reasonable thing to add to ser core

c the routing policy needs to be set up in such a way, the de-natifying
  instance of SER is always in the path -- otherwise subsequent inbound 
  requests would be routed based-on Contact directly to NAT, would not 
  use symmetric path opened by initial REGISTERs and fail;
  the denatifier thus needs to use record-routing

d for the same reason, all initial inbound requests to natted users proxied 
  by the main server need to be statically routed to the de-natifier

-Jiri

the examples bellow demonstrate in ascii charts some more details;
A:B is address:port of natted phone, X:Y the natted A:B, C:D that of
denatifier

network setting:

fone F: A:B     NAT N: X:Y       proxy D                       proxy P
                  ~
/------\          ~            /-------------\                /--------------\
|phone | -------->~----------->|denattifying |--------------->|registrar/    |
\------/          ~            |ser/outbound |                |inbound proxy |
                  ~            |proxy        |                \--------------/
                               \-------------/\                      ^
                                               \                    /
                                                \---->   outbound  /
                                                             domains

1) registers go from F, are rewritten by D and processed at P
2) INVITEs from F visit D, Contact is rewritten, rport is introduced,
   request is record-routed, so that other party's request visit D too;
3) INVITEs from outside visit first P,  contacts rewritten previously
   by D are put in r-uri, requests are forwarded statically to D,
   and D forwardes by uri to the fone F


At 06:27 PM 1/10/2003, Maxim Sobolev wrote:
>On Fri, Jan 10, 2003 at 03:37:46PM +0200, Maxim Sobolev wrote:
>> Sounds reasonably - I'll do it that way.
>
>I am planning add a new nathelper module, which will export the
>following functions:
>
>add_rport() - insert a rport= parameter into the first Via field
>fix_nated_contact() - replaces host:port in Contact field with host:port
>we received this message from
>add_direction_passive() - adds direction=passive option to the SDP
>
>Then it would be possible to do the following at the very top of config
>before any other REGISTER/INVITE processing:
>
>if (method == "INVITE" || method == "REGISTER") {
>        if (search("User-Agent: Cisco ATA.*") {
>                add_rport();
>                if (method == "INVITE") {
>                        add_direction_passive();
>                };
>                if (method == "REGISTER") {
>                        fix_nated_contact();
>                };
>        };
>};
>
>Does it sound reasonably for you?
>
>-Maxim
>
>> 
>> Thanks!
>> 
>> -Maxim
>> 
>> On Fri, Jan 10, 2003 at 02:15:11PM +0100, Jan Janak wrote:
>> > On 10-01 14:32, Maxim Sobolev wrote:
>> > > Folks,
>> > > 
>> > > I need an advise on how to better implement one feature, which isn't
>> > > currently present in SER. We need to allow UAs behind NAT properly
>> > > register with the registrar - by "properly" I mean that host:port portion
>> > > of URI in Contact field should not be used, but host:port the request
>> > > came from should be used instead. By definition we know that those UAs
>> > > will support symmetric SIP signalling, so that this scheme will work just
>> > > fine.
>> > > 
>> > > In my opinion there are two ways to do it: either add new rewritecontact*
>> > > family of functions similar to rewritehost ones. or add a new flag for
>> > > the save() function. This is where I need your help - which implementation
>> > > looks better for you (or maybe you have even some better idea), since
>> > > we are really interested in inclusion of our changes into the mainline to
>> > > reduce our local hacks.
>> > > 
>> > 
>> >   This should be implemented as a standalone module for ser. I want to keep
>> >   registrar clean, it should not be aware of NATs. So, create a new module
>> >   for ser that will contain all the NAT traversal helper functions, the
>> >   functions will be then called from the config script.
>> > 
>> >   That includes modifications of contact, adding rport to Via and so on.
>> >  
>> >   regards, Jan.
>> > 
>> 
>> 
>> _______________________________________________
>> 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 

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




More information about the sr-users mailing list