Hi Albert!
On 03.02.2012 11:24, Albert Petit wrote:
Hi Klaus,
Thanks for your answer!
2012/2/3 Klaus Darilion <klaus.mailinglists(a)pernau.at
<mailto:klaus.mailinglists@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(a)lists.sip-router.org <mailto:sr-users@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