50% split in my company between phones provided by call manager and phones provided by PABX
I have noticed that when transferring calls from call manager to PABX the call drops. Prior to transferring the call the person can speak to the other end but when they press the transfer button this is when the call drops.
we are currently in the clearing/enrolment process of their calendar year. This means that: 1. There has been a change freeze so this should not have been the result of a change. 2. There is a heightened impact and urgency to this issue.
The issue appears constant, and it is quite unlikely that it began earlier than today as it would likely have been reported. There are no error messages showing in call manager, and neither call manager or PABX have been restarted.
There are 4 subs and 1 primary in the cluster. They are running Call Manager version 9.1
2 sites are affected. This could be affecting everyone or a small group - at present they are not able to confirm. The current impact could be very high due to clearing/enrolment.
Last time had an issue it was a sub that was overloaded as most of the softphone clients were registering to the one sub which was causing a CPU overload. I have not yet had a chance to check if this may be the case this time.
Can you please suggest some thing about this behaviour and how to fix it, It would be much appreciated.
The first thing I would do is identify a specific call flow that causes the behavior and document it. For example "Susie at CUCM DN 2000 calls Bob on CUCM DN 2001 who then transfers the call to Jane on PABX extension 3000. There is a H.323 trunk between CUCM and PABX." This is a very different call to troubleshoot than, perhaps "Susie from PSTN TN 4045550100 calls Bob on CUCM DN 2001. The call ingresses on gateway <hostname> from a PRI and the gateway uses <protocol> to route the call to CUCM. Bob then transfers the call to Jane on PABX extension 3000. There is a H.323 trunk between CUCM and PABX."
So, pin down exactly what call flow gets dropped and the equipment/protocols involved.
After you have this pinned down then reproduce the call drop with CUCM traces set to detailed. Look at the log and start asking some questions such as "Who (e.g. the PSTN gateway, CUCM, the PABX) drops the call and do they provide a Q.850 cause code?" If it's CUCM then you need to scroll backward and see what else happened that would cause CUCM to give up. This might be the point where you need a TAC case if you're not good at reading CUCM SDI/SDL traces.
Les stations de radio en ligne sont devenues l'une des formes de partage des médias les plus populaires dans la ecouter radio en ligne société d'aujourd'hui. La radio Internet est maintenant disponible sur tous les principaux modems de câbles et sans fil ...
This document describes the details about the Cisco Collaboration Endpoint software upgrade error “File too large”, and guides through the possible workarounds to upgrade the endpoint to the desired version.
we have recently announced a new Webex Events service with a best-in-class virtual event experience that is video-centric, intelligent, and simple to use.
Some highlights (features of new Webex Events that were not there with existing/c...
The purpose of this document is to present the different troubleshooting steps to take when some service from the Cisco IM & Presence Service Server have not started gracefully.
The States of a service
The IM&P ...
This event had place on Tuesday 20th, April 2021 at 10hrs PDT
What is the Real-Time Monitoring Tool (RTMT) and how do I use it? In addition to an overview of the components of the tool and the interface, attendees learned how to use ...