30 May
2005
30 May
'05
12:08 p.m.
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(a)4.5.6.7
Route: 1.2.3.4;lr=on
Device (10.0.0.1, NAT 4.5.6.7):
INVITE device(a)123.123.123.123
With add_rcv_param():
Ser:
INVITE device(a)10.0.0.1;rcv_param=4.5.6.7
Route: 1.2.3.4;lr=on
Device:
INVITE device(a)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?
What do you think? Any experience on this?
Regards,
Martin
7 Jun
7 Jun
1:06 p.m.
I thin k I solved the problem using fix_nated_register instead of
fix_nated_contact for REGISTER messages. (using nathelper)
regards,
klaus
Martin Koenig 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(a)4.5.6.7
Route: 1.2.3.4;lr=on
Device (10.0.0.1, NAT 4.5.6.7):
INVITE device(a)123.123.123.123
With add_rcv_param():
Ser:
INVITE device(a)10.0.0.1;rcv_param=4.5.6.7
Route: 1.2.3.4;lr=on
Device:
INVITE device(a)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?
What do you think? Any experience on this?
Regards,
Martin
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8 Jun
8 Jun
3:55 p.m.
On May 30, 2005 at 11:08, Martin Koenig <martin.koenig(a)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(a)4.5.6.7
Route: 1.2.3.4;lr=on
Device (10.0.0.1, NAT 4.5.6.7):
INVITE device(a)123.123.123.123
With add_rcv_param():
Ser:
INVITE device(a)10.0.0.1;rcv_param=4.5.6.7
Route: 1.2.3.4;lr=on
Device:
INVITE device(a)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?
Andrei
9 Jun
9 Jun
1:19 p.m.
Hello,
Andrei Pelinescu-Onciul wrote:
On May 30, 2005 at 11:08, Martin Koenig
<martin.koenig(a)toplink-plannet.de> wrote:
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
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(a)4.5.6.7
Route: 1.2.3.4;lr=on
Device (10.0.0.1, NAT 4.5.6.7):
INVITE device(a)123.123.123.123
With add_rcv_param():
Ser:
INVITE device(a)10.0.0.1;rcv_param=4.5.6.7
Route: 1.2.3.4;lr=on
Device:
INVITE device(a)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?
1:57 p.m.
On Jun 09, 2005 at 12:19, Martin Koenig <martin.koenig(a)toplink-plannet.de> wrote:
Hello,
Andrei Pelinescu-Onciul wrote:
Yes, but it's more theoretical. In practice UAs accept "spoofed" ip in
uris without complaining :-)
Andrei
On May 30, 2005 at 11:08, Martin Koenig
<martin.koenig(a)toplink-plannet.de>
wrote:
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. 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(a)4.5.6.7
Route: 1.2.3.4;lr=on
Device (10.0.0.1, NAT 4.5.6.7):
INVITE device(a)123.123.123.123
With add_rcv_param():
Ser:
INVITE device(a)10.0.0.1;rcv_param=4.5.6.7
Route: 1.2.3.4;lr=on
Device:
INVITE device(a)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?
7108
days inactive
7118
days old
4 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Klaus Darilion -
Martin Koenig