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

[Klaus Darilion]

Nils Ohlmeier wrote:
> On Wednesday 20 December 2006 11:55, Klaus Darilion wrote:
>> Nils Ohlmeier wrote:
>>> Hi Klaus,
>>>
>>>> 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?
>> As I think about it - if you test the response from the callee it is too
>> late, because you have to force rtpproxy also for the request.
> 
> I'm talking here about an re-INVITE for an already running dialog (RTP proxy 
> decision is history already at the point), not about the initial transaction. 
> The re-INVITE can be triggered by any side (e.g by session-timer).

I do not make NAT-tests for reINVITE. The firsts INVITE gets a 
record-route parameter (nat=caller, nat=callee or nat=both) which will 
be checked during re-INVITEs.

Of course you also have to check the direction of the reINVITE in case 
of nat=caller or callee for proper NAT handling.

regards
klaus


-- 
Klaus Darilion
nic.at