[SR-Users] REGISTER request and save() from onreply_route

Dmitry Sytchev kbdfck at gmail.com
Mon Jan 19 19:23:51 CET 2015


Yes, you're right about contact matching and ATAs, this is a part of our
case too.
I actually use Path module to forward REGISTERs to backend servers. But
there is a problem that not all backends support Path, like Asterisk 11.

If I get the point right, I should forward them as is and when I receive
request from backend set $ru to contact and $du to Contact's received
parameter?



2015-01-19 22:02 GMT+04:00 Alex Balashov <abalashov at evaristesys.com>:

> On 01/19/2015 12:56 PM, Dmitry Sytchev wrote:
>
>  Is there a way to make save() use original request fields like
>> T_req($ct), or some way to call save() with full set of custom params?
>>
>
> Yes; in fact, there are many standards-based reasons why it's desirable to
> store the original Contact binding provided by the registrant. Many devices
> (e.g. ATAs, various gateways, for instance) will not accept an INVITE with
> an incoming Request URI that does not correspond to the exact Contact URI
> that it sent in the REGISTER request.
>
> This is why Kamailio's usrloc record provides a 'received' field in
> addition to a 'contact' field. Take a look at this:
>
> http://kamailio.org/docs/modules/4.2.x/modules/registrar.html#registrar.p.
> received_param
>
> In essence, what you want is for the external IP:port to be stored in the
> 'received' value while the original Contact is stored in the 'contact'
> value. The 'received' value will be used as the destination set ($du) for
> inbound routing, while the Request URI will remain consistent with the
> Contact URI.
>
> The issue of having two proxies is a separate and more complex one.
> Ultimately, to make it work, you're going to need to use Path, which is
> like Record-Route, but for REGISTERs:
>
> http://kamailio.org/docs/modules/4.2.x/modules/registrar.html#registrar.p.
> path_mode
>
> But, the first step to solving your problem is to realise that you should
> not actually be rewriting the Contact header as your NAT traversal
> strategy. You should add the received IP:port as parameters in one way or
> another to be passed onto the receiving registrar, as for example using
> Contact URI header parameters per the received_param doc I linked to above.
>
> -- Alex
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> United States
>
> Tel: +1-678-954-0670
> Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>



-- 
Best regards,

Dmitry Sytchev,
IT Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150119/026dec7a/attachment.html>


More information about the sr-users mailing list