Yes the CTI Ports need to be directly reachable by the Gateway CSS, without invoking the css of the translation pattern. You can use the translation pattern, but then use simply a css which is the same for the gateway and the translation pattern.
Hopefully Vik or Marc could explain, why this is special for CTI Ports and. Cheers Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Devildoc Gesendet: Donnerstag, 4. September 2008 23:14 An: Christian Hennrich Cc: CCIE Voice Online Study List Betreff: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC Services Christian, So you are saying that if the CSS of the GK-controlled trunk does not have access to the CTI ports partition, then the call would fail? That makes sense because my GK-controlled trunk only has access to the GK partition which the translation patterns belong to. The translation patterns have CSS that could access the internal partition which the CTI ports belong. So in this scenario, my trunk uses the translation pattern as the middle man to reach the CTI ports which the trunk does not have direct access to. I'll lab it up tomorrow to reconfigure my trunk to have access to the internal partition and see if that resolve the issue. Thanks for help. JD > Date: Thu, 4 Sep 2008 21:48:03 +0200 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: ccie_voice@onlinestudylist.com > Subject: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC Services > > 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-c ns%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 > > ______________________________________________________________________ > ________________________________ 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-c ns!550F681DAD532637!5295.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 ______________________________________________________________________
