11-04-2020 06:50 AM
Hi,
I'm having an issue with a specific meeting number in the Conference Now feature.
Once I dial the Conference Now IVR Directory Number, I reach the IVR, the IVR then asks for the meeting number I put the required meeting number which is "629" and the call then immediately disconnects without any further information, message or sound. Any other meeting number I put will work.
I also changed the meeting number (self user ID) in the specific End User from "629" to "628" for example, and it worked.
so it seems like the issue only occurs when "629" is configured as the meeting number.
I would be very thankful for any insight that can help with this case.
Thanks in advance.
11-04-2020 07:55 AM
11-05-2020 12:14 AM - edited 11-05-2020 12:15 AM
Hello Mohammed, Thank you very much for the response. There is something that is unclear to me, if overlapping is causing this issue then why don't I experience the same issue with the meeting number "630", - I have a pattern that starts with "629" and one that starts with "630", therefore I assume that if there is indeed an overlap with "629" there should also be an overlap with "630"
I attached 2 screen-shots that show both 629 and 630 patterns as showed in the route plan report.
Mohammed,
Thank you very much for your help, it is much appreciated.
11-04-2020 08:26 AM
Wow! That is an interesting one. I agree with Mohammed that checking for an overlapping number somewhere is a good idea. CUCM won't let you have two self-service IDs that are the same, so what would be overlapping is a mystery to me but stranger things have happened.
Question: Can the person with the 629 self-service ID start (host) the meeting? Or is this a matter of participants not being able to join? And, if the host can indeed start the meeting, is it a problem with participants not being able to join before the host or both before and after the host?
If the Route Plan Report does not reveal the problem, I would suggest pulling traces for the CallManager service and the IVR service and posting them here. Between them we should be able to figure out what is going on. The CallManager service trace should be for the call processing node to which a device is registered and if that can be the same node on which the IVR service is running that would be easier.
Maren
11-05-2020 12:23 AM
Hi Maren,
Thank you very much for your response, and I am too, having trouble trying to understand what could cause an overlap.
To your question - neither the host nor participants can join with this meeting number.
As for pulling traces and posting them here - unfortunately, this can't be done since the customer has sensitive classification policies and restrictions, though you can guide me as for what to look at and ill be very thankful for that.
Thank you very much Maren.
11-05-2020 04:09 AM
I agree that once you are inside the Conference Now IVR that other overlaps interfering with the ability to host or join a meeting is unlikely, but software is software and stranger things have happened. More importantly, as the matches you have for 629 in the Route Plan Report are all longer than 3 digits I would expect some weird overlap to invoke the interdigit timeout rather than generate an immediate disconnect. So I think we can rule an overlap out for the time being.
As for the trace files, as I've never seen this problem before I can't give you a specific thing to look for. What I would be doing is tracking the call and the attempt to start the Conference Now session step-by-step trough the trace files and see what CUCM tells me. I'd look at the IVR trace first because it should be shorter and hopefully the problem just jumps out. Helpfully, the IVR trace should give you the timestamps you need to help you parse the CallManager trace file(s).
I do suggest, so that you are working with a single CallManager trace file, that you have the phone(s) you are working with to reproduce the problem be registered to the same server as the IVR service if at all possible. If these are different servers it will be more complicated just because of the numbers of files to plow through.
Maren
11-18-2020 03:11 AM - edited 11-18-2020 11:35 PM
Hi Maren,
After the solution I gave to the customer (to change the meeting number to a different one), I'm having the same issue with a different meeting number, this time - "164", therefore changing the meeting number is not an acceptable solution anymore.
As you instructed - I pulled the CallManager trace files - working with a single CallManager trace file.
I will now post the relevant logs I found for one of the calls to the IVR that ends with me "dialing" the meeting number "164" that causes the call to disconnect.
You will see that the last "Bye" SIP message includes Cause 1 (unallocated).
I did not yet restart any service whatsoever, so restarting the CallManager service might aswell fix this bug, though before I do that
I prefer to try an understand what causes this issue so if I will ever encounter a similar situation in the future - I will know, at least to some degree, what is going on.
Trace Info:
Calling DN - 84029
Called DN (Conference Now IVR) - 86666
Meeting Number - 164
11-18-2020 08:54 AM
At this point in time I would recommend you, if not already done so, to open a case with TAC to have them look at this. A fair guess would be that you’re hitting a defect.
11-19-2020 09:22 AM
I looked through the two files. I get that you're in a secure environment and had to sterilize and extract as little as possible, but there's a lot missing in the trace file that I'd be looking at, like digit analysis, the Media Resource Manager choosing a conference resource, the MRM signaling out to the resource and the resource's response, etc. (And the trace file is truncated.) The fact that CUCM is at least attempting to access a conference resource (b00505501144) is a good sign, but I don't see the signaling going out to it. And in the SIP Trace, I see the Notify messages where the KPML is transmitted but the actual XML code below the Notify (which contains the dialed digits) is missing.
If you can provide a fuller trace file privately, I can take a look. Otherwise I think - to Roger's suggestion - that it's time to call TAC.
Maren
11-09-2020 01:49 AM
Hello Mohammed and Maren,
After a failed attempt to re-create this problem in my own lab environment with an identical configuration to this of the Customer, overlapping is not what causing the issue, or at least its not visible in any log report or configuration I could find. Restarting the call manager might be a fix for this issue but its not something that could be done at this point.
so for the time being, the solution I offered to the customer is to change the meeting number from "629" to anything else.
Btw, I forgot to mention that the Version of the CUCM is 11.0
Thank you both Mohammed and Maren for your help!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide