<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
try this:<br>
create a line on a registered phone with wildcards<br>
612XXXX<br>
<br>
stick the phone in the corner and turn off the ringer.<br>
set the inbound gateway css to hit this dn for incoming calls to 612XXXX<br>
<br>
set CFNA timer to something over ~6 seconds and use XXXXXXX<br>
(literally X's) as the forward no answer destination. This is a mask
and will automatically propagate the digits from the current called
number.<br>
Give it a forwarding css that allows it to hit your actual route
pattern 612XXXX that points to the cm612 ICT.<br>
<br>
you can either play the above games with CSS or you can use different
number prefixes, but the result should be the same. so long as the
cm413 cluster receives the cname info from pstn before it extends the
call the info should be presented to the next hop destination.<br>
<br>
/wes<br>
<br>
Matthew Linsemier wrote:
<blockquote cite="mid:C4571A60.1BA6%25MLinsemier@apcapital.com"
type="cite">
<pre wrap="">I Suspect that you are right in regards to the ICT trunk.
If you call in from the PSTN to the CM 4.1(3) Cluster and answer a CM 4.1(3)
phone, you get calling name and number (we have had this working via MGCP
for the last 5 years).
If you then transfer this CM 4.1(3) call (with name and number) over to the
CM 6.1(2) cluster, you get the name and number of both calling parties
throughout the transfer.
They both hit the same route pattern which forwards the call over the ICT,
yet if you direct dial the same number into the CM 4.1(3) cluster, which
then hits the route pattern and forwards the call over to the CM 6.1(2)
cluster via the ICT, calling name is dropped.
Thoughts? Ideas?
On 5/19/08 11:12 AM, "Wes Sisk" <a class="moz-txt-link-rfc2396E" href="mailto:wsisk@cisco.com"><wsisk@cisco.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Matt,
I suspect this has to do with isdn cname feature and then propagation over
the ict.
if you:
call from pstn into cm413 phone
answer cm413 phone
do you get calling name/number on cm413 phone?
if you then consult transfer that call over ict to cm612
do you get cm413 calling name/number on cm612 phone?
complete transfer (2nd transfer button)
do you get pstn calling name/number on cm612 phone?
/Wes
On Mon, 19 May 2008, Matthew Linsemier wrote:
</pre>
<blockquote type="cite">
<pre wrap="">So a bit more on this. It looks like calling name works from the outside
(via MGCP) when the calls comes in via a IPCC Express CTI route
point/trigger, but not via DID.
Anyone that can offer any input on this would be great. I¹m beating my head
against the wall trying to get this to work.
On 5/15/08 4:52 PM, "Matthew Linsemier" <a class="moz-txt-link-rfc2396E" href="mailto:MLinsemier@apcapital.com"><MLinsemier@apcapital.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello all,
We are currently working on migrating from an existing CallManager 4.1(3)
cluster to a fresh install of CallManager 6.1(2) in our environment. In our
4.1(3) environment, our gateways are configured with MGCP with both calling
name and number displayed from the PSTN. I have configured a non-gateway
controlled Inter-Cluster H.323 (QSIG) trunk between the two clusters, set up
a
few route patterns, and calls are working back and fourth.
I have noticed that calling name is only working from subscribers on the
CallManager 4.1(3) cluster, and not incoming calls from the PSTN network
which
enter that cluster, and then route to the new CallManager 6.1(2) cluster
over
the Inter-cluster trunk.
Caller [Matt/1234] --> MGCP GW [Matt/1234] --> CM4.1(3) [Matt/1234] -->
Trunk
--> CM6.1(2) [1234] --> Phone only displays [1234] with no name.
Is there a way to pass this PSTN caller ID information on or is this a
limitation? Our hopes were to maintain the same functionality (outside
calling name) as we migrate users from one cluster to another.
Any input would be greatly appreciated.
Matt
</pre>
</blockquote>
<pre wrap="">
CONFIDENTIALITY STATEMENT
This communication and any attachments are CONFIDENTIAL and may
be protected by one or more legal privileges. It is intended
solely for the use of the addressee identified above. If you
are not the intended recipient, any use, disclosure, copying
or distribution of this communication is UNAUTHORIZED. Neither
this information block, the typed name of the sender, nor
anything else in this message is intended to constitute an
electronic signature unless a specific statement to the
contrary is included in this message. If you have received this
communication in error, please immediately contact me and delete
this communication from your computer. Thank you.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
CONFIDENTIALITY STATEMENT
This communication and any attachments are CONFIDENTIAL and may
be protected by one or more legal privileges. It is intended
solely for the use of the addressee identified above. If you
are not the intended recipient, any use, disclosure, copying
or distribution of this communication is UNAUTHORIZED. Neither
this information block, the typed name of the sender, nor
anything else in this message is intended to constitute an
electronic signature unless a specific statement to the
contrary is included in this message. If you have received this
communication in error, please immediately contact me and delete
this communication from your computer. Thank you.
</pre>
</blockquote>
</body>
</html>