[Serdev] [Tracker] Created: (SER-200) Patch for a new nathelper nat_uac_test (Contact != rport)

[Nils Ohlmeier]

Hi Klaus,

On Tuesday 19 December 2006 14:19, Klaus Darilion wrote:
> Nils Ohlmeier (JIRA) wrote:
> > Patch for a new nathelper nat_uac_test (Contact != rport)
> > ---------------------------------------------------------
> >
> > Key: SER-200 URL: http://tracker.iptel.org/browse/SER-200 Project:
> > SER Issue Type: Improvement Components: NAT Traversal Affects
> > Versions: Ipteldorf Environment: Latest CVS code (Ottendorf version)
> > from the 18.12.2006. Reporter: Nils Ohlmeier Priority: Minor
> > Attachments: nathelper_contact_rport_test.patch
> >
> > The attached patch adds one more test to the nat_uac_test (0x20)
> > which compares the port in the Contact header with the port value
> > from the transport layer (UDP/TCP). This test can be helpful in
> > scenarios with clients behind symmetric NATs and STUN support, where
> > the wrong Contact header port may be the only indication for a NAT
> > traversal, but not fixing these values breaks the further in-dialog
> > communication. But be warned that this test should not be used by
> > default, as it might break things for example in cases where UA's are
> > on a public IP and advertising a different port in their Contact
> > header with intention.
>
> Hi Nils!
>
> I thought this clients can also be spotted by comparing the port in the
> topmost Via header and the port from which the message was received.
>
> Which clients needs this new test?

I dont know which client(s) exactly. But the scenario is pretty simple:
the UA answers (with the "broken" STUN support and behind a sym NAT) with 200 
OK on an re-INVITE -> the topmost Via is not from the UA... you could ask 
your registrar if it sits behind a NAT, but if the first hop is not your 
registrar... You see?

Cheers
  Nils