[SR-Users] question about NAT being behind of a Load Balancer
Klaus Darilion
klaus.mailinglists at pernau.at
Fri Feb 3 15:48:57 CET 2012
Hi Albert!
On 03.02.2012 11:24, Albert Petit wrote:
> Hi Klaus,
>
> Thanks for your answer!
>
> 2012/2/3 Klaus Darilion <klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>>
>
> The Load-Balancer is the only server which sees the real IP Address
> of the client. Thus, some parts of NAT-Traversal can only be done by
> the LB.
>
> Expecting kind of this answer because also makes sense to me that LB is
> the only one who can see from where is it really coming :-) however
> then if I fix rport in LB could I still do do operations like /
> fix_nated_register(); fix_nated_contact();/
> from S1,S2..SN ? Or that needs to be handled on LB too?
There are several ways to implement it. What you have to achieve is:
- forward REGISTER from LB to Sn
- store the clients public IP somewhere, so that it can be used later to
contact the client
- store the registration on Sn
- on incoming calls forward the INVITE from Sn to LB and
- LB needs to know the public IP to forward the INVITE to the client
For incoming calls, there are 3 possibilities to route the INVITE from
Sn to LB:
a) manually set the destination URI to the IP address of the LB
($du="sip:1.2.3.4")
b) use that "Path" extension. The LB will add a Path header to the
REGISTER. The Path will be stored in Sn during registration and used by
Sn when routing incoming calls.
c) on Sn, use fix_nated_register() before save(). This will store the
LB's IP address of contact and used as destination URI when routing the
call to the client.
You mentioned that you will use Kamailio as LB and Sn. Therefore I
suggest the most standard conform approach: b)
So, by using Path, you can solve the routing from Sn to the LB. To route
the call from the LB to the client, the client's public IP need to be
stored during registration and needs to be available in the INVITE. A
nice way to achieve this is the add_contact_alias() function.
(http://kamailio.org/docs/modules/3.2.x/modules_k/nathelper.html#id2550431).
Before dispatching the REGISTER to Sn, call add_contact_alias() and it
will add the clients public IP to the Contact URI as a URI parameter.
Thus, the parameter will be available in the request URI of the INVITE,
und by using handle_ruri_alias() you can extract the public IP from the
URI parameter and use it as destination URI.
Further, you have to call add_contact_alias() for all requests (with
Contact header) sent from the client to the LB, and call
handle_ruri_alias() on all requests which will be sent from the LB to
the client.
> E.g. the LB must use force_rport() and mangle the contact header of
> the client. Further, if you use light-weight NAT-keep-alive (CR-LF)
> you have to do it from the LB. If you use OPTIONS requests for
> NAT-keep-alive you should be possible to do it from the backend servers.
>
> We're using SIP Options..and I would prefer to keep like that. if
> possible. I will try to do it from S1,S2,...SN first.
This should work with the Path.
> If you use media relays (rtpproxy), either control them from the
> load balancer or from the backend-servers. If you control them from
> the backend-servers you have to instruct rtpproxy to accept RTP from
> all sources (by default it accepts RTP only from the previous SIP
> hop, which in this case would be the LB and not the public IP
> address of the SIP client).
>
>
> I believe it would be better to keep RTP Proxy on S1,S2..SN SIP Servers;
> this way I can have N instances of RTP Proxy instead of a maximum of one
> (or two if using active-passive LB)
You could control multiple rtpproxies from the LB. But controlling the
trpproxies from Sn will give you better scalability.
> Isit easy to instruct RTP Proxy to accept media from all sources? I
> never did. Where can I find this information? I tried here
> http://www.rtpproxy.org/wiki/RTPproxy/FAQ and here
> http://kamailio.org/docs/modules/3.0.x/modules_k/nathelper.html but no
> luck.
I think it is the 'r' flag. Maybe the SDP needs to be changed in the LB
to change the private IP address to the public IP address.
See: http://kamailio.org/docs/modules/3.2.x/modules/rtpproxy.html#id2535618
regards
Klaus
>
>
> regards
> klaus
>
> PS: You are using the terms UAC and UAS incorrectly. Every SIP node
> is a UAC and UAS - this term only defines if a node receive requests
> or sends requests. I think in your case it is better to just call
> them "SIP clients" and "SIP servers".
>
> Yes you're right, not correct use of the term, sorry for that.
>
>
>
> On 03.02.2012 10:26, Albert Petit wrote:
>
> Hi , Sorry for previous email. Hit send too soon .
>
> Good morning,
> On my system i've a structure similar to:
> SIP Clients SIP Platform
> [-------------------] [-----------------------------__----]
> S1 @IP2
> S2 @IP3
> SIP UACs SIP LB ...
> [NATted and @IP1
> non Nattted]
> SN @IPN
>
>
> SIP LB is based on Kamailio dispatcher and is responsible of
> distributing the load between different Servers SIP UAS.
>
> S1, S2,... SN Servers have a Kamailio Server too which will forward
> received balanced traffic to appropiate service (Presence ,
> registrar,...)
>
>
> Considering SIP LB and all SIP UAS have Public IP, how NAT from
> the UACs
> could be handled on this scenario?
>
> Initially I thought NAT should be handled on SIP LB however I
> would like
> the most simple possible load balancer with no need to read user
> locations . Responsible of location users should be S1,S2,..:SN
>
> Then, would it be possible to handle NAT of the SIP UACs *from
> the SIP
> UAS *with NAT Helper module? What i'm afraid is: If all
> traffic to
>
> S1,S2,..SN comes from SIP LB then nat_helper could think all
> clients are
> NATTed because top most via will be SIP LB.
>
>
> What I need, I think, is that NAT Helper decides if there is NAT
> looking
> the Via Header added originally by UAC , and not the top most
> via (which
> would be SIP LB). Is that possible? If possible how should i
> configure
> Nat helper for that?
>
>
> BR
> Albert
>
>
>
> _________________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> mailing list
> sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
> http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>
>
>
>
> --
> Albert
More information about the sr-users
mailing list