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/> >
