[Serusers] Rewriting URI in the Contact field

Jiri Kuthan jiri at iptel.org
Mon Jan 13 22:06:32 CET 2003


Isn't the ATA able of "double registration" (see draft-ietf-sipping-nat-scenarios-00.txt) ? 
I thought it was able to register, look at received and rport and re-register 
then again with the host/port it learned from reply to the first registration. 

Or does it do so only for IP address (received) and not for port numbers (rport)?

-Jiri

At 03:15 PM 1/10/2003, Maxim Sobolev wrote:
>Yes, I know - we have studied all those methods in details. Our
>method of choice is symmetric signalling/symmetric media (aka COMEDIA)
>due to the following reasons:
>
>1. Things should work without modifying or reconfiguring existing
>user's infrastructure (NATs) and should be compatible with all
>widely-used NATs.
>
>2. We are bound to ata186 as UA. It is compatible with this method.
>Support for other UAs isn't required.
>
>3. The calls will be terminated to Cisco GWs, while COMEDIA support
>was recently added into Cisco IOS, so that theoretically the only
>thing we need is to add received/rport support into proxy/registrar
>and update IOS at termination points.
>
>4. No media relay is allowed, because this will create excessive
>bandwith load in a single point.
>
>5. COMEDIA support is likely to become part of the standard, so that
>our investments into development are protected.
>
>-Maxim
>
>On Fri, Jan 10, 2003 at 02:26:07PM +0100, Jiri Kuthan wrote:
>> There is actually a plenty of options how to traverse NATs.
>> Sadly, none of them works in all possible scenarios.
>> 
>> a) STUN -- some phones (kphone for linux, snom hardphones)
>>    have the ability to "fool" NATs to accomplish traversal
>>    using the STUN protocols; particularly good if you cannot
>>    manipulate the NAT
>> b) geek tweaks -- you have a configurable NAT and configurable
>>    phones (there are some of both of them).  you configure static 
>>    port forwarding in the NAT and phones to advertise the
>>    public address in contacts and elsewhere
>> c) ALG -- use a SIP-aware NAT such as PIX or Intertex
>> d) UPnP -- takes UPnP enables phones (snom is) and NATs
>> e) SIP/media relay -- that's a too ugly story
>> 
>> What to choose best depends on your network setting -- can you
>> tweak the NAT, can you afford replacing it with a SIP-enabled
>> one, are the phones you are using configurable or do they use
>> STUN, do you have a server on the public or private NAT side
>> or on each of them, etc.
>> 
>> I remember someone shared with us he was using ser in his
>> network to do the translation of SIP addresses on behalf
>> ot the phones. The ser script was configured to statically
>> rewrite private IP addresses to the public address using
>> replace/textops.
>> 
>> -Jiri
>> 
>> At 01:32 PM 1/10/2003, 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.
>> >
>> >Regards,
>> >
>> >Maxim
>> >
>> >_______________________________________________
>> >Serusers mailing list
>> >serusers at lists.iptel.org
>> >http://lists.iptel.org/mailman/listinfo/serusers 
>> 
>> --
>> Jiri Kuthan            http://iptel.org/~jiri/ 

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




More information about the sr-users mailing list