[Users] Proxy/Registrar and NAT

[Klaus Darilion]

Bernie Hoeneisen wrote:
> 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....:-(

Hi Bernie!

Do you use the "received" features of path module? I think this should 
solve your problems.

http://www.openser.org/docs/modules/1.2.x/path#AEN82 and
http://www.openser.org/docs/modules/1.2.x/path#AEN123

regards
klaus

> 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.
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users