[Serusers] add_rcv_param() for INVITEs

Andrei Pelinescu-Onciul andrei at iptel.org
Thu Jun 9 12:57:29 CEST 2005


On Jun 09, 2005 at 12:19, Martin Koenig <martin.koenig at toplink-plannet.de> wrote:
> 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.

Yes, but it's more theoretical. In practice UAs accept "spoofed" ip in
uris without complaining :-)

Andrei




More information about the sr-users mailing list