[cisco-voip] variable-length translation pattern
Hi all, I have two translation pattern within the same partition (cucm 9.x). They are: 1XXX 1! When an incoming call from external sip gateway comes in with called number (say) 1234, the matched translation is 1!. At first, I thought that 1!, being less specific than 1XXX, should not being matched. Reading through Cisco Collaboration System 9.x Solution Reference Network Designs (SRND) http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab09/clb09/dialplan.html, I saw this: When determining the number of matched strings for a variable-length pattern, Unified CM takes into account only the number of matched strings that are equal in length to the number of digits dialed. Assuming a user dials 1311 and we have patterns 1XXX, 1[2-3]XX, and 13!, the following table shows the number of matched strings of these potentially matching patterns*In this example the variable-length pattern 13! is selected as the best match*. Changing temporarily the translation pattern with a leading # and then going back to the original form, the pattern 1XXX started to be matched. What do you think, guys? is this a bug or are 1! and 1XXX equal-precision matches from cucm point of view? Thank you ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Call transfer CallerID issues - Cisco to non-Cisco
Is Ameyo using CTI/JTAPI to do the transfers? If so would be a setting in Ameyo. From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Henry Gicheru (KE) Sent: Tuesday, December 9, 2014 7:12 AM To: cisco-voip; cisco-voip@puck.nether.net Subject: [cisco-voip] Call transfer CallerID issues - Cisco to non-Cisco Hi Running into an issue with call transfers from Cisco extensions to Ameyo Contact center agents extensions. The Ameyo agents are seeing the Cisco extension number that did the transfer other than the original PSTN number that made the call. The integration is via Cisco CUBE, H323 on CUCM side and SIP on the Ameyo side. Please assist. Regards, Henry Gicheru System Engineer Dimension Data Tel: +25420 499 3000 Mobile: +254733477307 Fax:+254204993200 henry.gich...@dimensiondata.commailto:henry.gich...@dimensiondata.com This email and all contents are subject to the following disclaimer: http://www.dimensiondata.com/emaildisclaimer;http://www.dimensiondata.com/Global/Policies/Pages/Email-Disclaimer.aspx itevomcid ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Attendant Console User 10.5.1 can't change layout?
Thanks! From: Jeff Sandstrom [mailto:jeff.sandst...@enghouse.com] Sent: Monday, December 8, 2014 2:40 PM To: Jason Aarons (AM) Cc: cisco-voip (cisco-voip@puck.nether.net) Subject: Re: [cisco-voip] Attendant Console User 10.5.1 can't change layout? Hi Jason, Unfortunately, we don’t have a way to rearrange the different window panes in the attendant console client; however, you can show/hide the Call Park pane from the application’s View menu (View Call Park). Thanks, Jeff Sandstrom Product Manager, Cisco Unified Attendant Consoles Arc Solutions t: +1 919-392-4938 | m: +1 919-599-8782 w: www.arcsolutions.comhttp://www.arcsolutions.com/ e: jsandst...@arcsolutions.commailto:first_initial_then_lastn...@arcsolutions.com On Dec 8, 2014, at 10:32 AM, Jason Aarons (AM) jason.aar...@dimensiondata.commailto:jason.aar...@dimensiondata.com wrote: Attendant Console Advanced 10.5.1 Customer doesn’t use Call Park and would to move it around on screen or get rid of it all together. Is there a way to customize the screen layout? For example move Speed Dials F6 to the left and Call Park to the right? See attached png for screenshot from manual. http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucmac/cuaca/10_5_1/user_guide/eng/CUACA1051CUG_eng.pdf 2014-12-08_103013.png___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip itevomcid ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Call transfer CallerID issues - Cisco to non-Cisco
The calling party info should be updated after the Cisco user completes the transfer. Do you see this coming across and does Ameyo have the ability to update it's connected party info? -Ryan On Dec 9, 2014, at 8:17 AM, Henry Gicheru (KE) henry.gich...@dimensiondata.commailto:henry.gich...@dimensiondata.com wrote: Hi Jason, The issue is transfer from Cisco to Ameyo. The Ameyo agent is seeing the Cisco Extension that performed the transfer rather than the original PSTN caller ID. The setup is as below; CUCM –H323- CUBE(Voice Gateway) – SIP- Ameyo. Regards, Henry Gicheru System Engineer Dimension Data Tel: +25420 499 3000 Mobile: +254733477307 Fax:+254204993200 henry.gich...@dimensiondata.commailto:henry.gich...@dimensiondata.com From: Jason Aarons (AM) Sent: Tuesday, December 09, 2014 4:01 PM To: Henry Gicheru (KE); cisco-voip; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net Subject: RE: Call transfer CallerID issues - Cisco to non-Cisco Is Ameyo using CTI/JTAPI to do the transfers? If so would be a setting in Ameyo. From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Henry Gicheru (KE) Sent: Tuesday, December 9, 2014 7:12 AM To: cisco-voip; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net Subject: [cisco-voip] Call transfer CallerID issues - Cisco to non-Cisco Hi Running into an issue with call transfers from Cisco extensions to Ameyo Contact center agents extensions. The Ameyo agents are seeing the Cisco extension number that did the transfer other than the original PSTN number that made the call. The integration is via Cisco CUBE, H323 on CUCM side and SIP on the Ameyo side. Please assist. Regards, Henry Gicheru System Engineer Dimension Data Tel: +25420 499 3000 Mobile: +254733477307 Fax:+254204993200 henry.gich...@dimensiondata.commailto:henry.gich...@dimensiondata.com This email and all contents are subject to the following disclaimer: http://www.dimensiondata.com/emaildisclaimer;http://www.dimensiondata.com/Global/Policies/Pages/Email-Disclaimer.aspx itevomcid ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] Inventory Reports
Hi group. I'm relatively new to Cisco telephony, but not to telecom in general. I've been tasked with generating a report of all our sites with MGCP and their version numbers, phone counts/ATA's at each remote location, and call volumes (most likely minimal but who knows). We're running Cisco 7 CUCM here and was wondering if there are any canned reports, or if plodding is necessary, what those steps will be to gather this information. We realize that CUCM 7 is end of life, but that is a conversation for another day..;-) Open to any/all suggestions. Thanks, Bill Bill Paris Network Engineer Delaware North 40 Fountain Plaza Buffalo NY 14202 T 716 858 5312 M 716 936 2122 www.delawarenorth.com The information contained in this electronic mail transmission is intended only for the use of the recipient(s) named above. It may contain proprietary, confidential or privileged information of the sender. If you are not the intended recipient, you are hereby notified that any disclosure, dissemination, distribution or copying of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by reply electronic mail and delete the original message and any copy of it from your computer system. ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] variable-length translation pattern
The reference from the SRND was only to make clear the origin of my suspect. Initially I tought that 1XXX has higher priority than 1! but now, after reading the SNRD, I'm not that sure. Of course the pattern from the SRND examples are different from mine but the concept still applies imo. I was trying to receive some confirmation/denial of my suspect. 2014-12-09 17:41 GMT+01:00 Bill Talley btal...@gmail.com: Your patterns are both 1 followed by a wildcard. The SRNDs examples are NOT 1 followed by a wildcard, they are 1 followed by more specific wildcards or digits. 1! Is NOT equal to 12! Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos. On Dec 9, 2014, at 9:35 AM, daniele visaggio visaggio.dani...@gmail.com wrote: Always from the SRND: [...] This does not mean that the urgent pattern has a higher priority than other patterns; the closest-match logic described in the section on Call Routing in Unified CM still applies. For example, assume the route pattern 1XX is configured as urgent and the pattern 12! is configured as a regular route pattern. If a user dials 123, Unified CM will not make its routing decision as soon as it receives the third digit because even though 1XX is an urgent pattern, it is not the best match (10 total patterns matched by 12! versus 100 patterns matched by 1XX). Unified CM will have to wait for inter-digit timeout before routing the call because the pattern 12! allows for more digits to be input by the user. Both my translation patterns have urgent priority enabled, so this aspect should not matter. I do not understand if 1XXX has higher priority than 1! or viceversa, given 1234 as called number. 2014-12-09 16:09 GMT+01:00 Bill Talley btal...@gmail.com: I would think it will always match 1! because of the urgent priority setting. Keep in mind the example you gave from the SRND list three different translation patterns. The two you have are the same as far as the first two digits, no? Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos. On Dec 9, 2014, at 5:59 AM, daniele visaggio visaggio.dani...@gmail.com wrote: Hi all, I have two translation pattern within the same partition (cucm 9.x). They are: 1XXX 1! When an incoming call from external sip gateway comes in with called number (say) 1234, the matched translation is 1!. At first, I thought that 1!, being less specific than 1XXX, should not being matched. Reading through Cisco Collaboration System 9.x Solution Reference Network Designs (SRND) http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab09/clb09/dialplan.html, I saw this: When determining the number of matched strings for a variable-length pattern, Unified CM takes into account only the number of matched strings that are equal in length to the number of digits dialed. Assuming a user dials 1311 and we have patterns 1XXX, 1[2-3]XX, and 13!, the following table shows the number of matched strings of these potentially matching patterns*In this example the variable-length pattern 13! is selected as the best match*. Changing temporarily the translation pattern with a leading # and then going back to the original form, the pattern 1XXX started to be matched. What do you think, guys? is this a bug or are 1! and 1XXX equal-precision matches from cucm point of view? Thank you ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] variable-length translation pattern
If urgent priority wasn't involved, then the interdigital timeout would apply, thus giving you more time to dial and the system time to assess a more accurate, competing match. Since urgent priority applies here, the system will not wait to assess further digit input and there is no further comparison beyond a second digit since it automatically matches the 1! translation pattern. Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos. On Dec 9, 2014, at 10:58 AM, daniele visaggio visaggio.dani...@gmail.com wrote: The reference from the SRND was only to make clear the origin of my suspect. Initially I tought that 1XXX has higher priority than 1! but now, after reading the SNRD, I'm not that sure. Of course the pattern from the SRND examples are different from mine but the concept still applies imo. I was trying to receive some confirmation/denial of my suspect. 2014-12-09 17:41 GMT+01:00 Bill Talley btal...@gmail.com: Your patterns are both 1 followed by a wildcard. The SRNDs examples are NOT 1 followed by a wildcard, they are 1 followed by more specific wildcards or digits. 1! Is NOT equal to 12! Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos. On Dec 9, 2014, at 9:35 AM, daniele visaggio visaggio.dani...@gmail.com wrote: Always from the SRND: [...] This does not mean that the urgent pattern has a higher priority than other patterns; the closest-match logic described in the section on Call Routing in Unified CM still applies. For example, assume the route pattern 1XX is configured as urgent and the pattern 12! is configured as a regular route pattern. If a user dials 123, Unified CM will not make its routing decision as soon as it receives the third digit because even though 1XX is an urgent pattern, it is not the best match (10 total patterns matched by 12! versus 100 patterns matched by 1XX). Unified CM will have to wait for inter-digit timeout before routing the call because the pattern 12! allows for more digits to be input by the user. Both my translation patterns have urgent priority enabled, so this aspect should not matter. I do not understand if 1XXX has higher priority than 1! or viceversa, given 1234 as called number. 2014-12-09 16:09 GMT+01:00 Bill Talley btal...@gmail.com: I would think it will always match 1! because of the urgent priority setting. Keep in mind the example you gave from the SRND list three different translation patterns. The two you have are the same as far as the first two digits, no? Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos. On Dec 9, 2014, at 5:59 AM, daniele visaggio visaggio.dani...@gmail.com wrote: Hi all, I have two translation pattern within the same partition (cucm 9.x). They are: 1XXX 1! When an incoming call from external sip gateway comes in with called number (say) 1234, the matched translation is 1!. At first, I thought that 1!, being less specific than 1XXX, should not being matched. Reading through Cisco Collaboration System 9.x Solution Reference Network Designs (SRND), I saw this: When determining the number of matched strings for a variable-length pattern, Unified CM takes into account only the number of matched strings that are equal in length to the number of digits dialed. Assuming a user dials 1311 and we have patterns 1XXX, 1[2-3]XX, and 13!, the following table shows the number of matched strings of these potentially matching patternsIn this example the variable-length pattern 13! is selected as the best match. Changing temporarily the translation pattern with a leading # and then going back to the original form, the pattern 1XXX started to be matched. What do you think, guys? is this a bug or are 1! and 1XXX equal-precision matches from cucm point of view? Thank you ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] variable-length translation pattern
Doh, sorry. ! Is variable length. I was thinking single digit Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos. On Dec 9, 2014, at 10:58 AM, daniele visaggio visaggio.dani...@gmail.com wrote: The reference from the SRND was only to make clear the origin of my suspect. Initially I tought that 1XXX has higher priority than 1! but now, after reading the SNRD, I'm not that sure. Of course the pattern from the SRND examples are different from mine but the concept still applies imo. I was trying to receive some confirmation/denial of my suspect. 2014-12-09 17:41 GMT+01:00 Bill Talley btal...@gmail.com: Your patterns are both 1 followed by a wildcard. The SRNDs examples are NOT 1 followed by a wildcard, they are 1 followed by more specific wildcards or digits. 1! Is NOT equal to 12! Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos. On Dec 9, 2014, at 9:35 AM, daniele visaggio visaggio.dani...@gmail.com wrote: Always from the SRND: [...] This does not mean that the urgent pattern has a higher priority than other patterns; the closest-match logic described in the section on Call Routing in Unified CM still applies. For example, assume the route pattern 1XX is configured as urgent and the pattern 12! is configured as a regular route pattern. If a user dials 123, Unified CM will not make its routing decision as soon as it receives the third digit because even though 1XX is an urgent pattern, it is not the best match (10 total patterns matched by 12! versus 100 patterns matched by 1XX). Unified CM will have to wait for inter-digit timeout before routing the call because the pattern 12! allows for more digits to be input by the user. Both my translation patterns have urgent priority enabled, so this aspect should not matter. I do not understand if 1XXX has higher priority than 1! or viceversa, given 1234 as called number. 2014-12-09 16:09 GMT+01:00 Bill Talley btal...@gmail.com: I would think it will always match 1! because of the urgent priority setting. Keep in mind the example you gave from the SRND list three different translation patterns. The two you have are the same as far as the first two digits, no? Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos. On Dec 9, 2014, at 5:59 AM, daniele visaggio visaggio.dani...@gmail.com wrote: Hi all, I have two translation pattern within the same partition (cucm 9.x). They are: 1XXX 1! When an incoming call from external sip gateway comes in with called number (say) 1234, the matched translation is 1!. At first, I thought that 1!, being less specific than 1XXX, should not being matched. Reading through Cisco Collaboration System 9.x Solution Reference Network Designs (SRND), I saw this: When determining the number of matched strings for a variable-length pattern, Unified CM takes into account only the number of matched strings that are equal in length to the number of digits dialed. Assuming a user dials 1311 and we have patterns 1XXX, 1[2-3]XX, and 13!, the following table shows the number of matched strings of these potentially matching patternsIn this example the variable-length pattern 13! is selected as the best match. Changing temporarily the translation pattern with a leading # and then going back to the original form, the pattern 1XXX started to be matched. What do you think, guys? is this a bug or are 1! and 1XXX equal-precision matches from cucm point of view? Thank you ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Attendant Console User 10.5.1 can't change layout?
I had a customer that had bought CUEAC back on version 8.x a few years ago and complained about this very thing. When I spoke to Arc about it, they told me that they researched and the layout was the best you could have and there was no reason to customize it. The customer switched to a 3rd party when smartnet came up and have been happier. They switched to Vistapoint. I have other customers that really like Akkadian Labs (used to be Fidelus). Good luck. On Tue, Dec 9, 2014 at 6:02 AM, Jason Aarons (AM) jason.aar...@dimensiondata.com wrote: Thanks! *From:* Jeff Sandstrom [mailto:jeff.sandst...@enghouse.com] *Sent:* Monday, December 8, 2014 2:40 PM *To:* Jason Aarons (AM) *Cc:* cisco-voip (cisco-voip@puck.nether.net) *Subject:* Re: [cisco-voip] Attendant Console User 10.5.1 can't change layout? Hi Jason, Unfortunately, we don’t have a way to rearrange the different window panes in the attendant console client; however, you can show/hide the Call Park pane from the application’s View menu (View Call Park). Thanks, *Jeff Sandstrom* Product Manager, Cisco Unified Attendant Consoles *Arc Solutions* t: +1 919-392-4938 | m: +1 919-599-8782 w: www.arcsolutions.com e: jsandst...@arcsolutions.com first_initial_then_lastn...@arcsolutions.com On Dec 8, 2014, at 10:32 AM, Jason Aarons (AM) jason.aar...@dimensiondata.com wrote: Attendant Console Advanced 10.5.1 Customer doesn’t use Call Park and would to move it around on screen or get rid of it all together. Is there a way to customize the screen layout? For example move Speed Dials F6 to the left and Call Park to the right? See attached png for screenshot from manual. http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucmac/cuaca/10_5_1/user_guide/eng/CUACA1051CUG_eng.pdf ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
