[cisco-voip] Expressway cluster algorithm

Ryan Huff ryanhuff at outlook.com
Wed Jan 23 16:50:01 EST 2019


Well, ideally each inbound caller’s endpoint uses the same implementation of DNS SRV as defined in RFC2782 and respects priorities and weights (my SIP SRV targets the edge cluster FQDN).

And to your point, I can reliably control the edge that accepts the initial inbound INVITE with SRV manipulation, but cannot reliably predict which control peer is used (though you can usually make a good guess).

Ideally, I am trying to guarantee an active/passive use case in all scenarios, ingress and egress.

Sent from my iPhone

On Jan 23, 2019, at 16:32, Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>> wrote:

Is this for inbound B2B or for MRA?

If inbound B2B, it's more up to the caller's implementation of DNS.  If the caller is Webex, their may be some documented behavior out there somewhere.

On Wed, Jan 23, 2019 at 4:17 PM Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
I’m trying to guarantee an active/passive use case; so maintenance mode would achieve that (or shutting one side down), but would require manual intervention, and be as clunky of a work-a-round as it gets for a runtime solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer explained that there were at least two selection processes in play, which C (or E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are testing a particular path, you want to put the nodes you don’t want to use into maintenance mode.

Made sense to me at the time.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>

www.uoguelph.ca/ccs<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C4952beb33b064065817608d6817a4fd3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636838759650501266&sdata=1%2Br2cLteB5DSYaYHM%2FK0FKD7uTK%2B1HxiY%2FQB0oSIJ8c%3D&reserved=0> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to determine which Expressway node in a given cluster is selected to process a call.

You can influence the selection with DNS SRV priority and weight, but does not appear to guarantee which cluster node is selected each time.

Thanks,

Ryan
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C4952beb33b064065817608d6817a4fd3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636838759650501266&sdata=pIdjV%2F45m%2Fq0IH45cl8WNOWTJ46jM30ktTe3znSCWIY%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C4952beb33b064065817608d6817a4fd3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636838759650501266&sdata=pIdjV%2F45m%2Fq0IH45cl8WNOWTJ46jM30ktTe3znSCWIY%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190123/db74501f/attachment.html>


More information about the cisco-voip mailing list