3 Mar
2016
3 Mar
'16
5:37 p.m.
Hi,
If I understand the DMQ documentation correctly, when a SIP request is
distributed to other Kamailio instances via dmq_t_replicate(), it is not
merely sent as a payload in a novel way, but actually "rehydrated" by
the receiver into a mock request on the other end and processed as
through it were a "real" message that came into the request_route[] in
the natural way.
Is this an accurate assumption?
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
3 Mar
3 Mar
6:09 p.m.
Hi Alex,
Yes, you are correct. It simply wraps the standard t_replicate() function,
replicating the original request to every other node (first appending a new
branch for each). Use case is essentially the same as the original but
having the benefit of not having to define destination(s) statically in
config, since that part is handled by DMQ.
Cheers,
Charles
On 3 March 2016 at 15:37, Alex Balashov <abalashov(a)evaristesys.com> wrote:
Hi,
If I understand the DMQ documentation correctly, when a SIP request is
distributed to other Kamailio instances via dmq_t_replicate(), it is not
merely sent as a payload in a novel way, but actually "rehydrated" by the
receiver into a mock request on the other end and processed as through it
were a "real" message that came into the request_route[] in the natural way.
Is this an accurate assumption?
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.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
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
6:14 p.m.
On 03/03/2016 11:09 AM, Charles Chance wrote:
Yes, you are correct. It simply wraps the standard
t_replicate()
function, replicating the original request to every other node (first
appending a new branch for each). Use case is essentially the same as
the original but having the benefit of not having to define
destination(s) statically in config, since that part is handled by DMQ.
I see! Thank you.
What I've got seems like a good use-case for clustering over DMQ as a
transport: a number of Kamailio servers that all answer on the same SIP
domain, and a nondeterministic Layer 3 routing topology where some
replies occasionally traverse a different Kamailio server to the one
that processed the request to which they correspond. For a wide variety
of reasons, I need to handle all this statefully, not statelessly.
So, it seems like I ought to be able to dmq_t_replicate() incoming
INVITEs to other nodes and, on those nodes, instantiate the transaction
with t_newtran(). But one would also need to devise a mechanism to
inform those secondary nodes that the message should not be t_relay()'d
unless the primary server for which it was intended (itself difficult to
identify due to same SIP domain everywhere) was determined to be out of
service. I don't suppose there's some clever shortcut to implementing
that kind of conditional logic manually?
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
6:29 p.m.
In the first instance, you could use dmq_is_from_node() to determine if the
message is a replicated one and if so, don't relay.
There's no specific function to check the state of other nodes, although it
would be a simple addition. If I understand your question correctly,
however, if the message has just been replicated by the primary server then
it's safe to assume it's in service, right?
Cheers,
Charles
On 3 March 2016 at 16:14, Alex Balashov <abalashov(a)evaristesys.com> wrote:
On 03/03/2016 11:09 AM, Charles Chance wrote:
Yes, you are correct. It simply wraps the standard t_replicate()
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
function, replicating the original request to
every other node (first
appending a new branch for each). Use case is essentially the same as
the original but having the benefit of not having to define
destination(s) statically in config, since that part is handled by DMQ.
I see! Thank you.
What I've got seems like a good use-case for clustering over DMQ as a
transport: a number of Kamailio servers that all answer on the same SIP
domain, and a nondeterministic Layer 3 routing topology where some replies
occasionally traverse a different Kamailio server to the one that processed
the request to which they correspond. For a wide variety of reasons, I need
to handle all this statefully, not statelessly.
So, it seems like I ought to be able to dmq_t_replicate() incoming INVITEs
to other nodes and, on those nodes, instantiate the transaction with
t_newtran(). But one would also need to devise a mechanism to inform those
secondary nodes that the message should not be t_relay()'d unless the
primary server for which it was intended (itself difficult to identify due
to same SIP domain everywhere) was determined to be out of service. I don't
suppose there's some clever shortcut to implementing that kind of
conditional logic manually?
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.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
6:31 p.m.
On 03/03/2016 11:29 AM, Charles Chance wrote:
In the first instance, you could use
dmq_is_from_node() to determine if
the message is a replicated one and if so, don't relay.
There's no specific function to check the state of other nodes, although
it would be a simple addition. If I understand your question correctly,
however, if the message has just been replicated by the primary server
then it's safe to assume it's in service, right?
I would think in almost all imaginable modes of operation, yes.
How are replies handled? Can these be dmq_t_replicated() too, so that
the transaction is properly aged through its life cycle on the other
nodes, too?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
7:33 p.m.
The function is only available to request route right now - it's been a
while so I don't recall the exact reasons behind it, however the same
restriction applies to t_replicate().
I can take a closer look later and let you know for sure.
Charles
On 3 March 2016 at 16:31, Alex Balashov <abalashov(a)evaristesys.com> wrote:
On 03/03/2016 11:29 AM, Charles Chance wrote:
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
In the first instance, you could use
dmq_is_from_node() to determine if
the message is a replicated one and if so, don't relay.
There's no specific function to check the state of other nodes, although
it would be a simple addition. If I understand your question correctly,
however, if the message has just been replicated by the primary server
then it's safe to assume it's in service, right?
I would think in almost all imaginable modes of operation, yes.
How are replies handled? Can these be dmq_t_replicated() too, so that the
transaction is properly aged through its life cycle on the other nodes, too?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.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:33 p.m.
Charles,
If replication for replies is not available, how would a replicated
transaction transition through its life cycle on a standby cluster node?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
8:58 p.m.
Hi Alex,
The function was primarily intended for onward replication of successful
REGISTERs, rather than transactional state.
Assuming the function was available for replies, how do you anticipate
handling them on the standby node(s)?
Cheers,
Charles
On 3 Mar 2016 17:33, "Alex Balashov" <abalashov(a)evaristesys.com> wrote:
Charles,
If replication for replies is not available, how would a replicated
transaction transition through its life cycle on a standby cluster node?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.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
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
9 p.m.
On 03/03/2016 01:58 PM, Charles Chance wrote:
Hi Alex,
The function was primarily intended for onward replication of successful
REGISTERs, rather than transactional state.
Assuming the function was available for replies, how do you anticipate
handling them on the standby node(s)?
Some mechanism would be needed to drop them, e.g. in a stateless default
onreply_route.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
4 Mar
4 Mar
10:37 a.m.
I'm not aware of such mechanism existing already, although I may have
overlooked something. It's likely easier though in my opinion, and more
beneficial to the project overall, to add replication directly within the
tm module - similar to that which exists in htable, with a flag to
enable/disable it.
Seems to me the most appropriate solution all round.
Alternatively, if a function is made available to update transaction state
manually on the receiving node, you may then be able to use
dmq_bcast_message() to relay the information yourself with some custom
payload.
Best,
Charles
On 3 Mar 2016 7:00 pm, "Alex Balashov" <abalashov(a)evaristesys.com> wrote:
On 03/03/2016 01:58 PM, Charles Chance wrote:
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
Hi Alex,
The function was primarily intended for onward replication of successful
REGISTERs, rather than transactional state.
Assuming the function was available for replies, how do you anticipate
handling them on the standby node(s)?
Some mechanism would be needed to drop them, e.g. in a stateless default
onreply_route.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.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
3215
days inactive
3216
days old
9 comments
2 participants
participants (2)
-
Alex Balashov -
Charles Chance