[SR-Users] Registrar module and local paths

[Ben Langfeld]

Hello everyone. I'm having a problem with registrations and Path and hope
that someone can help.

I have a Kamailio instance which is both a WebSocket proxy and a registrar
which has the following behaviour:

* A REGISTER with a Path header already on it gets recorded in the location
table.

* I use add_path() on all incoming REGISTERs, and a REGISTER relayed to
another registrar reaches that registrar with a Path header added
appropriately.

Unfortunately, save("location") ignores the path added by add_path(). I'd
prefer to keep the proxy and registrar co-located for the short term. Does
anyone know if/how I might be able to have the Path header properly stored
in the case that it was added by add_path()?

Regards,
Ben Langfeld

[Daniel-Constantin Mierla]

Hello,

Post by Ben Langfeld
Hello everyone. I'm having a problem with registrations and Path and
hope that someone can help.
I have a Kamailio instance which is both a WebSocket proxy and a
* A REGISTER with a Path header already on it gets recorded in the
location table.
* I use add_path() on all incoming REGISTERs, and a REGISTER relayed
to another registrar reaches that registrar with a Path header added
appropriately.
Unfortunately, save("location") ignores the path added by add_path().
I'd prefer to keep the proxy and registrar co-located for the short
term. Does anyone know if/how I might be able to have the Path header
properly stored in the case that it was added by add_path()?

if you have the registrar as first hop from client, then you don't need
to save path. save(location) and lookup(location) shout take care of
everything. Just be sure you set the nat flag and use
fix_nated_register() also for traffic coming via websocket.

Cheers,
Daniel

[Daniel-Constantin Mierla]

Post by Daniel-Constantin Mierla
Hello,

Hello everyone. I'm having a problem with registrations and Path and hope that someone can help.
* A REGISTER with a Path header already on it gets recorded in the location table.
* I use add_path() on all incoming REGISTERs, and a REGISTER relayed to another registrar reaches that registrar with a Path header added appropriately.
Unfortunately, save("location") ignores the path added by add_path(). I'd prefer to keep the proxy and registrar co-located for the short term. Does anyone know if/how I might be able to have the Path header properly stored in the case that it was added by add_path()?

if you have the registrar as first hop from client, then you don't need to save path. save(location) and lookup(location) shout take care of everything. Just be sure you set the nat flag and use fix_nated_register() also for traffic coming via websocket.

Unfortunately it's not that simple. I have two or more instances of this combined proxy/registrar and usrloc in dbmode 3 so they can share location data without SIP level replication. A web socket UA on one proxy would need to use the path to reach a we socket UA on the other proxy, else it looks locally for the socket and fails.

But then, the instance handling the REGISTER will have to do a loop or
other tricks in config to avoid it.

See msg_apply_changes() from textopsx to get the path header visible.

Cheers,
Daniel

[Ben Langfeld]

Post by Daniel-Constantin Mierla
Hello,

Hello everyone. I'm having a problem with registrations and Path and hope that someone can help.
* A REGISTER with a Path header already on it gets recorded in the location table.
* I use add_path() on all incoming REGISTERs, and a REGISTER relayed to another registrar reaches that registrar with a Path header added appropriately.
Unfortunately, save("location") ignores the path added by add_path(). I'd prefer to keep the proxy and registrar co-located for the short term. Does anyone know if/how I might be able to have the Path header properly stored in the case that it was added by add_path()?

if you have the registrar as first hop from client, then you don't need to save path. save(location) and lookup(location) shout take care of everything. Just be sure you set the nat flag and use fix_nated_register() also for traffic coming via websocket.

Unfortunately it's not that simple. I have two or more instances of this combined proxy/registrar and usrloc in dbmode 3 so they can share location data without SIP level replication. A web socket UA on one proxy would need to use the path to reach a we socket UA on the other proxy, else it looks locally for the socket and fails.

Post by Daniel-Constantin Mierla
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Ben Langfeld]

Post by Ben Langfeld

Post by Daniel-Constantin Mierla
Hello,

Post by Ben Langfeld
Hello everyone. I'm having a problem with registrations and Path and

hope that someone can help.

Post by Daniel-Constantin Mierla

Post by Ben Langfeld
I have a Kamailio instance which is both a WebSocket proxy and a
* A REGISTER with a Path header already on it gets recorded in the

location table.

Post by Daniel-Constantin Mierla

Post by Ben Langfeld
* I use add_path() on all incoming REGISTERs, and a REGISTER relayed

to another registrar reaches that registrar with a Path header added
appropriately.

Post by Daniel-Constantin Mierla

Post by Ben Langfeld
Unfortunately, save("location") ignores the path added by add_path().

I'd prefer to keep the proxy and registrar co-located for the short term.
Does anyone know if/how I might be able to have the Path header properly
stored in the case that it was added by add_path()?

Post by Daniel-Constantin Mierla
if you have the registrar as first hop from client, then you don't need

to save path. save(location) and lookup(location) shout take care of
everything. Just be sure you set the nat flag and use fix_nated_register()
also for traffic coming via websocket.

Unfortunately it's not that simple. I have two or more instances of this

combined proxy/registrar and usrloc in dbmode 3 so they can share location
data without SIP level replication. A web socket UA on one proxy would need
to use the path to reach a we socket UA on the other proxy, else it looks
locally for the socket and fails.
But then, the instance handling the REGISTER will have to do a loop or
other tricks in config to avoid it.
See msg_apply_changes() from textopsx to get the path header visible.

Thanks for the reference Daniel. I gave this a try and it results in the
following:

Oct 15 14:03:06 nyubachibo /usr/sbin/kamailio[21350]: DEBUG: <core>
[parser/parse_uri.c:1284]: parse_uri(): parse_uri: bad host in uri (error
at char ; in state 4) parsed: <sip:yfEcKaf/W6yLtwWsHxZzE8uxzeId728=@>(37)
/<sip:yfEcKaf/W6yLtwWsHxZzE8uxzeId728=@;lr;ob> (43)
Oct 15 14:03:06 nyubachibo /usr/sbin/kamailio[21350]: ERROR: registrar
[path.c:84]: build_path_vector(): failed to parse the first Path URI

I figure at this point it may be simpler to separate the registrar and the
proxy rather than attempt to debug this further, though if you have any
other suggestions to avoid that I'd love to hear them.

Thanks for your help so far, it's much appreciated :)

Cheers,

Post by Ben Langfeld
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

[Juha Heinanen]

Post by Ben Langfeld
I figure at this point it may be simpler to separate the registrar and the
proxy rather than attempt to debug this further, though if you have any
other suggestions to avoid that I'd love to hear them.

one possibility is that both of your combined proxy/registrars have
their own location tables and you forward registrations from one to the
other.

-- juha

[Ben Langfeld]

Post by Juha Heinanen

Post by Ben Langfeld
I figure at this point it may be simpler to separate the registrar and

the

Post by Ben Langfeld
proxy rather than attempt to debug this further, though if you have any
other suggestions to avoid that I'd love to hear them.

one possibility is that both of your combined proxy/registrars have
their own location tables and you forward registrations from one to the
other.

The problem with that is horizontal scalability brings noise. If I have 10
of these things, the SIP replication alone would be flooding the network.

Post by Juha Heinanen
-- juha

[Frank Carmickle]

Post by Juha Heinanen

Post by Ben Langfeld
I figure at this point it may be simpler to separate the registrar and the
proxy rather than attempt to debug this further, though if you have any
other suggestions to avoid that I'd love to hear them.

one possibility is that both of your combined proxy/registrars have
their own location tables and you forward registrations from one to the
other.
The problem with that is horizontal scalability brings noise. If I have 10 of these things, the SIP replication alone would be flooding the network.

If you are running in an environment where you can use multicast it might be an option for you. Multicast the registrations from the edge proxy to the registrar cluster. If not maybe you can get the registrars to replicate to each other on a separate interface from the interface facing the edge proxy.


--FC

[Ben Langfeld]

To follow up, separately deployed WebSocket proxies and registrars (sharing
usrloc DB w/ db_mode 3) are working nicely now. Perhaps I can optimise the
shared location data further, but that's a good enough start for me :)
Thanks for the input from everyone.

Post by Ben Langfeld

Post by Juha Heinanen

Post by Ben Langfeld
I figure at this point it may be simpler to separate the registrar and

the

Post by Ben Langfeld
proxy rather than attempt to debug this further, though if you have any
other suggestions to avoid that I'd love to hear them.

one possibility is that both of your combined proxy/registrars have
their own location tables and you forward registrations from one to the
other.

The problem with that is horizontal scalability brings noise. If I have 10
of these things, the SIP replication alone would be flooding the network.
If you are running in an environment where you can use multicast it might
be an option for you. Multicast the registrations from the edge proxy to
the registrar cluster. If not maybe you can get the registrars to
replicate to each other on a separate interface from the interface facing
the edge proxy.
--FC
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users