[Users] UA behind NAT puts public IP in Contact, Via - help

[Arek Bekiersz]

Hi Bogdan,



I think it should be possible by some flag manipulation, with some help 
from registrar module. I can:

1. Set NAT-ed flag (flag 1) on first REGISTER, that comes with private 
IP in Via

2. If flag (1) is set, store "temporary" registration in "location" 
table, with  flag (let's say flag 10)

3. challenge user

4. when second REGISTER comes (with public IP Via ,so there is no (1) 
flag) check if UA is "already" in "location" table and the flag (10) was 
stored

5. If yes, set flag (1) (UA wanted to cheat us, he is NATed), answer 
'200 OK' and store in "location" table, this time with flag (1)

6. Next actions will assume that user is NAT-ed, by checking (1) flag in 
"location". He will also be pinged from SER. Pretty standard stuff.


However, the problem is there is no "Contact" in first REGISTER. So I 
cannot store temporary entry in "location" database.. But the true 
(private) IP of user is still in Via. So maybe I could append "Contact" 
header field with IP value from Via. It would allow me to store this 
"temporary" registration.

QUESTION: Do we have any access to Via value from ser.cfg, to append 
Contact HF with Via value? And not the topmost, but the last Via, as 
this will probably contain true private IP of UA?

Help!!!

I don't want to write another custom module or database for this stupid 
UA. In fact last year I had to write custom module for SDP manipulation. 
It was impossible to set codec preference in the SAME vendor's devices. 
I had preferred system codec and I had to force it using brute force... 
works until today...



-- 
Regards,
Arek Bekiersz


Bogdan-Andrei Iancu wrote:
> it's not about RFC compliance here, but about making it work, about the 
> logic used to detect and traverse NATS , things that are not specified 
> by RFC.
> I guess it should be reasonable from them to accept to make this auto 
> NAT detection configurable in order to disable it.
> alternative solutions will be (1) to consider all these UAC as nated - 
> by looking at UA hdr- or (2) to try to remember the NAT flag from the 
> non-authenticated REGISTER until the auth-ed one - the first 
> (challenged) register will reveal the true status of the clients (nated 
> or not) as it's also used by client for nat detection....but I guess it 
> will be quite complicated