Hi JD,
Jonathan is correct, it works for normal phones, but for CTI ports, this
is special. cti ports need to be in the gateway cti ports.
I do not why, but cti ports are not reachable, if they reside only in
the css which the translation patterns uses, but not in the gateway css.
I had this often before on customer installations. This also happens
whit CUE CTI Ports. That is the reason why I also prefer and advise to
use the significant digits and the prefix on the gateway.
Cheers
Devildoc schrieb:
CSS is not the problem here. All of my CTI ports belong to the same
internal partition as with the rest of my phone extensions, and I
could make calls from BR2 to HQ phones via the same GK trunk without
any issue. Calls from BR2 to any extension, route pattern or
translation pattern in HQ and BR1 worked through the GK trunk, except
for these IPCC services DNs.
If you have an opportunity to lab it next time, then please do and see
if you have the same problem that i have.
JD
------------------------------------------------------------------------
Date: Thu, 4 Sep 2008 10:56:13 -0500
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC Services
CC: ccie_voice@onlinestudylist.com
OK, let's do this in sequence.
First off, since you are accepting 10-digits, that means basically all
of em (cuz you are actually sending only 6 in this instance).
So, the problem must be the translation pattern.
Do you have a specific CSS on the trunk for inbound, which can see the
translation pattern? I presume you do.
First thing to check is the CSS of the translation pattern, can it see
both the CTI RP AND the CTI Ports (as the call will hit the CTI RP and
then get transferred to the CTI Port).
The problem with your solution is that you will break many other
components (Teho, etc...)
Jonathan
On Thu, Sep 4, 2008 at 9:35 AM, Devildoc <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hello,
For some reasons, calls from BR2 into IPCC Express services (i.e.
AA and ICD) located in HQ failed via the GK-controlled trunk if
the trunk is configured to accept 10 digits for incoming and use
the translation pattern with predot to discard the extra digit and
deliver only 4 digits to the IPCC Express services trigger
number. The IPCC Express service trigger number would ring twice
before giving me a busy status and a reorder tone. However, if
the trunk is configured to accept only 4 incoming digits, then the
call goes through successfully. All configuration stays the
same. The only difference is the number of incoming digits
accepted by the GK trunk.
For example, I configured IPCC Express service ICD with the
trigger number of 1710. I also configured a GK and a
GK-controlled trunk. The trunk was configured to accept 10
incoming digits. I also had a translation pattern of 1#.[12]xxx
with a discard predot. From BR2, I made a call to 1710 with a
tech-prefix of 1#. The call got routed to the GK trunk which
accepted all digits including the 1#. It then passed the 1#1710
pattern to the translation pattern, which in turn stripped of the
1# and forwarded 1710 to the ICD trigger DN. The 1710 DN rang
twice and then it stopped, and i got a busy status on my BR2 phone
and a reorder tone. If I configured the GK trunk to accept only 4
incoming digits and not using the translation pattern, then the
call went through successfully without any issue.
I was just wondering if i am the only one who has experienced this
issue. Has anyone come across this issue before? Is this a bug
or did i miss something in my configuration? Any help is greatly
appreciated. Thanks.
JD
------------------------------------------------------------------------
Stay up to date on your PC, the Web, and your mobile phone with
Windows Live. See Now
<http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/>
------------------------------------------------------------------------
Get more out of the Web. Learn 10 hidden secrets of Windows Live.
Learn Now
<http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns%21550F681DAD532637%215295.entry?ocid=TXT_TAGLM_WL_getmore_092008>
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
