No, it's NOT the CSS on the translation pattern. It's the CSS on the GK trunk. Now, if you don't understand the difference, then i would highly suggest that you lab it up yourself! JD
Date: Sun, 7 Sep 2008 08:31:08 -0500From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC ServicesCC: [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com So, basically what we said initially.... CSS on translation pattern...Jonathan On Sun, Sep 7, 2008 at 8:16 AM, Devildoc <[EMAIL PROTECTED]> wrote: The reason why it worked when i changed to 4 digits was because i had my GK translation patterns in their own partition called pt-gk and the internal DNs in their own partition called pt-internal. So when I configured the GK trunk to accept the 10 digits, I only gave its CSS access to pt-gk and not the pt-internal. But when i configured it to accept 4 digits, the trunk didn't need to access any GK translation patterns, and therefore, I gave it access to pt-internal directly. JD Date: Fri, 5 Sep 2008 15:27:25 -0500 From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC ServicesCC: [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com 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]: [EMAIL PROTECTED]: [EMAIL PROTECTED]: 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 DevildocGesendet: Donnerstag, 4. September 2008 23:14An: Christian HennrichCc: CCIE Voice Online Study ListBetreff: 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 ______________________________________________________________________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 See how Windows connects the people, information, and fun that are part of your life. See Now _________________________________________________________________ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008
