Wait... why would it work when you changed the number of received digits then?
Jonathan On Fri, Sep 5, 2008 at 3:25 PM, Devildoc <[EMAIL PROTECTED]> wrote: > Christian, > > Yes, you're right. I just labbed it up today and it worked! The GK trunk > must have CSS access to the partition of the CTI route points. The issue is > not the CSS of the translation pattern. It's the CSS of the GK trunk. It's > so weird that it's working that way. I wonder if there is any tool that you > can help you debug the communication to see what's going on at the lower > layers. > > Normally, i would configure the GK trunk to accept only 4 digits. However, > due to stringent requirements that mandate call routing from BR2 phones to > the HQ and BR1 PSTN area code numbers (i.e any number in 212xxxxxxx and > 617xxxxxxx) via the GK trunk, I had to configure the trunk to accept 10 > digits. If I configured only 4 significant digits, then that would break > the requirements. > > Anyway... that was an easy fix. All I had to do was... added the internal > partition to the CSS of the GK trunk, and that fixed the issue. Thank you > for you help. > > JD > > ------------------------------ > > Date: Fri, 5 Sep 2008 08:20:03 +0200 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: ccie_voice@onlinestudylist.com > Subject: AW: [OSL | CCIE_Voice] Failed GK Calls to IPCC Services > > > > 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-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 > > > ______________________________________________________________________ > > > > ------------------------------ > > 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 > ______________________________________________________________________ > > ------------------------------ > See how Windows connects the people, information, and fun that are part of > your life. See > Now<http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/> >