Hi, I'm starting with OpenSer 1.2.1-1 and have a strange problem. This occurs always with users behind NAT with a mapped NAT port different of his device SIP port. For example:
* user 807: device: sip:192.186.0.204:5061 is mapped in the NAT router as: sip:212.121.235.18:1055
So in "location" table I see: --------------------------------- username contact received 807 sip:807@192.168.1.204:5061 sip:212.121.235.18:1055 800 sip:800@212.121.235.18:5080 NULL ---------------------------------
800 is a user with STUN.
I have some services in Asterisk accesible via public and private numbers in OpenSer. Public numbers (500) don't need auth in INVITE.
When 807 call to any private number (or internal users as 800) OpenSer ask him for auth, but OpenSer replies this messaje to a wrong port: --------------------------------- # 807 INVITE 800 U 212.121.235.18:1055 -> 82.94.0.210:5060 INVITE sip:800@openser.domain.org SIP/2.0
# OpenSer 407 U 82.94.0.210:5060 -> 212.121.235.18:5061 <--- WRONG DST PORT SIP/2.0 407 Proxy Authentication Required --------------------------------- As you see, OpenSer send the 407 message to the NAT IP but to the device SIP port instead of the NAT port. So 807 sends again and again the INVITE.
But if 807 calls to a public number (500) it get the call but when 807 does BYE, the response to that BYE is again wrong: --------------------------------- # 807 INVITE 500 U 212.121.235.18:1055 -> 82.94.0.210:5060 INVITE sip:500@openser.domain.org SIP/2.0
# OpenSer OK U 82.94.0.210:5060 -> 212.121.235.18:1055 SIP/2.0 200 OK
# 807 BYE 500 U 212.121.235.18:1055 -> 82.94.0.210:5060 BYE sip:1800@82.94.0.210:5070 SIP/2.0
# OpenSer OK U 82.94.0.210:5060 -> 212.121.235.18:5061 <--- WRONG DST PORT SIP/2.0 200 OK ---------------------------------
I hope this is a bug in my OpenSer configuration. Please, could anyone tell me with funcions related to this issue should I verify?
Thanks a lot.
Hi,
use force_rport() for the requests coming from behind nat.
regards, bogdan
Iñaki Baz Castillo wrote:
Hi, I'm starting with OpenSer 1.2.1-1 and have a strange problem. This occurs always with users behind NAT with a mapped NAT port different of his device SIP port. For example:
- user 807: device: sip:192.186.0.204:5061 is mapped in the NAT router as: sip:212.121.235.18:1055
So in "location" table I see:
username contact received 807 sip:807@192.168.1.204:5061 sip:212.121.235.18:1055 800 sip:800@212.121.235.18:5080 NULL
800 is a user with STUN.
I have some services in Asterisk accesible via public and private numbers in OpenSer. Public numbers (500) don't need auth in INVITE.
When 807 call to any private number (or internal users as 800) OpenSer ask him for auth, but OpenSer replies this messaje to a wrong port:
# 807 INVITE 800 U 212.121.235.18:1055 -> 82.94.0.210:5060 INVITE sip:800@openser.domain.org SIP/2.0
# OpenSer 407 U 82.94.0.210:5060 -> 212.121.235.18:5061 <--- WRONG DST PORT SIP/2.0 407 Proxy Authentication Required
As you see, OpenSer send the 407 message to the NAT IP but to the device SIP port instead of the NAT port. So 807 sends again and again the INVITE.
But if 807 calls to a public number (500) it get the call but when 807 does BYE, the response to that BYE is again wrong:
# 807 INVITE 500 U 212.121.235.18:1055 -> 82.94.0.210:5060 INVITE sip:500@openser.domain.org SIP/2.0
# OpenSer OK U 82.94.0.210:5060 -> 212.121.235.18:1055 SIP/2.0 200 OK
# 807 BYE 500 U 212.121.235.18:1055 -> 82.94.0.210:5060 BYE sip:1800@82.94.0.210:5070 SIP/2.0
# OpenSer OK U 82.94.0.210:5060 -> 212.121.235.18:5061 <--- WRONG DST PORT SIP/2.0 200 OK
I hope this is a bug in my OpenSer configuration. Please, could anyone tell me with funcions related to this issue should I verify?
Thanks a lot.
El Friday 06 July 2007 16:51:18 Bogdan-Andrei Iancu escribió:
Hi,
use force_rport() for the requests coming from behind nat.
Thanks a lot, you are right. In my modifications I deleted some force_rport().
Let me one question more:
Is it correct to put a simple force_rport() in the start of main route and other force_rport() in onreply_route[1] (replies to general t_relay)? Or should I do that but inside a NAT(19) check?
Thanks a lot.