[Serusers] add_rcv_param() for INVITEs
Martin Koenig
martin.koenig at toplink-plannet.de
Thu Jun 9 12:19:07 CEST 2005
Hello,
Andrei Pelinescu-Onciul wrote:
>On May 30, 2005 at 11:08, Martin Koenig <martin.koenig at 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 at 4.5.6.7
>>Route: 1.2.3.4;lr=on
>>
>>Device (10.0.0.1, NAT 4.5.6.7):
>>INVITE device at 123.123.123.123
>>
>>With add_rcv_param():
>>
>>Ser:
>>INVITE device at 10.0.0.1;rcv_param=4.5.6.7
>>Route: 1.2.3.4;lr=on
>>
>>Device:
>>INVITE device at 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
More information about the sr-users
mailing list