[Users] Proxy/Registrar and NAT

[Bernie Hoeneisen]

Hi Klaus, Alex et al.

I was thinking about the same problem.

My setup has two redundant SIP Proxy/Registrar (OpenSER 1.1) Servers (P1 
and P2), no additonal edge proxies. It uses either MySQL cluster or 
Master-Master Replication to exchange the state of the location table.

For NAT Processing of REGISTER I use the Nathelper module, which writes 
the original (inside NAT) address to the 'contact' column and the 
information, where the REGISTER request was received from (outside NAT 
socket) goes to 'received' column of the location table.

e.g.:
   contact column: sip:behoe at 192.168.1.56:2051
   received column: sip:130.56.88.20:5432

When an INVITE arrives at P1 (or P2), the 'contact' column will go to the 
R-URI and the 'received' value will be used as the next target of the 
INVITE request.

INVITE requests that do not arrive at the proxy, where the UA 
has registered, have (depending on the NAT type) some likelihood to fail.

Appart from that and as long as there is no path value saved in the 
location table, this work fine. If there is a path value, its content will 
go to the Route header field and the the request is sent to the topmost 
Route entry. Therefore it looses the information that was stored in the 
'received' column....:-(


The preserve this information and to make sure that LL requests are 
routed via the proxy, the UA has registered to, I have some idea, that uses 
path. (Unfortunately not all of my UAs support 'outbound'...:-( ):

When the REGISTER arrives at the Proxy P1, I would insert a Path header 
field with the address of P1 (i.e. the IP address and port of the proxy 
processing the request)

Furthermore I would add a new header field parameter to the contact header 
field (let's call it "extsock" for the time being) containing the external 
NAT socket (i.e. the same information that also goes to 'received' column)

e.g.
   Path: <sip:136.59.10.85:5060;lr>,
   Contact: <sip:behoe at 192.168.1.56:2051;extsock=sip:130.56.88.20:5432;lr>

This will then be stored in the 'path' / 'contact' columns of the 
location table at save().

When the INVITE arrives e.g. at P2, it does the location lookup: The 
Route header field will be populated with the content of the 'path' 
column and the R-URI will be rewritten with the 'contact' column. This 
means the request will be normally forwarded to P1 (topmost Route).

The SIP INVITE looks e.g. as follows:

   INVITE sip:behoe at 192.168.1.56:2051;extsock=sip:130.56.88.20:5432 SIP/2.0
   Route:<sip:136.59.10.85:5060;lr>
   [...]

After the request arrives at P1, it checks, whether there is an extsock 
parameter in the R-URI, and if yes, it uses its values as the next target 
of the request i.e. sip:130.56.88.20:5432
(Maybe P1 could even remove the extsock parameter from the 
R-URI at this stage to make some Nokia E-Series' phones happier...)

My questions:
- Is this idea feasible? Does it work in any case? Any issues with 
forking?
- Could it easily be configured to OpenSER, or is there a change in the 
source code necessairy?
- How much does it break SIP standards? ;-)

Looking forward to your feedback.

Have a nice weekend!

cheers,
  Bernie


> On Wednesday 02 May 2007 08:33, Klaus Darilion wrote:
>> Hi Alex!
>> 
>> Without having done this: You can configure the SIP proxies as load
>> balancers too which distribute the load over all the proxy/registrars
>> (including itself).
>
> I thought of that, but then every REGISTER needs to be forwarded to another
> proxy to get the path info right. This result in a great amount of traffic
> between the proxies and extra processing power. I want the REGISTER request
> to be handled on the first host it arrives on. Then only some INVITE's need
> to create inter-proxy traffic.