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
Hello,
On 14/10/14 23:56, Ben Langfeld wrote:
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()?
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
Em 15/10/2014, às 07:18, Daniel-Constantin Mierla miconda@gmail.com escreveu:
Hello,
On 14/10/14 23:56, Ben Langfeld wrote: 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()?
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.
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 sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 15/10/14 14:19, Ben Langfeld wrote:
Em 15/10/2014, às 07:18, Daniel-Constantin Mierla miconda@gmail.com escreveu:
Hello,
On 14/10/14 23:56, Ben Langfeld wrote: 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()?
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
On 15 October 2014 10:33, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 15/10/14 14:19, Ben Langfeld wrote:
Em 15/10/2014, às 07:18, Daniel-Constantin Mierla miconda@gmail.com
escreveu:
Hello,
On 14/10/14 23:56, Ben Langfeld wrote: 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()?
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,
Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Ben Langfeld writes:
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
On 15 October 2014 11:32, Juha Heinanen jh@tutpro.com wrote:
Ben Langfeld writes:
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.
-- juha
On Oct 15, 2014, at 10:40 AM, Ben Langfeld ben@langfeld.me wrote:
On 15 October 2014 11:32, Juha Heinanen jh@tutpro.com wrote: Ben Langfeld writes:
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
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.
On 15 October 2014 11:47, Frank Carmickle frank@carmickle.com wrote:
On Oct 15, 2014, at 10:40 AM, Ben Langfeld ben@langfeld.me wrote:
On 15 October 2014 11:32, Juha Heinanen jh@tutpro.com wrote:
Ben Langfeld writes:
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
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Ben Langfeld -
Ben Langfeld -
Daniel-Constantin Mierla -
Frank Carmickle -
Juha Heinanen