CUCM 10.5 - Order of trunks in Route Group ignored...Not sure why

[voip7372]

Question #1   

I've had a voice mail pilot number working for a long time now.  It's MS Unified Messaging (MS UM for short).  Since we have more than one MS UM server, I thought I'd go ahead and create a SIP trunk for each of the MS UM servers and then put them in the existing Route Group (RG).  I thought I'd go ahead and reorder the trunk groups listed in the RG just to be sure my configure for the new trunk groups was correct.  I have the SIP Options Ping enabled in my SIP profile and I do see all the MS UM SIP trunks with a status of 'Full Service'.  Anyway, if I place one of the newly added SIP trunks for MS UM at the top of the existing RG, my calls are still ending up at the original MS UM server.  It's like CUCM is ignoring the fact that I placed the new SIP trunk at the top and it keeps routing to the old/existing SIP trunks/MS UM server I had in this RG.   I tried resetting the SIP trunks and also reset the Route List (which I didn't think I'd need to do, but I did it anyway) and the result is the same.  It won't select the new SIP trunks no matter what I try.  

I didn't try removing the original SIP trunk from that RG yet and I don't want to do it during the business day, but I could try that after hours and see what happens then.  

Any ideas about why it won't use the new SIP trunks even though they're in service and at the top of the RG list (higher priority), above the original SIP trunk?  My RG is set for top down, not circular.  

Question #2:

Here's a somewhat related question.  (screenshot attached for this one)  I first thought I could simply go to the original SIP trunk and add the other IP addresses for the ofther MS UM servers so I wouldn't need to create more SIP trunk groups for this.  Maybe I'm understanding it wrong, so please enlighten me what these fields are really used for.  On the SIP trunk page, there's a SIP Information section and that's where you add the IP address of the device CUCM is talking to (Destination).  For example, the MS UM server.  Was I wrong to assume that if the SIP trunks would be identical in their config you can simply add the other IP addresses for the alternate MS UM servers here in this section of the SIP trunks page?   What exactly would the extra IP address fields be used for (when you click + to added another address)?   

As soon as I added a second IP address, my calls to MS UM stopped working.  After I removed the second IP (which is for an alternate MS UM server), everything started working again.  Just curious how that IP address field should really be used.  For now, I simply created new SIP trunk groups for the other MS UM servers.

Thanks :-)

[Shadi Shami · Accepted solution]

Hello,

For me both questions are related, and I expect a communication issue between CUCM and the new MS UM server.

I would like to start with the 2nd question as it answers both, the below is mentioned in the admin guide of CUCM 8.5 but no much explanation was added to the admin guide of 10.0:

"•When an outbound call gets placed, a destination address gets chosen randomly. No preference is given to one destination address over another. All SIP messages that are sent out for a given outbound call go to the same destination address.

•The SIP trunk accepts inbound messages from any of the configured destination addresses."

The above answers your inquiry, redundancy cannot be achieved by configuring multiple destinations. And calls are dropped when you add the new ip address within the same trunk, because it was chosen but the CUCM was not able to communicate with it, and also this explains why the new MS UM server trunk was not selected in the RG, as CUCM also was not able to communicate with it and moved to the next member in the RG (i.e. the old MS UM).

- Can you try to ping the new MS UM server from CUCM server, SSH to CUCM server and issue the following command: utils network ping IP_ADDRESS_OF_NEW_MS_UM

- It can be that the new MS UM server is configured to accept only SIP UDP messages, can you try changing it from the SIP security Profile?

If the above two suggestions did not help to isolate the issue, then we need detailed CCM logs covering test outgoing call together with the IP addresses of both MS UM servers.

Thank you,

Shadi

[voip7372]

Wow...that's interesting.   I didn't change anything, but it's working now.  It follows the order I put the SIP trunks in for that RG.  I tested it several times, moving one up to the top and saving it....then make a test call and then check the MS UM server event log to verify the call hit the server I expected.   

The only thing that has happened since I posted this question was....well, over an hour of time has passed, but other than that, the only other thing was that I SSH'd to the Pub and each Sub CUCM server and pinged the MS UM server to make sure it replied.   There are 4 MS UM servers and they've all been in production and working for a long time (they're primarily answering calls from Avaya, but I send these Cisco calls to them too).  

I wonder if the pings from the server somehow forced CUCM to start working for these new MS UM servers?   I have no idea, but it does work now and I didn't change anything.  

[voip7372]

Update.  I spoke too soon.  :-)   There certainly is an improvement because like I said in my last reply, one of the other servers does get selected now if I move it to the top.....but I didn't test the final two at that time.   The other 2 still weren't answering.  

So, I SSH'd to the Pub and 2 Subs again and pinged the other two MS UM servers and they do reply.  I still couldn't get them to answer.  Finally, I went to the trunk page in CUCM for each of those two MS UM servers and clicked Reset and Restart.  After waiting a few seconds, I can now get all 4 of them to answer in any order I want by moving them up or down in the RG.  

[Charles Hill]

Glad you got it working!

I had a similar issue where the correct trunks were not selected in the route group.

It was actually a database replication issue.

[Shadi Shami]

That's a good news ..  from the behavior it looked like a communication issue, but not sure if the ping can help in forcing the communication establishment or clear out any stuck tcp communication.

[voip7372]

Thank you.   And last question/follow-up.   So, based on what you said in your original reply, to use the 4 MS UM servers the way I intended, I really do need to have them added in CUCM as 4 separate SIP trunks and this is a totally acceptable and proper way to do it?   The whole point is just to be sure that if one of those MS UM servers is unavailable, the other 3 in the list can be used by CUCM.

[Shadi Shami]

that's totally correct.

[voip7372]

Thanks