26 Mar
2013
26 Mar
'13
8:51 a.m.
Hi all,
I was wondering, how are others sharing dialog module (particularly
profile) state between multiple servers?
Thanks in advance,
Charles
--
www.sipcentric.com
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
B7 4EJ.
26 Mar
26 Mar
11:05 a.m.
Hello,
On 3/26/13 1:51 PM, Charles Chance wrote:
Hi all,
I was wondering, how are others sharing dialog module (particularly
profile) state between multiple servers?
if it is just about counting the active dialog calls per user/ip/etc ...
so far I am mainly using htable, with notifications from each node to
the other using uac_req_send() (see next for ways for when to send
notifications). I index by key (userid,ip/etc) plus the call id, then I
use $shtcn(...) to get the number of items for an user/ip/etc...
An alternative is to use a database table and replicate its content.
This comes in addition to the dialog table, using the event_routes
exported by the dialog module to update records:
- http://kamailio.org/docs/modules/stable/modules/dialog.html#id2556376
dmq module is supposed to offer the framework for inter-kamailio
communication, iirc, the developer added support for distributing htable
keys. But then he changed job and didn't work further on this part, it
is in my list to get it going again before next major release.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
12:30 p.m.
Hi Daniel,
Yes, dmq is the clear way forward once it's working. Is it a lot of work to
get going again? For it to be really useful, I would imagine other modules
will need to make use of it from within their code, rather than the user
trying to do stuff in the config. I may take a look and see how far along
it is.
The others all seem to hinge around dialog:start and dialog:end event
routes, but we really need to replicate info about early dialogs too. So I
think we'll have to send some notifications from the other routes as well.
Anyway, thanks again,
Charles
On 26 March 2013 15:05, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello,
On 3/26/13 1:51 PM, Charles Chance wrote:
--
www.sipcentric.com
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
B7 4EJ.
Hi all,
I was wondering, how are others sharing dialog module (particularly
profile) state between multiple servers?
if it is just about counting the active dialog calls per user/ip/etc ...
so far I am mainly using htable, with notifications from each node to the
other using uac_req_send() (see next for ways for when to send
notifications). I index by key (userid,ip/etc) plus the call id, then I use
$shtcn(...) to get the number of items for an user/ip/etc...
An alternative is to use a database table and replicate its content. This
comes in addition to the dialog table, using the event_routes exported by
the dialog module to update records:
- http://kamailio.org/docs/**modules/stable/modules/dialog.**
html#id2556376<http://kamailio.org/docs/modules/stable/modules/dialog.ht…
dmq module is supposed to offer the framework for inter-kamailio
communication, iirc, the developer added support for distributing htable
keys. But then he changed job and didn't work further on this part, it is
in my list to get it going again before next major release.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/**miconda<http://www.linkedin.com/in/miconda&…
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.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<http:/…
12:40 p.m.
Hello,
On 3/26/13 5:30 PM, Charles Chance wrote:
Hi Daniel,
Yes, dmq is the clear way forward once it's working. Is it a lot of
work to get going again? For it to be really useful, I would imagine
other modules will need to make use of it from within their code,
rather than the user trying to do stuff in the config. I may take a
look and see how far along it is.
The others all seem to hinge around dialog:start and dialog:end event
routes, but we really need to replicate info about early dialogs too.
So I think we'll have to send some notifications from the other routes
as well.
Initial dialog event_route was not added because that is practically the
moment when dlg_manage() is executed for initial INVITE -- if there is
no error executing dlg_manage(), do the actions for initialing the state
on the other nodes as well.
Could be easier to add event_routes for add to/remove from profiles --
the information is really small there, replicating it should be easy. Or
even skip event routes and replicate directly from inside dialog module
using dmq.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
2:36 p.m.
Thanks Daniel, that's what I'm thinking (dmq).
I'll let you know how I get on!
Cheers,
Charles
On Mar 26, 2013 4:40 PM, "Daniel-Constantin Mierla" <miconda(a)gmail.com>
wrote:
Hello,
On 3/26/13 5:30 PM, Charles Chance wrote:
--
www.sipcentric.com
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
B7 4EJ.
Hi Daniel,
Yes, dmq is the clear way forward once it's working. Is it a lot of work
to get going again? For it to be really useful, I would imagine other
modules will need to make use of it from within their code, rather than the
user trying to do stuff in the config. I may take a look and see how far
along it is.
The others all seem to hinge around dialog:start and dialog:end event
routes, but we really need to replicate info about early dialogs too. So I
think we'll have to send some notifications from the other routes as well.
Initial dialog event_route was not added because that is practically the
moment when dlg_manage() is executed for initial INVITE -- if there is no
error executing dlg_manage(), do the actions for initialing the state on
the other nodes as well.
Could be easier to add event_routes for add to/remove from profiles -- the
information is really small there, replicating it should be easy. Or even
skip event routes and replicate directly from inside dialog module using
dmq.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/**miconda<http://www.linkedin.com/in/miconda&…
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
3:21 p.m.
On 3/26/13 7:36 PM, Charles Chance wrote:
Thanks Daniel, that's what I'm thinking (dmq).
Welcome! Not sure it would help anyhow, but htable should have support
for dmq replication -- quick source code reveals that, although the
readme of htable does not have any related note.
Cheers,
Daniel
I'll let you know how I get on!
Cheers,
Charles
On Mar 26, 2013 4:40 PM, "Daniel-Constantin Mierla" <miconda(a)gmail.com
<mailto:miconda@gmail.com>> wrote:
Hello,
On 3/26/13 5:30 PM, Charles Chance wrote:
Hi Daniel,
Yes, dmq is the clear way forward once it's working. Is it a
lot of work to get going again? For it to be really useful, I
would imagine other modules will need to make use of it from
within their code, rather than the user trying to do stuff in
the config. I may take a look and see how far along it is.
The others all seem to hinge around dialog:start and
dialog:end event routes, but we really need to replicate info
about early dialogs too. So I think we'll have to send some
notifications from the other routes as well.
Initial dialog event_route was not added because that is
practically the moment when dlg_manage() is executed for initial
INVITE -- if there is no error executing dlg_manage(), do the
actions for initialing the state on the other nodes as well.
Could be easier to add event_routes for add to/remove from
profiles -- the information is really small there, replicating it
should be easy. Or even skip event routes and replicate directly
from inside dialog module using dmq.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
www.sipcentric.com <http://www.sipcentric.com/>
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592.
Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court
South, Birmingham B7 4EJ.
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
4305
days inactive
4305
days old
5 comments
2 participants
participants (2)
-
Charles Chance -
Daniel-Constantin Mierla