24 Jun
2012
24 Jun
'12
1:28 p.m.
Hi Reda
A bit late for a reply but I found your post recently and it helped me
to solve a similar problem, so I wanted to share one possible
solution.
On 21 January 2012 23:19, Reda Aouad <reda.aouad(a)gmail.com> wrote:
After endless tests, I tried to replace
record_route_preset with insert_hf,
writing the complete record route headers. A light started to come out of
the tunnel.....
Suppose User A is registered to port 53, User B to port 5060.
In the case of double record route, when A sends an INVITE to B, I write the
following in the SIP header of the INVITE forwarded to B :
Record-Route: <sip:public_ip:5060;r2=on;lr=on>
Record-Route: <sip:public_ip:53;r2=on;lr=on>
The first transaction, INVITE / 200OK goes well, with Kamailio forwarding
packets correctly from the corresponding socket of each user.
The problem arises when User B sends BYE to the 5060 port, with both route
headers in the SIP header of the BYE. I get the following error :
WARNING: rr [loose.c:747]: no socket found for match second RR
after which Kamailio forwards the BYE from the 5060 socket to User A. User A
being registered on port 53, ignores the packet coming with source port
5060. The BYE is never replied to.
I guess that means that Kamailio is not able to find the private_ip:53
socket from the public_ip:53 record-route header.
I hope it was clear.
One way to get around this is to populate the RR with a hostname
instead of an address. Then you can configure it so that the external
clients resolve public_ip but the Kamailio server itself resolves
private_ip. This can be done through an entry in /etc/hosts to
override the public DNS entry.
Not exactly elegant but it works for me.
I think there's a fundamental issue with running
Kamailio behind NAT and
listening on multiple port numbers. Am I the only one suffering from this
type of configuration?
(Part of the problem is also tied to dumb ALG NAT routers which try to
out-smart SIP servers, without which I wouldn't run Kamailio on multiple
ports, and life would be much easier)
Regards,
Richard