[Serdev] Can SER determine NAT type?

[Chris St Denis]

Is mediaproxy on its own enough, or do I need the nathelper module as well
(I know rtpproxy/mediaproxy are alternatives but not sure about the
modules).

Mediaproxy the only nat help function I can find is fix_contact and
force_rport. fix_contact sounds like it just fixes the contact header, but
what about all the other headers? Will fix_contact or force_rport take care
of them, or should I use nathelper as well to rewrite IPs in headers and rtp
description body?

Also, can you direct me to more info about the session timers for dealing
with missing byes?

-----Original Message-----
From: Andrei Pelinescu-Onciul [mailto:andrei at iptel.org] 
Sent: Friday, September 23, 2005 2:15 AM
To: Chris St Denis
Cc: 'Greger V. Teigre'; 'Serdev'
Subject: Re: [Serdev] Can SER determine NAT type?

On Sep 22, 2005 at 11:01, Chris St Denis <chris at aebc.com> wrote:
> I just don't want to waste my bandwidth and processing power on clients
that
> don't need it.

If you use rtpproxy/mediproxy only if nat_uac_test("19") is true (as
Greger said) you want waste any resources in most cases. You will only
act as an rtp relay for the UAs who are behind a symmetric NAT, are
behind NAT and not use STUN or use a broken STUN implementation. 
The only exception is that you will missdetect UAs which use asymmetric
signalling as being behind NATs, even if they are on the public
internet. However almost all modern UAs are symmetric (asymmetric UAs
don't work with NATs).
> 
> Can b2bua be used for this kind of thinks (instead of mediaproxy or
> rtpproxy)? I'm considering using that for my long distance calls anyway to
> ensure there are no problems like lost bye messages causing endless
billable
> calls. Or can media/rtp proxy perform that function?

A b2bua will use more resources. For the lost BYE problem you should use
the gateway logs (recommended) or session timers.

Andrei

> 
> -----Original Message-----
> From: Greger V. Teigre [mailto:greger at teigre.com] 
> Sent: Thursday, September 22, 2005 10:51 AM
> To: Chris St Denis; Serdev
> Subject: Re: [Serdev] Can SER determine NAT type?
> 
> Hi Chris,
> No, SER can never be really sure about the NAT type. Some clients will, as

> you say, add the detected NAT in the header. However, there are cases
where 
> a badly implemented STUN client (or a badly implemented NAT) will give the

> wrong answer.
>     That being said, if you have control over the clients deployed in your

> network, you will know how the stun client(s) behave and what to expect.
if
> 
> you use nat_uac_test("19"), you also include the test where ip is
correctly 
> fixed by the stun client, but where the source port of the sip message is 
> different from the reported contact port (i.e. faulty STUN check). 
> Unfortunately, some NATs are not implemented according to the STUN 
> classification and you get unexpected results.  These NATs must be handled

> case by case basis.
>     So, by using nat_uac_test("19") you should be pretty safe, but you
need 
> to test the UACs you support as well as what results you get for different

> NATs.  There is an RFC with a lot of results for different NATs that may 
> help you, I don't recall the number right now.
> g-)
> 
> ----- Original Message ----- 
> From: "Chris St Denis" <chris at aebc.com>
> To: "Serdev" <serdev at lists.iptel.org>
> Sent: Thursday, September 22, 2005 06:48 PM
> Subject: [Serdev] Can SER determine NAT type?
> 
> 
> >I want to use STUN as a primary nat solution, with the nathelper or
> > mediaproxy module doing rewrites as a secondary/backup solution.
> >
> > However, this will not work for symmetric NATs. I want to proxy the rtp 
> > data
> > from these (and only these) kind of nat. Can SER determine that?
> >
> > My client adds a
> > Warning: 399 spa "Restricted Cone NAT Dectected".
> > Header to the register message (determined by stun), but that looks
> > proprietary and not something I can expect to be the same from other 
> > clients
> > so I'm not sure I want to header match on that.
> >
> >
> > _______________________________________________
> > Serdev mailing list
> > serdev at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serdev
> > 
> 
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev