yep- thats probably a typo. The call flow is: (1) Call comes into trunk with DNIS=1#1710. (2) Matches Translation Pattern. (3) 1# stripped. (4) Matches CTI RP 1710. To get from step (3) to step (4) logic dictates that the CSS of the Translation pattern should see the CTI RP. However the CSS of the trunk used in step (1) is the guy whose CSS needs to see the CTI RP in step (4).
Vik Malhi - CCIE #13890 Senior Technical Instructor - IPexpert, Inc. Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] Join our free online support and peer group communities: http://www.IPexpert.com/communities IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Charles Sent: Sunday, September 07, 2008 8:04 AM To: Devildoc Cc: CCIE Voice Online Study List; Christian Hennrich Subject: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC Services OK... this is prob a typo, but 1#[12]XXX would not match 1#1710... I am curious tho how/why the GK trunk is able to pass a call to 1710 without stripping the 1#... Jonathan On Sun, Sep 7, 2008 at 9:16 AM, Devildoc <[EMAIL PROTECTED]> wrote: No Jonathan, you didn't read my posts correctly. If you went back to read it again, you would see that my CSS for translation patterns DID have the pt-internal. That was why it worked when i called from BR2 phones to HQ and BR1 phones. If I didn't have the pt-internal in my CSS for translation patterns, then calling to HQ and BR1 phones would not work. As Christian mentioned in his post... calling from BR2 to HQ and BR1 phones via a GK trunk and have the trunk use the translation patterns to call the IP phones in HQ and BR1 only works if the endpoints are IP iphones. However, it does not work the same way on CTI route points for some reasons (and i think i know what the reason is - but that's a different matter). With CTI route points, the GK trunk needs direct access to the pt-internal where the CTI route points reside. So that was why i had to modify my CSS of the GK trunk to include the pt-internal. Here is my original configuration. css-gk only had pt-gk in it. css-internal had pt-support and pt-internal in it. My GK trunk had the css-gk, so it could only access any pattern in the pt-gk. My 1#.[12]XXX translation pattern belonged to the pt-gk and had css-internal, so that this pattern can only be accessed by the GK trunk and had access to the internal DNs. So when i called 1001 from BR2, the GK accepted the digits 1#1001 and passed it on to the translation pattern 1#.[12]XXX. The translation pattern stripped off the 1# and sent 1001 on to the HQ Phone1. So that worked! However, when i called 1710 (an IPCC Express ICD pilot number) from BR2, the GK trunk received the digits 1#1710 and passed it on to the translation pattern 1#.[12]XXX. The translation pattern stripped of the 1# and passed the digits 1710 on to the IPCC Express ICD pilot. The 1710 pilot rang twice and gave me a busy status with a reorder tone. Per Christian suggestion, I had to go back and modified my css-gk to include pt-internal, so now my css-gk has pt-gk and pt-internal. After the modification, the call worked. So you see, the issue was with my css of the GK trunk and not of the css of the translation pattern. JD _____ Date: Sun, 7 Sep 2008 08:45:17 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC Services CC: [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com Your words: "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." You had a CSS on the trunk to the pt-gk... which was where the translation was... so, the call came in, hit the translation and died, a CSS to pt-internal on the translation would also have fixed your problem. I presume that 4-digits worked cuz you had the pt-internal in the gk CSS as well... Jonathan On Sun, Sep 7, 2008 at 8:39 AM, Devildoc <[EMAIL PROTECTED]> wrote: 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 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC Services CC: [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] To: [EMAIL PROTECTED] Subject: Re: [OSL | CCIE_Voice] Failed GK Calls to IPCC Services CC: [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] 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%2 1550F681DAD532637%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%2 1550F681DAD532637%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/> _____ See how Windows connects the people, information, and fun that are part of your life. See <http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/> Now _____ Want to do more with Windows Live? Learn "10 hidden secrets" from Jamie. Learn Now <http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns%2 1550F681DAD532637%215295.entry?ocid=TXT_TAGLM_WL_domore_092008> _____ See how Windows Mobile brings your life together-at home, work, or on the go. See Now <http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/>
