Hello,
Andrei Pelinescu-Onciul wrote:
On May 30, 2005 at 11:08, Martin Koenig martin.koenig@toplink-plannet.de wrote:
Hello,
is it possible to use add_rcv_param() also for Contact-HF of INVITEs, instead of fix_nated_contact()?
This would make sure that the NATed End Device gets fed exactly the contact as R-URI that it announced in the INVITE:
Example R-URI in Loose-Route Requests for fix_nated_contact():
Ser (1.2.3.4): INVITE device@4.5.6.7 Route: 1.2.3.4;lr=on
Device (10.0.0.1, NAT 4.5.6.7): INVITE device@123.123.123.123
With add_rcv_param():
Ser: INVITE device@10.0.0.1;rcv_param=4.5.6.7 Route: 1.2.3.4;lr=on
Device: INVITE device@10.0.0.1
The problem is that the End-Device, in the fix_nated_contact() callflow, has to accept a Request that is not really for this device (IP in Request-URI != IP of the Device). Imagine a Ser checkip uri == myself. This would fail without knowing the public IP of the NAT and hard-conding it into Ser.cfg.
Does Ser support the rcv_param in Request-URI also?
No, but it would be very easy to add a function that would set the dst_uri to the received_param value and would remove receveid_param from the uri. The question is where it will be the best place for it: the uri module, nathelper?
Do you really need it?
It would make sure that the end device always receives a properly formatted request-uri. In the current setup, end device has to accept a "spoofed" request-uri that does not point to the end device itself but to the nat router.
I think this is an important issue, and has also been identified as such, otherwise fix_nated_register() would not exist.
Also, I think nathelper is the right place to put it.
Regards, Martin