[cisco-voip] Calling Name lost inbound from PSTN over Intercluster Trunk with QSIG

[Linsemier, Matthew]

Ryan,

The answer in 2008 from Wes had to do with setting up a phone in a corner with a xxxx extension in different CSS and then answered the calls on the 6.1 side then did a CFA via over the ICT to the other cluster.  From what I understand the way that it comes in from the PSTN on the 6.1 server and how the UC acts is that it is immediatly processed by the route pattern to the ICT and the 6.1 cluster does not process the Calling Name and it gets lost in transit.

What traces should I take a look at?  I thought perhaps others had seen this type of behavior before.

Matt

Sent from my iPad

On Oct 29, 2012, at 10:30 AM, "Ryan Ratliff" <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:

What was the answer you got in 2008?   In order for calling name to be delivered to the remote cluster the originating cluster is going to have to send it, and the remote is going to have to honor it.

How is the name delivered on the 6.1 side and what do ccm traces show for what it sends on to the 8.6 cluster?

-Ryan

On Oct 28, 2012, at 4:26 PM, "Linsemier, Matthew" <MLinsemier at thedoctors.com<mailto:MLinsemier at thedoctors.com>> wrote:


All,

I asked this question back in 2008 and I am wondering if anything has changed since then.

I have two Unified Communication clusters, one on 6.1 (existing) and a new one on 8.6 (new greenfield cluster).  They are currently connected via a Intercluster Trunk using QSIG.  Everything is working well across the trunk from internal calling name and number as well as MWI.

The issue we are having is as we move users from the old cluster to the new cluster, inbound calls from the PSTN on the old cluster (via MGCP gateways that are still registered there) destined for users on the new cluster will lose calling name.  This means that during the migration (which will be going on for 3-4 weeks), users on the new cluster will lose Calling Name from outside PSTN users.

PSTN GW – MGCP --> UC6.1 <--- ICT ---> UC8.6 --- Phone

Is there any way to fix this?

Sincerely,

<image001.gif>




Matthew M. Linsemier, CCNP / CCDP
Senior Network Engineer
The Doctors Company

• 517.324.6695
• mlinsemier at thedoctors.com<mailto:mlinsemier at thedoctors.com>





Confidentiality Notice: This message and any attachments hereto may contain confidential and privileged communications or information and/or attorney client communications or work-product protected by law. The information contained herein is transmitted for the sole use of the intended recipient(s). If you are not the intended recipient or designated agent of the recipient of such information, you are hereby notified that any use, dissemination, copying or retention of this e-mail or the information contained herein is strictly prohibited and may subject you to penalties under federal and/or state law. If you received this e-mail in error, please notify the sender immediately and permanently delete this e-mail.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip




Confidentiality Notice: This message and any attachments hereto may contain confidential and privileged communications or information and/or attorney client communications or work-product protected by law. The information contained herein is transmitted for the sole use of the intended recipient(s). If you are not the intended recipient or designated agent of the recipient of such information, you are hereby notified that any use, dissemination, copying or retention of this e-mail or the information contained herein is strictly prohibited and may subject you to penalties under federal and/or state law. If you received this e-mail in error, please notify the sender immediately and permanently delete this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121029/995d07d3/attachment.html>