We need to make sure that all queue applications run on the correct system that the user agents that own the queue application are registered to. So when a server fails and the user agents register with their secondary server (which will always be configured to be the same server for those related agents) the queue application is running on that server and routed to correctly by it's peers. Enters DUNDi:
Working scenario: 1) Configured 3 contexts, referenced by DUNDi, to manage which server is the primary, secondary, and tertiary server for each given queue. So: a. UA1, 2, and 3 register with Astbox1 as their primary server b. Their registration tables refer to Astbox2 as their secondary registration server and Astbox3 as their tertiary registration server c. Agents are logging into the queue1 via UA1, 2, and 3 d. Queue1's dial plan logic is in the same context on all boxes e. Queue1's dial plan logic is referred to via 3 different DUNDi contexts weighted according to which server is the primary, secondary, and tertiary host server for the user agents (UA1,2, and 3) f. So queue1, assigned the phone number of 5551212, is assigned to the Primary DUNDi context on Astbox1 with the weight of 0 g. Then queue1 is assigned to the secondary DUNDi context on Astbox2 with the weight of 100 and to the tertiary DUNDi context on Astbox3 with the weight of 200 h. So let's say we make a call from an User Agent on Astbox2 to 5551212 i. When determining which server to terminate a call to 5551212 on we do a local lookup first on Astbox2 to see if the primary server for that number happens to be the server performing the routing logic... if so, we directly route the call to that queue on the local server j. In this case Astbox2 does not refer to queue1 in the primary DUNDi context, Astbox1 refers to queue1 in it's primary context, so we do a DUNDi lookup to find the next server we should route the call to k. Due to weighting, we receive the IP of Astbox1 as the first DUNDi destination and the IP of Astbox3 as a second DUNDi destination serving that queue and we route the call to the first destination IP l. Everything is fine... but when the primary server fails (Astbox1) and the the secondary server happens to be the box that is routing the call (Astbox2) there is a logic gap we need help addressing 2) Logic gap we need to address a. UA1, 2, and 3 normally register with Astbox1 as their primary server but it has now failed b. So UA1, 2, and 3 now register with Astbox2 c. Due to queue1's routing logic, that the agents assigned to UA1, 2, and 3 log into, residing in the same context on all boxes we are able to handle calls to that context on Astbox2 (please refer to our statement in 1.d through 1.g to re-paraphrase the queue and agent relationship) d. So let's say we make a call from a user agent Astbox2 to 5551212 e. When determining which server to terminate a call to 5551212 on we do a local lookup first on Astbox2 to see if the primary context shows that number as local (queue1)... if so, we directly route the call to that queue on the local server f. In this case it is not because the context we are referring to (PRIMARY) does not reside on Astbox2 with 5551212 in it's context so we do a DUNDi lookup to find the next server we should route the call to g. Due to weighting and the fact that Astbox1 has failed, we receive the IP of Astbox3 as the only DUNDi destination serving that queue (HERE IS THE PROBLEM --- Astbox3 is tertiary... the box during this failed condition that has the highest weight is the box doing the lookups (Astbox2) along with Astbox2 is the box that the destination agents of the queue are now registered with) h. If we could actually query to find the weight of the DUNDi returned lookup we could add logic to the scripting to determine if it is the Primary server with a weight of 0. i. If not we could add some logic to see if the server we are on happens to be the secondary j. If so the call would then remain on that box k. If not we could then route to the returned IP address from the DUNDi lookup _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
