Well, then it may be a transcoder... but I am willing to bet it is assigned to both the trunk and the ports...
Jonathan On Thu, Sep 4, 2008 at 12:04 PM, Devildoc <[EMAIL PROTECTED]> wrote: > 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]> 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> >
