Call Park from PSTN - Gateway or subscriber the phone is registered to?
This question is probably just trivia for someone, but it's giving us fits right now.
The situation is that suddenly call park was failing for a lot of individual offices.
The only changes that had been made recently was that some CUCM subscribers had been moved up in priority in the Call Manager Groups. Some Subscribers have been removed from Call Manager Groups.
There's a SIP Trunk where most inbound calls get processed through.
Let's call all the servers in the cluster 1, 2, 3, 4, & 5.
If the CMG for the SIP Trunk was previously 1, 2, & 3... now it's 1, 4, & 5.
Most phones are registered to 2, & 3.
Now then... Call Park configuration documentation does clearly state that you should have references to each Call Manager server in the cluster. My question is why?
I can't find a definitive answer in documentation, but it seems to indciate (in the interactions section) that if a registered phone places a call in Park, then the Subscriber that the phone is registered to will make the request.
The assumption being that it will use the Call Park reference for that server (that it's registered to).
So again... Phone A is registered to server 2. Call comes in on SIP Trunk registered to server 4.
Phone A has Call Park references for Server 1, 2, & 3. Not servers 4 & 5.
We're finding that Call Park now fails.
It begins working again when we add Call Park references to servers 4 & 5.
At the end of the day, it's not a big deal. I'd just like to have some sort of Cisco branded documentation that states the server that the call initiates on is the server where the call will be parked.
Or, if that's not the way it's supposed to work, then I need to know that too so I can open a TAC case.
If I were to guess, do you have different partitions for the Call Park numbers that are assigned to each server? Maybe the phone that is parking the call doesnt have access to the partition of the Call Park range for the new servers in the CMG?
We duplicate those ranges and server references in each partition.
So... each partition had three (of five) servers referenced. Suddenly we had to add the other two servers. I think because we changed the CMG where the SIP Trunk is. Suddenly calls were on servers 4 & 5 (and they hadn't been before). Servers 4 & 5 are the servers that were NOT referenced in the call park partitions previously.
So, (and this is where I probably sound like a nut) I'm sure most people would say, add the references to servers 4 & 5 to call park, and go get a beer. Problem solved.
Problem not solved because we need to know, for sure, that what's important to call park is the device that has the call. Not the device that initiates the park.
When I go over documentation, it's not clear. It does seem to favor that call park server is the phone that initiates. There aren't any phones registered to servers 4 & 5. So, I shouldn't have needed references to those servers.
If that's true, we have a bug that we need to deal with. So, I'm looking for any documentation that supports that the call park server is the node where the call comes in on. In this case, the node where the SIP trunk is registered.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...