Re: [cisco-voip] Adding area code to local calls and digit manipulation at route list/route pattern level

2021-05-21 Thread Michael Nickolich
We had an issue with one of our clusters where we were not sending the
proper ELIN from CER to the ITSP, so the PSAP was receiving the incorrect
information. Turns out that CER was modifying the ANI to the proper ELIN,
but we had a Calling Party Transformation CSS setup on the SIP trunk for
Outgoing Calls in CUCM. That caused the Original DN not the CER modified
ANI to alway be sent to the ITSP. Our Transformation pattern \+1.XX
was causing the original DN to be sent out under invite from CUCM. WE
needed to make changes in CUCM or CUBE accordingly. I removed our
CSS_CPN_Lumos drop-down from the Calling Party Transformation CSS on the
SIP Trunk. Then checked, Use Device Pool Calling Party Transformation CSS.
Then reset the trunk and wait for it to register. Then our test 911 calls
showed the correct ELIN and not the original DN.

++ So we had 3 options to correct this issue:

**change the directory number so that it doesn't match the pattern
**Remove the transformation from the trunk
**Delete the pattern  \+1.XX

We removed the transformation from the trunk.

Transformation patterns configured on the device selected to route the call
(or on that device’s device pool) take precedence over calling and called
party transformations configured in the route pattern and/or route list. If
a transformation calling search space (CSS) is configured on the device
selected to route the call (or on that device’s device pool),
then transformations configured in the route pattern or route list are
considered only if no match is found using the
respective transformation CSS. The input to the transformation CSS always
is the untransformed number before applying route pattern or route
list transformations. Refer to
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/dialplan.html#63188

On Fri, May 21, 2021 at 3:04 PM Raffi Rodrigo  wrote:

> algue tem sala pra disca numeros pra ganha dinheiro?
>
> Em sex., 21 de mai. de 2021 às 15:59, Dave Wolgast 
> escreveu:
>
>> My question was about:
>>  • Calling Party Mask = XX
>>
>> You said further down that you were sending  01509XX but it wasn't
>> being reflected in DNA. It seems to me that it may be getting overwritten
>> someplace downstream. I don't think DNA would have just inserted XX
>> by itself.
>>
>> Can you confirm from the SIP trace (either Real Time from RTMT or 'debug
>> ccsip messages' on the CUBE) that you are actually sending the right
>> 01509XX information?
>>
>> Dave Wolgast
>> Geneseo, NY
>>
>>
>> On Fri, May 21, 2021 at 8:59 AM Gary Parker 
>> wrote:
>>
>>> Afternoon all, I’ve got a problem I’ve been struggling with for a few
>>> days now. It’s bound to be something simple I’ve forgotten from my CCNA
>>> Voice days (a long time ago!).
>>>
>>> I’m running CUCM 12.5 SU4 with GBNP 1.1(31) and 2921 voice gateways
>>> operating as CUBE with IOS 15.5(3)M2 in the UK
>>>
>>> Background:
>>> I’m in the process of migrating our outbound PSTN dialling from our
>>> Virgin Media Business PRI circuits to SIP trunks provided by Gamma. The
>>> problem I’ve encountered is with local rate calls with no area code. Our
>>> PRIs will happily route outbound six digit dialled numbers but the SIP
>>> trunks will not. I suspect this is a common problem, and will only become
>>> more common in the UK as Ofcom removes the obligation on TSPs to provide
>>> local dialling:
>>>
>>>
>>> https://www.ispreview.co.uk/index.php/2021/04/ofcom-will-stop-requiring-uk-phone-providers-to-offer-local-dialling.html
>>>
>>> Problem:
>>> I though this would be a relatively simple task of adding Prefix Digits
>>> (Outgoing Calls) of my area code (01509) to all calls matching the LOCAL
>>> route filter using a Route Pattern. At first glance, Dialled Number
>>> Analyzer shows that Dialled Digits of eg. 9112233 gets transformed to
>>> Called Party Number of 01509112233
>>>
>>> • Results Summary
>>> • Calling Party Information
>>> • Dialed Digits = 9112233
>>> • Match Result = RouteThisPattern
>>> • Matched Pattern Information
>>> • Called Party Number = 01509112233
>>> • Time Zone = Etc/GMT
>>> • End Device = Lboro_SIP_Test
>>> • Call Classification = OffNet
>>> • InterDigit Timeout = NO
>>> • Device Override = Disabled
>>> • Outside Dial Tone = NO
>>> • Call Flow
>>> • Alternate Matches
>>>
>>> However calls via the SIP TSP fail with a 404 as the dialled number is
>>> still “123456” when I look at debug on the voice gateway.
>>>
>>> Looking more closely at the DNA output it appears that the
>>> post-transform Called Number at the Route Pattern level isn’t being passed
>>> to the Route List:
>>>
>>>
>>> • Call Flow
>>> • Route Pattern :Pattern= 9.@
>>> • Positional Match List =
>>>

Re: [cisco-voip] moving jabber client between clusters for support?

2021-04-28 Thread Michael Nickolich
Nick,

This is what I have done to register between test and prod clusters for
J4W. I reset my Jabber client and then kill off that process.

Browse to C:\ProgramData\Cisco Systems\Cisco Jabber. Use Notepad++ or some
other editor.

Example Bootstrap

You can modify the file, but each position is designated for a particular
parameter -- upnDiscoveryEnabled is the 30th position and can only be added
at that position. The parameters and values are case sensitive as well.
You'll want to set position 17 (ServicesDomain) and 18
(VoiceServicesDomain) to NOT_SPECIFIED. When you do Notepad++ will tell you
that you have to be an Administrator, so say yes and repeat those steps and
save that file. Once those settings are blanked out, you can open Jabber.
Go into Advanced Settings and set Cisco Communications Manager 9 or later
and Use the following server to the CCM/TFTP of the cluster in question.
Then typical user setup with home cluster checked. It has been a while, but
that is how I believe I jumped to our test cluster. Then when you are done
testing and want to set the config back just put ServicesDomain:
yourdomain.com to position 17 and VoiceServicesDomain: yourdomain.com to
position 18.

NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
Forgot_Password_URL: https://Forgotlogin.com
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
ServicesDomain: yourdomain.com
VoiceServicesDomain: yourdomain.com
ServiceDiscoveryExcludedServices: WEBEX,CUP
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
upnDiscoveryEnabled: false
Meetings_Enabled: True
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
UpdateUrl: http://updateURL.com
EnableDPIAware: TRUE
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
NOT_SPECIFIED
Location_Mode: ENABLEDNOPROMPT
NOT_SPECIFIED

Thanks,
Mike

On Wed, Apr 28, 2021 at 1:10 PM Lelio Fulgenzi  wrote:

> A different user is another good idea.
>
>
>
> Be careful with the bootstrap file though. You will need
>
>
>
> upnDiscoveryEnabled: FALSE
>
>
>
> and you can only change this by deleting the directories (I think)
> C:\ProgramData\Cisco Systems\Cisco Jabber
>
>
>
> or by re-installing with a CLEAR=1 and the UPN_DISCOVERY_ENABLED=false
>
>
>
> It’s enabled by default.
>
>
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *UC
> Penguin
> *Sent:* Wednesday, April 28, 2021 12:55 PM
> *Cc:* cisco-voip 
> *Subject:* Re: [cisco-voip] moving jabber client between clusters for
> support?
>
>
>
> *CAUTION:* This email originated from outside of the University of
> Guelph. Do not click links or open attachments unless you recognize the
> sender and know the content is safe. If in doubt, forward suspicious emails
> to ith...@uoguelph.ca
>
>
>
> Creating a uniquely named user account marked as home cluster on each
> cluster would appear to be the simplest. This assumes you have ILS setup
> between all clusters and you don’t have a large number of clusters that
> would chew through licensing.
>
>
>
> On Apr 28, 2021, at 11:03, Nick Barnett  wrote:
>
> 
>
> Thanks, let me try and clarify a bit.
>
>
>
> We have a support team that needs to log their Jabber device into multiple
> clusters. Using the "home cluster" setting is too cumbersome and requires
> CUCM access. Our testers do not have CUCM access, but they can modify their
> own local config files.
>
>
>
> Ultimately, I'm looking for a bootstrap hack, or some other way, to
> MANUALLY and / or STATICALLY define which cluster the Jabber client
> registers with.
>
>
>
> This is purely for our support group with CUCM access and our testing team
> without CUCM access. No real end users need to use this feature... but
> security is taking away our CIPC and I need to have another way for them to
> jump between prod clusters...
>
>
>
> Additionally, I personally have to jump between prod and non-prod, so i
> want this fix for me as well.
>
>
>
> Ideally, there is something local that a tech can do to their jabber
> config file, bootstrap, or registry that will make their jabber register to
> a specific cluster instead of using UPN discovery.  Granted, some of the
> installation switches seem to fundamentally change how jabber is installed
> (imagine that!)... so another requirement would be NOT HAVING TO uninstall
> and reinstall with different switches. (If in the end, the support team
> MUST be configured to never use UPN, that's fine, i just want to know the
> best way).
>
>
>
> Does that make it any clearer? I'm just looking for an easy way to hop
> between clusters without discovery to replace CIPC.
>
>
>
> Thanks!
>
>
>
> On Wed, Apr 28, 2021, at 9:26 AM, Lelio Fulgenzi wrote:
>
> I may not understand exactly what you’re trying to do, but, I think that
> will come out during discussion.
>
>
>
> I have a production cluster and a development 

Re: [cisco-voip] CUM 11.5 report question

2021-04-21 Thread Michael Nickolich
James, I'm not sure if this helps, but this gentleman has steps on getting
the active load ID for all devices on your system. I think what you are
wanting starts at step 7 and will require you to run it on each CCM node.
Then sort the spreadsheet by device names TCT, CSF, and BOT.

https://profcollab.wordpress.com/2016/01/16/cisco-jabber-update-11-5/

On Wed, Apr 21, 2021 at 3:57 PM Lelio Fulgenzi  wrote:

> If you haven’t setup Jabber analytics on control hub, it takes a
> jabber-config.xml change (and reload) and then waiting two days.
>
>
>
> *From:* James Dust 
> *Sent:* Wednesday, April 21, 2021 3:53 PM
> *To:* Lelio Fulgenzi ; cisco-voip@puck.nether.net
> *Subject:* RE: CUM 11.5 report question
>
>
>
> *CAUTION:* This email originated from outside of the University of
> Guelph. Do not click links or open attachments unless you recognize the
> sender and know the content is safe. If in doubt, forward suspicious emails
> to ith...@uoguelph.ca
>
>
>
> Very kind thank you Lelio,
>
>
>
> Kind regards
>
>
>
> James
>
>
>
> Sent with BlackBerry Work
> (www.blackberry.com)
>
>
>
> *From: *Lelio Fulgenzi 
>
> *Date: *Wednesday, 21 Apr 2021, 8:52 pm
>
> *To: *James Dust ,
> cisco-voip@puck.nether.net 
>
> *Subject: *RE: CUM 11.5 report question
>
>
>
> This message originates from outside Charles Stanley. Please do not click
> links or open attachments unless you know the sender and are confident the
> content is safe.
>
> Hey James,
>
>
>
> I do this a couple of ways. First, I use Jabber analytics on Control Hub.
> This gives a good view. But, I think the metrics might be skewed.
>
>
>
> The other way is through RTMT. You can search for Jabber devices, i.e.
> CSF, TCT, etc and choose registered or not registered, then, sort by
> version.
>
>
>
> Unfortunately there is no export from the RTMT tool, but, it should give
> you what you need.
>
>
>
> Lelio
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *James
> Dust
> *Sent:* Wednesday, April 21, 2021 3:16 PM
> *To:* cisco-voip@puck.nether.net
> *Subject:* [cisco-voip] CUM 11.5 report question
>
>
>
> *CAUTION:* This email originated from outside of the University of
> Guelph. Do not click links or open attachments unless you recognize the
> sender and know the content is safe. If in doubt, forward suspicious emails
> to ith...@uoguelph.ca
>
>
>
> Good evening all,
>
>
>
> Does anyone know if there is a  way to run a report, on the active load ID
> of a TCT, CSF or BOT profile on cucm.
>
>
>
> I need to carry out an audit, to see if any staff members are still using
> Cisco Jabber.
>
>
>
> Many thanks
>
>
>
> James
>
>
> *Consider the environment - Think before you print*
>
> The contents of this email are confidential to the intended recipient and
> may not be disclosed. Although it is believed that this email and any
> attachments are virus free, it is the responsibility of the recipient to
> confirm this.
>
> You are advised that urgent, time-sensitive communications should not be
> sent by email. We hereby give you notice that a delivery receipt does not
> constitute acknowledgement or receipt by the intended recipient(s).
>
> Details of Charles Stanley group companies and their regulators (where
> applicable), can be found at this URL
> http://www.charles-stanley.co.uk/contact-us/disclosure/
>
>
> *Consider the environment - Think before you print*
>
> The contents of this email are confidential to the intended recipient and
> may not be disclosed. Although it is believed that this email and any
> attachments are virus free, it is the responsibility of the recipient to
> confirm this.
>
> You are advised that urgent, time-sensitive communications should not be
> sent by email. We hereby give you notice that a delivery receipt does not
> constitute acknowledgement or receipt by the intended recipient(s).
>
> Details of Charles Stanley group companies and their regulators (where
> applicable), can be found at this URL
> http://www.charles-stanley.co.uk/contact-us/disclosure/
> ___
> 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] UCCX 11.6 HA LAN to WAN

2019-09-03 Thread Michael Nickolich
Thank you guys for all your feedback! This exactly what we were looking for
with this move.Based on the responses, we'll need to do the HA WAN and new
hostname. Current config has the device pool as UCCX_ABC, so the agents
would eventually fail-over to CUCM Sub C in DC2. CUCM Sub A and B, as well
as CUCM Pub are in DC1 and will be down for a majority of the day as they
upgrade power in DC1. Honestly, not sure that I prefer that they have to
prefer CUCM Sub in DC2, but I was worried about the agents ability to
authenticate with their local end user accounts.

Could we just keep HA LAN and update the UCCX Unified CM Configuration to
include Sub C in DC2? Current AXL Service Providers only list the CUCM Pub,
and JTAPI and RmCm both have CUCM Sub A and B in DC1. Could I just add Sub
C as a secondary AXL Service Provider and then swap out one of the Subs
listed in DC1 to Sub C in DC2 for both JTAPI and RmCm?


On Fri, Aug 30, 2019 at 1:19 PM Brian Meade  wrote:

> Yea, I think the process would work fine with new hostname.  I'm wondering
> if deleting a sub and re-adding/rebuilding with same hostname as WAN causes
> some issues which needed that cleanup script.
>
> On Fri, Aug 30, 2019 at 11:06 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> You can't convert the model from LAN to WAN, per se.  You basically just
>> destroy your HA by deleting the Sub from the Pub GUI.  Then delete your Sub
>> VM.  Then, you rebuild the whole Sub integration from scratch, as if it was
>> new.
>>
>> On Fri, Aug 30, 2019 at 9:55 AM Brian Meade  wrote:
>>
>>> HA over WAN allows each server to have different configurations for the
>>> Unified CM connection as well as your call control groups.  So you could
>>> have the subscriber connect to a local CUCM subscriber and have different
>>> device pools for those CTI groups to use that local subscriber as well.
>>>
>>> I've definitely seen some bugs with HA over WAN in older versions but it
>>> should be pretty stable now.
>>>
>>> I've never tried to convert an existing subscriber from LAN to WAN.
>>> There may indeed be some database references that don't get fully cleaned
>>> up when deleting the subscriber from the publisher.  You would probably
>>> have better luck using a different hostname for the new subscriber.
>>>
>>> On Fri, Aug 30, 2019 at 10:45 AM Michael Nickolich <
>>> michael.nickol...@gmail.com> wrote:
>>>
>>>> Hello all,
>>>>
>>>> We are looking to geographical separate our HA UCCX 11.6.1 nodes, which
>>>> are currently in "data center 1". We will be installing the UCCX Sub at our
>>>> other data center across campus, which is connected by 10Gb fiber. "Data
>>>> Center 2" already has two UCM Subscribers and this is where the UCCX Sub
>>>> will reside. My question is when we install the new Sub, will we select HA
>>>> over LAN or HA over WAN? TAC said it needs to be HA over WAN as the Pub and
>>>> Sub will be on different networks. TAC also said they would need to have
>>>> root access to delete the Sub from the Pub and delete any traces of the old
>>>> Sub. Then add the Sub back to the Pub. The documentation does not mention
>>>> anything about contacting TAC to gain root access for Switching Network
>>>> Deployment from LAN to WAN. Just wondering if their documentation needs
>>>> updated or if the TAC engineer misspoke.
>>>>
>>>> We will be keeping the same hostname for the server. Going to have our
>>>> Sys Admins to lower the TTL on the original record prior to making these
>>>> changes. Once we remove the Sub, have the Sys Admin update the A and PTR
>>>> record to point to the new IP and set TTL back to the default. Then verify
>>>> DNS resolution to the new IP.
>>>> Then install the new UCCX Sub. Still not sure HA over LAN or WAN.
>>>> Then update AXL, JTAPI, and RmCM to include one UCM Sub from data
>>>> center 2 in case there is a total outage in data center 1. Currently AXL
>>>> only has the UCM Pub.
>>>>
>>>> Any guidance on any gotchas would be greatly appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> ___
>>>> 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


[cisco-voip] UCCX 11.6 HA LAN to WAN

2019-08-30 Thread Michael Nickolich
Hello all,

We are looking to geographical separate our HA UCCX 11.6.1 nodes, which are
currently in "data center 1". We will be installing the UCCX Sub at our
other data center across campus, which is connected by 10Gb fiber. "Data
Center 2" already has two UCM Subscribers and this is where the UCCX Sub
will reside. My question is when we install the new Sub, will we select HA
over LAN or HA over WAN? TAC said it needs to be HA over WAN as the Pub and
Sub will be on different networks. TAC also said they would need to have
root access to delete the Sub from the Pub and delete any traces of the old
Sub. Then add the Sub back to the Pub. The documentation does not mention
anything about contacting TAC to gain root access for Switching Network
Deployment from LAN to WAN. Just wondering if their documentation needs
updated or if the TAC engineer misspoke.

We will be keeping the same hostname for the server. Going to have our Sys
Admins to lower the TTL on the original record prior to making these
changes. Once we remove the Sub, have the Sys Admin update the A and PTR
record to point to the new IP and set TTL back to the default. Then verify
DNS resolution to the new IP.
Then install the new UCCX Sub. Still not sure HA over LAN or WAN.
Then update AXL, JTAPI, and RmCM to include one UCM Sub from data center 2
in case there is a total outage in data center 1. Currently AXL only has
the UCM Pub.

Any guidance on any gotchas would be greatly appreciated.

Thanks,
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip