Hello, I have my proxy behind a NAT (static NAT) with SIP clients that are both on my LAN and on public IP.
UAC1 Private IP <--> <--> UAC3 PublicIP Proxy <--> NAT <--> WAN UAC2 Private IP <--> <--> UAC4 PublicIP
I'm looking for the correct configuration of record route for this scenario. I looked for examples with proxy behind the NAT and I have always found a config section for the record route like this
# ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (method=="INVITE" && client_nat_test("3")) { # INSERT YOUR IP ADDRESS HERE record_route_preset("<MY OPENSER PBULIC IP>:5060;nat=yes"); } else if (method!="REGISTER") { record_route(); };
In this way the proxy uses "record_route_preset" when the caller is private (client_nat_test("3")) and "record_route" when the caller is public, without consider the callee. Consequently the proxy puts in the record route the public IP when the caller is private and the private IP address when the caller is public. I can't understand how it can work: when a client on an public ip calls a client on an public ip, they find in record route the private ip and they will try to send the SIP method (ACK,BYE, reINVITE ecc) to a private IP, so this messages will be lost. This is the beahaviour that I'm observing in my test. Maybe this configuration isn't adapted for my scenario or I miss something else (I have already added advertised_address/port) or I haven't correctly understand the instructions or the Record Route's usage. ********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message inerror.
**********************************************************************
2008/10/22 Zappasodi Daniele Daniele.Zappasodi@seltatel.it:
In this way the proxy uses "record_route_preset" when the caller is private (client_nat_test("3")) and "record_route" when the caller is public, without consider the callee. Consequently the proxy puts in the record route the public IP when the caller is private and the private IP address when the caller is public. I can't understand how it can work: when a client on an public ip calls a client on an public ip, they find in record route the private ip and they will try to send the SIP method (ACK,BYE, reINVITE ecc) to a private IP, so this messages will be lost. This is the beahaviour that I'm observing in my test. Maybe this configuration isn't adapted for my scenario or I miss something else (I have already added advertised_address/port) or I haven't correctly understand the instructions or the Record Route's usage.
The above configuration is not valid for calls between clients with public IP (both) or clients with private IP (both).
Anyawy, the above configuration is wrong, not just when calls between public clients. Imagine the following:
UA1 <--> Kamailio <---> Router NAT <----> UA2
- INVITE UA1 --> Kamailio Record-Route = PUBLIC_IP
The INVITE arrives to UA2 who sets the route set for the dialog and send it back to UA1 with Record-Route in reverse order in the 200 OK.
So UA2 has this route set: PUBLIC_IP, CONTACT_UA1
And UA1 has this route set: PUBLIC_IP, CONTACT_UA2
When UA1 sends an in-dialog request (BYE, INFO, re-INVITE, ACK for 200-INVITE...) the message will be lost.
The solution could be adding two Record-Routes, one with private IP and the other with public IP, but I'm not sure of how to achieve it with Kamailio. AFAIK Kamailio *already* does it when the transaction comes via eth0 and leaves the proxy via eth1, but this is not your case.
I recommend you reading this draft, and later trying to get it in Kamailio: http://tools.ietf.org/html/draft-ietf-sip-record-route-fix (5. Double Record-Routing)
Regards.
-
Iñaki Baz Castillo -
Zappasodi Daniele