19 Jan
2015
19 Jan
'15
6:56 p.m.
Hi all!
Seems to be an old topic but still unclean is it possible or not, please
correct me if I'm wrong.
There are some old threads like
http://lists.sip-router.org/pipermail/users/2007-May/011278.html
I use Kamailio 4.2.1 trying to create intercepting registrar proxy, which
handles NAT (rewrites contact), forwards REGISTER to backend and then
stores REGISTER in its internal location on 200 OK from backend, so I call
save() from reply route in noreply mode.
The problem is, it stores IP source of reply as 'received' and modified
contact which i sent out to backend server as 'contact', so it loses
original information from initial REGISTER.
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?
Of course, I can save() all REGISTERs in request_route and then delete on
backend fail, but it seems to be waste of resources, especially when
REGISTER traffic is high :(
I'd be glad to hear any advice.
19 Jan
19 Jan
7:02 p.m.
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.r…
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.p…
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/
7:23 p.m.
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(a)evaristesys.com>om>:
On 01/19/2015 12:56 PM, Dmitry Sytchev wrote:
Is there a way to make save() use original request fields like
--
Best regards,
Dmitry Sytchev,
IT Engineer
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:37 p.m.
BTW, is there any way to alias contacts on Kamailio side and then on INVITE
use rewritten contact as base for real (original untouched) contact lookup,
like using 'received' field as lookup source?
And thanks for your detailed reply, I'll dig into the docs about 'received'
handling.
2015-01-19 22:23 GMT+04:00 Dmitry Sytchev <kbdfck(a)gmail.com>om>:
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(a)evaristesys.com>om>:
--
Best regards,
Dmitry Sytchev,
IT Engineer
On 01/19/2015 12:56 PM, Dmitry Sytchev wrote:
Is there a way to make save() use original request fields like
--
Best regards,
Dmitry Sytchev,
IT Engineer
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3604
days inactive
3604
days old
3 comments
2 participants
participants (2)
-
Alex Balashov -
Dmitry Sytchev