[Freeswitch-users] Distributing SIP registrations using ODBC

[Tim St. Pierre]

Yes, that solution will fix it just fine.

There is another way, just in case it makes more sense for you:

If you have a NAT device that has a proper SIP ALG in it, (such as any of the Netopia 3300-ENT
routers), they will accept traffic from either server.

The other way that I'm about to try (I'm in the same boat, with all my clients behind NAT), is to
use a simple SIP proxy / load balancer in front of Freeswitch.  FS will send SIP back through the
load balancer to the client, so the traffic will originate from the load balancer IP, no matter
which FS box originates.  As long as each client registers through the same proxy each time (the
correct SRV record will ensure this), the NAT rules won't be a problem.

Media isn't as big an issue with Freeswitch, as it will detect the incoming RTP and use that as the
return path if the sdp is wrong.

-Tim	


Dan Lane wrote:
> Yup, that was how I plan to fix it using LUA to figure out where to
> route the call (possibly proxying it via the other FS server).
> 
> Just wanted to check I wasn't re-inventing the wheel before I go ahead
> and do it as it seems like the sort of issue other people would have
> dealt with.
> 
> On Mon, Aug 2, 2010 at 5:10 PM, Steven Ayre <steveayre at gmail.com> wrote:
>> I haven't tried this myself, but routing the call via the FS server they
>> registered too might work since it'll be the IP the NAT router is expecting
>> traffic from.
>>
>> -Steve
>>
>>
>> On 2 August 2010 16:10, Dan Lane <null at invalid.name> wrote:
>>> Hi Guys,
>>>
>>> I have a cluster of FS boxes all sharing SIP registrations using ODBC
>>> and under certain circumstances I can register Client-A on FS-A and
>>> Client-B on FS-B and make calls between Client-A and Client-B without
>>> issue as the relevant FS box knows how to get a call to the client
>>> from the shared registrations table.
>>>
>>> However when the callee client is behind NAT (or using a SIP client
>>> configured to only allow calls from a server it has registered with)
>>> the call gets dropped by the NAT router (or client)
>>>
>>> I can fix this easily with some LUA but before I do I wanted to check
>>> if there was an advisable or recognised FreeSWITCH way to work around
>>> this.
>>> ro
>>> Has anyone else solved this issue already?
>>>
>>> Regards,
>>> Dan
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
> 
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org