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