Re: [cisco-voip] Webex contact center agent transfer issue

[Anthony Holloway]

I see some people talking about it in a Webex space, and it sounds like: if
the transfer is completed on the telephone, then this happens, so instruct
the Agent to complete the transfer within the Agent desktop instead.

On Wed, Dec 7, 2022 at 3:02 PM SK  wrote:

> We are experiencing an issue with Webex contact center agent , once the
> agent transfers the call to any other user ( non contact center user ) the
> agent state still shows engaged until that call is fully handled by the
> recipient and is only able to receive calls once that call is complete .
> Has anyone experienced this issue before? Any pointers will be appreciated.
>
> 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

Re: [cisco-voip] Scripting best practice - xml read

[Anthony Holloway]

Hi Fred,

I'm a little confused by your question, as getting CSQ status should not be
XML based.

Let's start with: What platform are you using?  E.g., UCCX?


On Fri, Oct 15, 2021 at 10:29 AM f...@browardcommunications.com <
f...@browardcommunications.com> wrote:

> Greetings!
>
> Does anyone know best practice for doing a xml read to get a csq status?
> We’re already doing the typical holiday check subflow, so I wanted to
> avoid firing off another script just to do a xml read, I would like to keep
> the xml read within the main script.
>
> Any thoughts?
>
> TIA.
>
> Sent from my iPhone
> ___
> 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] CUCM PLAR SIP 8851

[Anthony Holloway]

It's been a while for me, but I think you need both: blank xlate and sip
dial rule.  Contrast this with a sccp phone, which only needs the xlate.

Did you do both, or just one and then the other?

On Fri, Jul 2, 2021 at 5:49 AM Abbas Wali  wrote:

> having issues with config. PLAR for a SIP 8851 phone. tried the blank Part
> didnt work, tried the SIP dial rules with button or blank Pattern still the
> same. any help?
>
> thank you
>
> --*AW*
> ___
> 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] CCX Selected Resource User ID showing as Stars

[Anthony Holloway]

Interesting!  I just tried something like this in 12.5(1) and I get the
same thing as you.

I did achieve the desired outcome using the Get User Info step instead of
casting the User object to a String,

*cleanAgentID = Get User Info (selectedResource, Identifier)*

On Tue, Jun 15, 2021 at 2:02 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> We collect the name of the agent for recording to our ticketing system.
>
>
>
> Apparently no one has used this piece of  data in a long time, but I
> noticed it today. All agents are showing up as “***”
>
>
>
> CCX 12.5
>
>
>
> Here is what the script does:
>
>
>
> And the values I got in my debug:
>
>
>
>
>
>
>
> What is going on here? Do I need to change how I capture this?
>
> Matthew Loraditch​
> Sr. Network Engineer
> (He/Him/His)
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] 
> [image: Facebook] 
> [image: Twitter] 
> [image: LinkedIn] 
> ___
> 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] Create 8bit 8khz mono ulaw TTS prompts

[Anthony Holloway]

https://www.ciscoprompts.com/?tts_voice=en-US-Wavenet-A&tts_text=Ray%2C+you+are+a+scholar+and+a+saint%21#

On Thu, Jun 3, 2021 at 7:05 PM Ray Maslanka  wrote:

> I created this little app some time ago partially as an experiment but
> later ended up using it to power through a deployment at a required
> breakneck pace.  Seemed to work fine.
>
> Looking at the logs today it seems it's actually been found and being used
> occasionally by the public.
>
> As a thanks to this always helpful group, feel free to use my site to
> generate 8bit 8khz uLaw WAV files from text.
>
> https://www.ciscoprompts.com
>
> It's free to use.
> There's no sign up required.
> I'm not tracking you and / or reselling info.
>
> Just hoping it helps.
>
> Thanks everyone.
>
>
>
>
> ___
> 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] Unity SMTP Domain Change

[Anthony Holloway]

Just my two cents on this: if "unitya" is the hostname name of the 11.5
system, and "unityb" is the hostname of the 12.5 system, I would not use
"unitya" on 12.5.  That's just a "typo" waiting to be corrected by someone,
which then would break things.

So, while you can change the domain to be anything you want on the 12.5
system, to include "unitya", I would shy away from it, from a cleanliness
of data/configuration standpoint.

That's just me.  But, if you have no other choice, because the alternative
is too expensive or complicated, then you gotta do what you gotta do.

For future reference, as long as you're not networked to another CUC
system, just change the 12.5 to something even more generic (e.g.,
"voicemail.domain.local") which might help with this kind of thing in the
future (e.g., v14).

On Wed, Jan 27, 2021 at 11:23 AM Riley, Sean 
wrote:

> We are migrating to a new Unity Connection cluster, from an existing Unity
> Connection cluster.  My question is around changing the SMTP Domain on the
> new UCxN to match the existing UCxN cluster.  The reason behind this is
> that we have some automation for other external services written around the
> “username@unityA.domain.local” and we have an Exchange email address
> policy to build an smtp alias for “username@unityA.domain.local” to mask
> the Unity smtp domain.
>
>
>
> Once we migrate users to the new UCxN they will now be
> “username@unityB.domain.local”.  My thought was I could keep from making
>  changes to the external services and avoid creating another Exchange email
> alias by changing the SMTP domain on the new UCxN cluster to
> UnityA.domain.local.
>
>
>
> Thoughts on this or am I creating more work than just keeping the SMTP
> domain as FQDN of the publisher and updating my external services
> referencing the old domain?
>
>
>
> Current UCxN v 11.5
>
> New UCxN v 12.5
>
>
>
> 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

Re: [cisco-voip] Our benefactor -Jared Mauch

[Anthony Holloway]

Get to know Jared: https://puck.nether.net/~jared/

On Wed, Jan 13, 2021 at 7:58 PM Lelio Fulgenzi  wrote:

>
> For those of you that don’t know, Jared Mauch runs the list.
>
> There are stories of people who run their own fibre, but this time, it’s
> true! ;)
>
>
> https://arstechnica.com/information-technology/2021/01/jared-mauch-didnt-have-good-broadband-so-he-built-his-own-fiber-isp/
>
> Sent from my iPhone
> ___
> 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] CUCM call set up issue after migration

[Anthony Holloway]

Nice! That was easy.  This email chain goes into my folder called: When
Someone Says Only Windows Servers Need Reboots.

On Tue, Jan 12, 2021 at 7:40 PM Riley, Sean 
wrote:

> So far it seems the reboot resolved this problem.  Thanks for all the
> replies with guidance and help.
>
>
>
> *From:* Kent Roberts 
> *Sent:* Tuesday, January 12, 2021 4:42 PM
> *To:* Riley, Sean 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] CUCM call set up issue after migration
>
>
>
> Ah split brains. Gotta love it.   Did you restart the ones that did not
> move?I have seen this when things go stupid. The sync usually isn’t the
> problem it’s the real-time communication between the nodes that’s all
> messed up. Usually can fix with a node reboot or restarting the cucm
> and cti services.   Course their maybe more to it but if things are in sync
>  should not be hard to fix
>
>
>
> Kent
>
>
>
> On Jan 12, 2021, at 14:06, Riley, Sean 
> wrote:
>
> 
>
> This past weekend we migrated 2 CUCM servers to a new datacenter.  This
> involved changing the IP address on these 2 CUCM nodes.  These 2 nodes
> consist of the Publisher and 1 Subscriber.  We have another Sub at a remote
> datacenter that was not touched this past weekend.
>
>
>
> Node configuration:
>
>
>
> DC A
>
> CM1: Pub which was re-ip’d
>
> CM2: Sub which was re-ip’d
>
>
>
> DC B:
>
> CM3: Sub at remote site that was not changed
>
>
>
> Phones are at many sites, but issue is independent of the phone type,
> phone location or subnet.  Also, Expressway phones have the same issue.
>
>
>
> The issue is any phone that is registered to CM3 cannot call phones
> registered to CM1 or CM2 and vice versa.  The phones do not see the call
> coming in.  If SNR is configured, the call will ring to the remote
> destination. Phones registered to CM3 can make outbound PSTN calls without
> issue, but not receive inbound from PSTN (probably because the gateway is
> handing off to CM1 or CM2).  While the gateways are not unique to the
> issue, they are running H323.
>
>
>
> If the phones are both registered to CM3, they can call each other, but
> not phones registered to CM1 or CM2.
>
>
>
> I have had my network team verify there is not anything they can see in
> the network causing this behavior. Database replication checks out OK and I
> can ping from/to each node.
>
>
>
> Anyone able to point me in the right direction to figure this out?
>
>
>
> 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

Re: [cisco-voip] [External] Re: List still active?

[Anthony Holloway]

Hi Peter!

This list is quasi-indexed by Google, but only because Google is indexing
other websites (mailing list archives) which are archiving the messages.
My favorite way to search the list is https://cisco-voip.markmail.org/

However, I was painting a picture of a single source of knowledge
sharing, one that just happens to also be indexed by Google.  A place where
most new people will likely land first.  A place where reputation building
(via voting, ranking and awards) can happen. Oh, and by the way, Cisco is
willing to reward you with real cash value via the VIP program; something I
have achieved 5 times now.

I don't keep a running total, but if I had to estimate it, I've been
awarded approximately $20,000 of value (e.g., cisco live passes) for my
contributions on the forums over the years.

Now, don't let me fool you into thinking I'm against all
other communication channels. I know that there's value in a
distributed system, so I do use quite a few.  Some of you may even know me
as ez4me2c3d <https://www.reddit.com/user/ez4me2c3d> on reddit.  Some of
you see me in Teams spaces chatting it up there.  Not too mention my
participation on this list over the years.

But that doesn't mean I cannot have a favorite amongst the bunch. ;)

On Sat, Dec 26, 2020 at 2:06 PM Peter Slow  wrote:

> A. I was actually under the impression that this list was indexed by
> search engines
>
> B. I legit miss you guys, not being able to see you all at networkers was
> a total bummer.
>
> Hope you’re all staying safe.
>
> -Peter
> peter at slow dot net
>
> On Sat, Dec 26, 2020 at 12:02 Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Hunter,
>>
>> Yeah, I hear you on that one.  I struggle with it too.  If I had it my
>> way, everything would just be on the Cisco forums, being indexed by
>> Google.  Think of people trying to come up in their career and how
>> distributed the knowledge is.  Cisco Docs, Cisco Forums, Mailing Lists,
>> Training Sites (pluralsight, cbt nuggets, etc.), Reddit (and other
>> random sites about voip), Webex Teams spaces, Slack, Discord, Twitter,
>> YouTube, etc.  And yes, I have a connection to Cisco collaboration on every
>> one of those platforms.  I just prioritize some over others, and that might
>> mean that I only check Twitter like every 2 weeks or something like that.
>>
>> Maybe this distributed nature of information, knowledge, and
>> communication is necessary?  Or at the very least, unavoidable?
>>
>> On Fri, Dec 25, 2020 at 2:55 PM Hunter Fuller  wrote:
>>
>>> Wow. I struggle enough keeping up with the real-time chats from my
>>> colleagues and customers. I definitely can't handle a chat for every list
>>> I'm subscribed to. Not sure how those people do it.
>>>
>>> Merry VoIPmas!
>>>
>>> --
>>> Hunter Fuller (they)
>>> Router Jockey
>>> VBH Annex B-5
>>> +1 256 824 5331
>>>
>>> Office of Information Technology
>>> The University of Alabama in Huntsville
>>> Network Engineering
>>>
>>>
>>> On Fri, Dec 25, 2020 at 2:51 PM Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
>>>> Chat services like Webex Teams and Discord have killed the list, IMO.
>>>>
>>>> Also, Merry Christmas, all you VoIP Heads out there.
>>>>
>>>> On Fri, Dec 25, 2020 at 1:38 PM Ryan Huff  wrote:
>>>>
>>>>> Yes, it has declined in volume.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> > On Dec 25, 2020, at 14:30, Bill Talley  wrote:
>>>>> >
>>>>> > Thanks for the confirmation Ryan.  Are you also seeing a
>>>>> significant decline in volume from the group?
>>>>> >
>>>>> > Hope all the usual (and even casual) participants are staying
>>>>> healthy and employed.  Hope those aren’t reasons for the decline in forum
>>>>> usage.
>>>>> >
>>>>> > Sent from an iPhone mobile device with very tiny touchscreen input
>>>>> keys.  Please excude my typtos.
>>>>> >
>>>>> >> On Dec 25, 2020, at 1:28 PM, Ryan Huff 
>>>>> wrote:
>>>>> >>
>>>>> >> I still see you.
>>>>> >>
>>>>> >> Sent from my iPhone
>>>>> >>
>>>>> >>>> On Dec 25, 2020, at 14:28, Bill Talley  wrote:
>>>>> >>>
>>>>

Re: [cisco-voip] [External] Re: List still active?

[Anthony Holloway]

Hunter,

Yeah, I hear you on that one.  I struggle with it too.  If I had it my way,
everything would just be on the Cisco forums, being indexed by Google.
Think of people trying to come up in their career and how distributed the
knowledge is.  Cisco Docs, Cisco Forums, Mailing Lists, Training Sites
(pluralsight, cbt nuggets, etc.), Reddit (and other random sites about
voip), Webex Teams spaces, Slack, Discord, Twitter, YouTube, etc.  And yes,
I have a connection to Cisco collaboration on every one of those
platforms.  I just prioritize some over others, and that might mean that I
only check Twitter like every 2 weeks or something like that.

Maybe this distributed nature of information, knowledge, and communication
is necessary?  Or at the very least, unavoidable?

On Fri, Dec 25, 2020 at 2:55 PM Hunter Fuller  wrote:

> Wow. I struggle enough keeping up with the real-time chats from my
> colleagues and customers. I definitely can't handle a chat for every list
> I'm subscribed to. Not sure how those people do it.
>
> Merry VoIPmas!
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
>
> On Fri, Dec 25, 2020 at 2:51 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Chat services like Webex Teams and Discord have killed the list, IMO.
>>
>> Also, Merry Christmas, all you VoIP Heads out there.
>>
>> On Fri, Dec 25, 2020 at 1:38 PM Ryan Huff  wrote:
>>
>>> Yes, it has declined in volume.
>>>
>>> Sent from my iPhone
>>>
>>> > On Dec 25, 2020, at 14:30, Bill Talley  wrote:
>>> >
>>> > Thanks for the confirmation Ryan.  Are you also seeing a significant
>>> decline in volume from the group?
>>> >
>>> > Hope all the usual (and even casual) participants are staying healthy
>>> and employed.  Hope those aren’t reasons for the decline in forum usage.
>>> >
>>> > Sent from an iPhone mobile device with very tiny touchscreen input
>>> keys.  Please excude my typtos.
>>> >
>>> >> On Dec 25, 2020, at 1:28 PM, Ryan Huff  wrote:
>>> >>
>>> >> I still see you.
>>> >>
>>> >> Sent from my iPhone
>>> >>
>>> >>>> On Dec 25, 2020, at 14:28, Bill Talley  wrote:
>>> >>>
>>> >>> I stopped receive list emails.   Is the list dead or was I banned?
>>> 😉
>>> >>>
>>> >>> Sent from an iPhone mobile device with very tiny touchscreen input
>>> keys.  Please excude my typtos.
>>> >>> ___
>>> >>> cisco-voip mailing list
>>> >>> cisco-voip@puck.nether.net
>>> >>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=04%7C01%7C%7C862cd952c60f4cb8ebb608d8a90b8c18%7C84df9e7fe9f640afb435%7C1%7C0%7C637445214339013495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TOQxb7cMkrbb3akfFF2LdEwcWyveeqpl6PJ%2Bk9AMIlg%3D&reserved=0
>>> ___
>>> 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] List still active?

[Anthony Holloway]

I do not have links UC Penguin to share.  In fact, it would seem as though
they are mostly invite-only, or at the very least, not publicly promoted.
I'm not sure if that's intentional, or just a side effect of the technology.

On Sat, Dec 26, 2020 at 8:00 AM UC Penguin  wrote:

> Do you have links for related lists on these services?
>
> On Dec 25, 2020, at 14:51, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 
> Chat services like Webex Teams and Discord have killed the list, IMO.
>
> Also, Merry Christmas, all you VoIP Heads out there.
>
> On Fri, Dec 25, 2020 at 1:38 PM Ryan Huff  wrote:
>
>> Yes, it has declined in volume.
>>
>> Sent from my iPhone
>>
>> > On Dec 25, 2020, at 14:30, Bill Talley  wrote:
>> >
>> > Thanks for the confirmation Ryan.  Are you also seeing a significant
>> decline in volume from the group?
>> >
>> > Hope all the usual (and even casual) participants are staying healthy
>> and employed.  Hope those aren’t reasons for the decline in forum usage.
>> >
>> > Sent from an iPhone mobile device with very tiny touchscreen input
>> keys.  Please excude my typtos.
>> >
>> >> On Dec 25, 2020, at 1:28 PM, Ryan Huff  wrote:
>> >>
>> >> I still see you.
>> >>
>> >> Sent from my iPhone
>> >>
>> >>>> On Dec 25, 2020, at 14:28, Bill Talley  wrote:
>> >>>
>> >>> I stopped receive list emails.   Is the list dead or was I banned? 😉
>> >>>
>> >>> Sent from an iPhone mobile device with very tiny touchscreen input
>> keys.  Please excude my typtos.
>> >>> ___
>> >>> cisco-voip mailing list
>> >>> cisco-voip@puck.nether.net
>> >>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=04%7C01%7C%7C862cd952c60f4cb8ebb608d8a90b8c18%7C84df9e7fe9f640afb435%7C1%7C0%7C637445214339013495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TOQxb7cMkrbb3akfFF2LdEwcWyveeqpl6PJ%2Bk9AMIlg%3D&reserved=0
>> ___
>> 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] List still active?

[Anthony Holloway]

Chat services like Webex Teams and Discord have killed the list, IMO.

Also, Merry Christmas, all you VoIP Heads out there.

On Fri, Dec 25, 2020 at 1:38 PM Ryan Huff  wrote:

> Yes, it has declined in volume.
>
> Sent from my iPhone
>
> > On Dec 25, 2020, at 14:30, Bill Talley  wrote:
> >
> > Thanks for the confirmation Ryan.  Are you also seeing a significant
> decline in volume from the group?
> >
> > Hope all the usual (and even casual) participants are staying healthy
> and employed.  Hope those aren’t reasons for the decline in forum usage.
> >
> > Sent from an iPhone mobile device with very tiny touchscreen input
> keys.  Please excude my typtos.
> >
> >> On Dec 25, 2020, at 1:28 PM, Ryan Huff  wrote:
> >>
> >> I still see you.
> >>
> >> Sent from my iPhone
> >>
>  On Dec 25, 2020, at 14:28, Bill Talley  wrote:
> >>>
> >>> I stopped receive list emails.   Is the list dead or was I banned? 😉
> >>>
> >>> Sent from an iPhone mobile device with very tiny touchscreen input
> keys.  Please excude my typtos.
> >>> ___
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=04%7C01%7C%7C862cd952c60f4cb8ebb608d8a90b8c18%7C84df9e7fe9f640afb435%7C1%7C0%7C637445214339013495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TOQxb7cMkrbb3akfFF2LdEwcWyveeqpl6PJ%2Bk9AMIlg%3D&reserved=0
> ___
> 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] call redirect to external number is sometimes failing

[Anthony Holloway]

I agree with you, it does not seem to be a CSS/PT issue, since the call
routes some of the time.

Have you taken a look at the logs on CUCM yet?  Did you know you can throw
the logs into Cisco Solution Analyzer  for a
quick check?

Have you checked the PSTN Voice Gateway to see if the bad calls even hit it?

On Thu, Nov 12, 2020 at 7:03 AM naresh rathore  wrote:

> hi
>
>
> I have a requirement to call external land line number after particular
> option is selected (uccx 12.0). for that I used call redirect step and
> mentioned destination number as desired landline number. when I make a test
> call, all calls are not successful ( i also checked after office hours when
> there is no other call except test call), may be 2 out of 5 calls are
> successful and the call gets connected but mostly i hear double beep and
> call gets disconnected rather than connecting me to landline number.
>
>
> it doesnt appear to be CSS, Partition issue as all calls are not failing.
> any suggestions?
>
>
> Regards
>
>
> Naresh Rathore
> ___
> 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] RedSky SIP Trunk

[Anthony Holloway]

Was there a need for inbound traffic initiated from RedSky, or is this
purely outbound from CUCM?

On Wed, Apr 1, 2020 at 1:29 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> Nope it is actually as simple as they said. Basic sip trunk out of CUCM.
> No special profiles, or anything.  Am having problems as one of my CUCMs
> goes through an ISR to get to RedSky vs an ASA. ISR NAT is being funky but
> dealing with that.
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Wednesday, April 1, 2020 2:27 PM
> *To:* Matthew Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] RedSky SIP Trunk
>
>
>
> [EXTERNAL]
>
>
>
> So...are you still without a functional SIP trunk then Matt?
>
>
>
> On Tue, Mar 31, 2020 at 8:08 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> Has anyone done this? Surprisingly they don’t provide a bunch of guidance
> here. I’m so used to carriers and other vendors being very very specific
> about how to setup their trunks.
>
>
>
> I was planning on doing them directly in CUCM as that seemed simpler, but
> would appreciate any input.
>
>
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> ___
> 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] End of Sale for Perpetual Calling Licenses and related SWSS

[Anthony Holloway]

Oops!  "tierd TAC support" was intended.

On Thu, Sep 24, 2020 at 9:30 AM Charles Goldsmith  wrote:

> "come with *tired* TAC support?"
>
> I bet they are!
>
>
> On Thu, Sep 24, 2020 at 9:23 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> That's great info, thank you for sharing.
>>
>> Does this mean that "traditional" tac support is also changing?  Because,
>> doesn't Flex come with tired TAC support?  Any info you can share there?
>> Thanks!
>>
>> On Thu, Sep 24, 2020 at 8:48 AM Matthew Loraditch <
>> mloradi...@heliontechnologies.com> wrote:
>>
>>>
>>> https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-licensing/eos-eol-notice-c51-744285.html
>>>
>>>
>>> https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-licensing/eos-eol-notice-c51-744286.html
>>>
>>>
>>>
>>> Everything CUCM/UCXN is moving to a new Flex 3.0 License model.
>>>
>>>
>>>
>>> It’s got better pricing than before with significant multi year
>>> discounts for 36 month or greater commitments. For on-prem folks SRST and
>>> CER licenses are included with all license levels and there are levels now
>>> with cheaper options for what would have been UCL Enhanced, and UCL
>>> Essential/Basic users.
>>>
>>>
>>>
>>> Key Dates:
>>>
>>>
>>>
>>> Yesterday- SWSS Reinstatements ended
>>>
>>> 1/23/21 – Non BE6K licenses/SWSS no longer available for Sale, all add
>>> ons must be flex, also last day to renew existing SWSS as multi year
>>>
>>> 7/24/21 – BE6K licenses/SWSS no longer available for sale
>>>
>>> 1/29/22- Last Day to renew any SWSS Contract
>>>
>>> 1/27/24- Last Day of Support via SWSS (you would have had to do a Multi
>>> Year Renewal before 1/23/21)
>>>
>>>
>>>
>>>
>>>
>>> Partner Link: https://salesconnect.cisco.com/#/program/PAGE-2888
>>>
>>>
>>>
>>> Customer Link:
>>> https://www.cisco.com/c/en/us/products/collateral/unified-communications/cisco-collaboration-flex-plan/datasheet-c78-744220.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Matthew Loraditch
>>> Sr. Network Engineer
>>> p: *443.541.1518* <443.541.1518>
>>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
>>> e: *mloradi...@heliontechnologies.com*
>>> 
>>> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>>> [image: Facebook] <https://facebook.com/heliontech>
>>> [image: Twitter] <https://twitter.com/heliontech>
>>> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>>> ___
>>> 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] Deprecated phones in CUCM 14

[Anthony Holloway]

This statement from the link is interesting to me:

"...opportunity to move to newer phone models and clients at a pace that is
reasonable."


   - 8800 series was released 8 years ago
   - 7940's have been end of support since 5 years ago


On Thu, Sep 24, 2020 at 8:20 AM Lelio Fulgenzi  wrote:

> Yeah, there was some talk about this in the forums. Someone from Cisco
> said, “watch the page for some changes we think you’ll like”.
>
>
>
> Wish they would update the “updated” date.
>
>
>
> Lelio
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *James
> Buchanan
> *Sent:* Thursday, September 24, 2020 7:49 AM
> *To:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* [cisco-voip] Deprecated phones in CUCM 14
>
>
>
> *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
>
>
>
> Hello,
>
>
>
> So, Cisco changed their mind for now:
>
>
>
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/14_0_1/fieldNotices/cucm_b_deprecated-phones-14.html
>
>
>
> Thanks,
>
>
>
> James
> ___
> 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] End of Sale for Perpetual Calling Licenses and related SWSS

[Anthony Holloway]

That's great info, thank you for sharing.

Does this mean that "traditional" tac support is also changing?  Because,
doesn't Flex come with tired TAC support?  Any info you can share there?
Thanks!

On Thu, Sep 24, 2020 at 8:48 AM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

>
> https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-licensing/eos-eol-notice-c51-744285.html
>
>
> https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-licensing/eos-eol-notice-c51-744286.html
>
>
>
> Everything CUCM/UCXN is moving to a new Flex 3.0 License model.
>
>
>
> It’s got better pricing than before with significant multi year discounts
> for 36 month or greater commitments. For on-prem folks SRST and CER
> licenses are included with all license levels and there are levels now with
> cheaper options for what would have been UCL Enhanced, and UCL
> Essential/Basic users.
>
>
>
> Key Dates:
>
>
>
> Yesterday- SWSS Reinstatements ended
>
> 1/23/21 – Non BE6K licenses/SWSS no longer available for Sale, all add ons
> must be flex, also last day to renew existing SWSS as multi year
>
> 7/24/21 – BE6K licenses/SWSS no longer available for sale
>
> 1/29/22- Last Day to renew any SWSS Contract
>
> 1/27/24- Last Day of Support via SWSS (you would have had to do a Multi
> Year Renewal before 1/23/21)
>
>
>
>
>
> Partner Link: https://salesconnect.cisco.com/#/program/PAGE-2888
>
>
>
> Customer Link:
> https://www.cisco.com/c/en/us/products/collateral/unified-communications/cisco-collaboration-flex-plan/datasheet-c78-744220.html
>
>
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] 
> [image: Facebook] 
> [image: Twitter] 
> [image: LinkedIn] 
> ___
> 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] presence failover issues

[Anthony Holloway]

Under normal HA failover circumstances, the users should not lose the
association they already have.  Granted, new users will not be able to be
assigned when HA is broken.  So, this seems like a defect to me.  Or, quite
possibly a change in behavior from what I am used to, in which case, that's
terrible to have to re-assign all users upon failover, especially if you've
chosen manually as opposed to automatic assignment, because you need users
on certain pairs, in a multi-pair environment.

If you think it's a matter of distance, you need to check that the network
characteristics are meeting the requirements for clustering over the wan
.
E.g., There is a steady 1.5Mbps required between sites, and then you must
factor in: additional sites, users and activity on top of that.  QoS plays
an important role to ensure the network performs the way you designed it to
under no congestion/load.

On Mon, Sep 14, 2020 at 1:16 AM naresh rathore  wrote:

> hi
>
>
> I currently have cucm 12.5.1.11900-146, primary cucm and im and presence
> is installed in Sydney and secondary is installed in Newzealand. often i
> see user disassociated with presence server and user are not able to login
> to jabber. i have to to again assign all user to presence server. also
> sometime see following presence redudancy status. is it because of these
> devices are installed far away
>
>
>
>
>
> Regards
>
>
> Nareh
> ___
> 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] SIP Binding: Different Binds for Carrier vs Internal

[Anthony Holloway]

Doh! You're absolutely right.  It was a mistake in thought process on my
part.  You would not need to bind if a single interface.  You would only
need to bind when there is more than one possible egress interface to
source your traffic from.

In your case, with loopbacks, you'll need to bind.

Something tricky the CUBE does, in my opinion, is how it responds to
OPTIONS messages.  You will need to either match your incoming leg on Via
header, or create a specific dial-peer matching on Via header just to set
the bind, to the OPTIONS reply uses the correct interface.

On Fri, Sep 11, 2020 at 6:34 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> The way you  have #2 written is bothering me, if you only have one
> interface period you should never need to bind, but if you only have one
> egress interface and need certain traffic to be on IP A and some on IP B
> (via loopbacks) then you would need to bind and that is my scenario.
>
>
>
>
>
> I have a complicated (to me!) routing situation and I need my PSTN traffic
> to the ITSP to be on an IP that only they know about and my internal
> traffic to be the same. This was the best way I could think of to make that
> happen.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Friday, September 11, 2020 5:46 PM
> *To:* Matthew Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] SIP Binding: Different Binds for Carrier vs
> Internal
>
>
>
> [EXTERNAL]
>
>
>
> First up, you don't need to bind your interfaces.  You should bind your
> interfaces in two scenarios though:
>
>
>
> 1. You're trying to source your IP from a loopback address
>
> 2. You only have one interface
>
>
>
> Otherwise, let the router do it's routing and it will pick the correct
> interface to "bind" SIP too, by the nature of which interface the packet
> leaves the router from.
>
>
>
> Now, you can bind, if you want to, but it doesn't do anything extra, to
> the best of my knowledge.
>
>
>
> When you say, "[n]ever see the other’s IP," you should know that this
> happens by default.  That's what a B2BUA does.  It terminates a dialog with
> one peer, and then turns around and originates a new dialog with a
> different peer.
>
>
>
> And yes, flow through is default, but that does not affect signaling,
> which it kind of sounds like is the topic at hand.  Otherwise, flow around
> means your carrier knows how to hit your inside IP Phone addresses
> directly, and that's not likely the case.
>
>
>
> So literally, you do not have to do anything extra or special to get what
> you want.  You simply configure the router as a device with two interfaces
> on two different networks, and teach it how to route (e.g., static routing
> or something, I don't know I'm not a CCIE Routing and Switching).
>
>
>
> On Fri, Sep 11, 2020 at 2:25 PM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> I need to bind call legs to my carrier to one IP and all legs to CUCM on
> another IP on the same router and neither side ever see the other’s IP nor
> need to route to it
>
>
>
> I’ve done something, at least similar, many years in the past but no
> longer have access to the environment to verify the behavior and am trying
> to refresh myself on the setting.
>
>
>
> In that setup we bound the dial peers to the relevant interfaces and
> enabled allow-connections sip to sip and address-hiding in my voice service
> voip config.
>
>
>
> From what I further understand media flow-through is the default behavior
> so as long as I do the binding, I will get what I want to happen happening.
>
>
>
> Am I generally correct in all of my current thoughts? Anything I’m not
> thinking of?
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> ___
> 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] SIP Binding: Different Binds for Carrier vs Internal

[Anthony Holloway]

First up, you don't need to bind your interfaces.  You should bind your
interfaces in two scenarios though:

1. You're trying to source your IP from a loopback address
2. You only have one interface

Otherwise, let the router do it's routing and it will pick the correct
interface to "bind" SIP too, by the nature of which interface the packet
leaves the router from.

Now, you can bind, if you want to, but it doesn't do anything extra, to the
best of my knowledge.

When you say, "[n]ever see the other’s IP," you should know that this
happens by default.  That's what a B2BUA does.  It terminates a dialog with
one peer, and then turns around and originates a new dialog with a
different peer.

And yes, flow through is default, but that does not affect signaling, which
it kind of sounds like is the topic at hand.  Otherwise, flow around means
your carrier knows how to hit your inside IP Phone addresses directly, and
that's not likely the case.

So literally, you do not have to do anything extra or special to get what
you want.  You simply configure the router as a device with two interfaces
on two different networks, and teach it how to route (e.g., static routing
or something, I don't know I'm not a CCIE Routing and Switching).

On Fri, Sep 11, 2020 at 2:25 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> I need to bind call legs to my carrier to one IP and all legs to CUCM on
> another IP on the same router and neither side ever see the other’s IP nor
> need to route to it
>
>
>
> I’ve done something, at least similar, many years in the past but no
> longer have access to the environment to verify the behavior and am trying
> to refresh myself on the setting.
>
>
>
> In that setup we bound the dial peers to the relevant interfaces and
> enabled allow-connections sip to sip and address-hiding in my voice service
> voip config.
>
>
>
> From what I further understand media flow-through is the default behavior
> so as long as I do the binding, I will get what I want to happen happening.
>
>
>
> Am I generally correct in all of my current thoughts? Anything I’m not
> thinking of?
>
>
>
>
>
>
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] 
> [image: Facebook] 
> [image: Twitter] 
> [image: LinkedIn] 
> ___
> 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] [External] Re: Remote Phone Control

[Anthony Holloway]

Adam, if you're interested in a sweeping method (i.e., running a script on
multiple phones), I can help you with a python program do so.  Just let me
know.

On Mon, Aug 24, 2020 at 7:10 AM Pawlowski, Adam  wrote:

> That’s pretty neat.
>
>
>
> Back before COVID when we had more people in those terrible open office
> spaces I wanted to set up a couple of RTP streams to “dial” into white
> noise, or ocean sounds or some such thing for a bit more privacy. Rather
> than having SURL buttons to do it that would be a neat way to go about it.
>
>
>
> Adam
>
>
>
> *From:* Anthony Holloway 
> *Sent:* Friday, August 21, 2020 4:39 PM
> *To:* Pawlowski, Adam 
> *Cc:* Hunter Fuller ; Cisco VoIP Group <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] [External] Re: Remote Phone Control
>
>
>
> Yeah, neat idea.  Speaking of unconventional ideas with joining RTP
> streams, when I worked at a larger company which held all employee
> conference calls, I hooked into the CURRI API for the toll free number for
> the audio bridge, and caused the call to be rejected but at the same time,
> I joined the calling phone to the RTP stream, because the production was
> also streaming the audio over the network enterprise wide.  Saved on
> trunks, and conferencing costs.
>
>
>
> On Fri, Aug 21, 2020 at 3:36 PM Pawlowski, Adam  wrote:
>
> Have had way too much fun with that in the past with various media files,
> the Play function, and yeah the RTP. VLC can be a source but so can a
> cheapo 7941. We used them for audio for some holiday parties years ago,
> just stuck some phones under the tables to boost the ones already in the
> room and viola.
>
>
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *Anthony
> Holloway
> *Sent:* Friday, August 21, 2020 4:27 PM
> *To:* Hunter Fuller 
> *Cc:* Cisco VoIP Group 
> *Subject:* Re: [cisco-voip] [External] Re: Remote Phone Control
>
>
>
> And you would never upload a rick roll audio clip to your CUCM as a
> mutlitcast audio source, and then abuse the join rtp stream function on
> your co-workers phones either.  No...no you wouldn't.  And neither have I.
> ;)
>
>
>
> On Fri, Aug 21, 2020 at 3:07 PM Hunter Fuller  wrote:
>
> Im pretty sure this just completely changed the way we provide remote
> help in the COVID era. Since I can just add a customer's phone to my
> controlled devices, help them fix/show me some problem remotely, and
> then remove it.
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
> On Fri, Aug 21, 2020 at 3:04 PM Erick Bergquist 
> wrote:
> >
> > It’s a great tool.
> >
> >
> > On Fri, Aug 21, 2020 at 9:13 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
> >>
> >> My add-on was approved to be in the add-on store:
> https://addons.mozilla.org/addon/cisco-phone-controller/
> >>
> >> On Fri, Aug 14, 2020, 11:38 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
> >>>
> >>> I published a phone control firefox add-on that I've been sitting on
> for over a decade now: it's not super polished, because it's just for me
> and my friends to use, but I thought, what the hell, make it available
> publicly. I might even polish it up and list it in the add-on store one
> day. Until then: https://github.com/avholloway/cisco-phone-controller
> >>>
> >>>
> >>
> >>
> >> ___
> >>
> >> 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] [External] Re: Remote Phone Control

[Anthony Holloway]

Yeah, neat idea.  Speaking of unconventional ideas with joining RTP
streams, when I worked at a larger company which held all employee
conference calls, I hooked into the CURRI API for the toll free number for
the audio bridge, and caused the call to be rejected but at the same time,
I joined the calling phone to the RTP stream, because the production was
also streaming the audio over the network enterprise wide.  Saved on
trunks, and conferencing costs.

On Fri, Aug 21, 2020 at 3:36 PM Pawlowski, Adam  wrote:

> Have had way too much fun with that in the past with various media files,
> the Play function, and yeah the RTP. VLC can be a source but so can a
> cheapo 7941. We used them for audio for some holiday parties years ago,
> just stuck some phones under the tables to boost the ones already in the
> room and viola.
>
>
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *Anthony
> Holloway
> *Sent:* Friday, August 21, 2020 4:27 PM
> *To:* Hunter Fuller 
> *Cc:* Cisco VoIP Group 
> *Subject:* Re: [cisco-voip] [External] Re: Remote Phone Control
>
>
>
> And you would never upload a rick roll audio clip to your CUCM as a
> mutlitcast audio source, and then abuse the join rtp stream function on
> your co-workers phones either.  No...no you wouldn't.  And neither have I.
> ;)
>
>
>
> On Fri, Aug 21, 2020 at 3:07 PM Hunter Fuller  wrote:
>
> Im pretty sure this just completely changed the way we provide remote
> help in the COVID era. Since I can just add a customer's phone to my
> controlled devices, help them fix/show me some problem remotely, and
> then remove it.
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
> On Fri, Aug 21, 2020 at 3:04 PM Erick Bergquist 
> wrote:
> >
> > It’s a great tool.
> >
> >
> > On Fri, Aug 21, 2020 at 9:13 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
> >>
> >> My add-on was approved to be in the add-on store:
> https://addons.mozilla.org/addon/cisco-phone-controller/
> >>
> >> On Fri, Aug 14, 2020, 11:38 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
> >>>
> >>> I published a phone control firefox add-on that I've been sitting on
> for over a decade now: it's not super polished, because it's just for me
> and my friends to use, but I thought, what the hell, make it available
> publicly. I might even polish it up and list it in the add-on store one
> day. Until then: https://github.com/avholloway/cisco-phone-controller
> >>>
> >>>
> >>
> >>
> >> ___
> >>
> >> 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] Remote Phone Control

[Anthony Holloway]

Thanks for the kind words!

On Fri, Aug 21, 2020 at 3:03 PM Erick Bergquist  wrote:

> It’s a great tool.
>
>
> On Fri, Aug 21, 2020 at 9:13 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> My add-on was approved to be in the add-on store:
>> https://addons.mozilla.org/addon/cisco-phone-controller/
>>
>> On Fri, Aug 14, 2020, 11:38 AM Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> I published a phone control firefox add-on that I've been sitting on for
>>> over a decade now: it's not super polished, because it's just for me and my
>>> friends to use, but I thought, what the hell, make it available publicly. I
>>> might even polish it up and list it in the add-on store one day. Until
>>> then: https://github.com/avholloway/cisco-phone-controller
>>>
>>>
>>>
>>
>> ___
>>
>> 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] [External] Re: Remote Phone Control

[Anthony Holloway]

And you would never upload a rick roll audio clip to your CUCM as a
mutlitcast audio source, and then abuse the join rtp stream function on
your co-workers phones either.  No...no you wouldn't.  And neither have I.
;)

On Fri, Aug 21, 2020 at 3:07 PM Hunter Fuller  wrote:

> Im pretty sure this just completely changed the way we provide remote
> help in the COVID era. Since I can just add a customer's phone to my
> controlled devices, help them fix/show me some problem remotely, and
> then remove it.
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
> On Fri, Aug 21, 2020 at 3:04 PM Erick Bergquist 
> wrote:
> >
> > It’s a great tool.
> >
> >
> > On Fri, Aug 21, 2020 at 9:13 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
> >>
> >> My add-on was approved to be in the add-on store:
> https://addons.mozilla.org/addon/cisco-phone-controller/
> >>
> >> On Fri, Aug 14, 2020, 11:38 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
> >>>
> >>> I published a phone control firefox add-on that I've been sitting on
> for over a decade now: it's not super polished, because it's just for me
> and my friends to use, but I thought, what the hell, make it available
> publicly. I might even polish it up and list it in the add-on store one
> day. Until then: https://github.com/avholloway/cisco-phone-controller
> >>>
> >>>
> >>
> >>
> >> ___
> >>
> >> 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] Remote Phone Control

[Anthony Holloway]

My add-on was approved to be in the add-on store:
https://addons.mozilla.org/addon/cisco-phone-controller/

On Fri, Aug 14, 2020, 11:38 AM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> I published a phone control firefox add-on that I've been sitting on for
> over a decade now: it's not super polished, because it's just for me and my
> friends to use, but I thought, what the hell, make it available publicly. I
> might even polish it up and list it in the add-on store one day. Until
> then: https://github.com/avholloway/cisco-phone-controller
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] [External] IPCC best practice

[Anthony Holloway]

Low blow Erick, low blow.

On Wed, Aug 19, 2020 at 7:37 PM Erick Bergquist  wrote:

> Didn’t the original name have Platform at the end , making P last
> character after CRA?
>
>
> On Wed, Aug 19, 2020 at 1:10 PM f...@browardcommunications.com <
> f...@browardcommunications.com> wrote:
>
>> Not blowing it up at all, I’ve enjoyed the back n forth!!
>>
>> I was going to try n be cool for a second and throw ICM out there.
>>
>> /FW
>>
>>
>>
>> Sent from my iPhone
>>
>> On Aug 19, 2020, at 2:42 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> We might have to stop blowing up Fred's email with our inside jokes and
>> musing of technology past.  Sorry Fred!  I hope you got the
>> answers/feedback you were looking for.
>>
>> On Wed, Aug 19, 2020 at 1:39 PM Bill Talley  wrote:
>>
>>> +1000
>>>
>>> 
>>>
>>> Sent from an iPhone mobile device with very tiny touchscreen input
>>> keys.  Please excude my typtos.
>>>
>>> On Aug 19, 2020, at 12:51 PM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
>>> 
>>> GTFO
>>>
>>> On Wed, Aug 19, 2020 at 10:25 AM NateCCIE  wrote:
>>>
>>>> What about IP IVR?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Aug 19, 2020, at 9:16 AM, Lelio Fulgenzi  wrote:
>>>>
>>>> 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> +100 for Anthony!
>>>>
>>>> 😊
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* Anthony Holloway 
>>>>
>>>>
>>>>
>>>>
>>>> *Sent:* Wednesday, August 19, 2020 10:48 AM
>>>>
>>>>
>>>> *To:* Lelio Fulgenzi 
>>>>
>>>>
>>>> *Cc:* Matthew Loraditch ; Charles
>>>> Goldsmith ; cisco-voip@puck.nether.net
>>>>
>>>>
>>>> *Subject:* Re: [cisco-voip] [External] IPCC best practice
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Wait Lelio, CRA is older terminology than CRS, so it should go:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> +1 IPCC
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> +2 CRS
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> +3 CRA
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Right?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 19, 2020 at 8:53 AM Lelio Fulgenzi 
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Not much more to add here, except +1 for calling in IPCC. :) you’d have
>>>> gotten +2 if you called it CRA. ;)
>>>>
>>>>
&

Re: [cisco-voip] [External] IPCC best practice

[Anthony Holloway]

We might have to stop blowing up Fred's email with our inside jokes and
musing of technology past.  Sorry Fred!  I hope you got the
answers/feedback you were looking for.

On Wed, Aug 19, 2020 at 1:39 PM Bill Talley  wrote:

> +1000
>
> 
>
> Sent from an iPhone mobile device with very tiny touchscreen input keys.
> Please excude my typtos.
>
> On Aug 19, 2020, at 12:51 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 
> GTFO
>
> On Wed, Aug 19, 2020 at 10:25 AM NateCCIE  wrote:
>
>> What about IP IVR?
>>
>> Sent from my iPhone
>>
>> On Aug 19, 2020, at 9:16 AM, Lelio Fulgenzi  wrote:
>>
>> 
>>
>> +100 for Anthony! 😊
>>
>>
>>
>>
>>
>>
>>
>> *From:* Anthony Holloway 
>> *Sent:* Wednesday, August 19, 2020 10:48 AM
>> *To:* Lelio Fulgenzi 
>> *Cc:* Matthew Loraditch ; Charles
>> Goldsmith ; cisco-voip@puck.nether.net
>> *Subject:* Re: [cisco-voip] [External] IPCC best practice
>>
>>
>>
>> *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
>>
>>
>>
>> Wait Lelio, CRA is older terminology than CRS, so it should go:
>>
>>
>>
>> +1 IPCC
>>
>> +2 CRS
>>
>> +3 CRA
>>
>>
>>
>> Right?
>>
>>
>>
>> On Wed, Aug 19, 2020 at 8:53 AM Lelio Fulgenzi  wrote:
>>
>>
>>
>> Not much more to add here, except +1 for calling in IPCC. :) you’d have
>> gotten +2 if you called it CRA. ;)
>>
>>
>>
>> But, seriously, you have to weigh the pros and cons of injecting a point
>> of failure vs ease of administration.
>>
>>
>>
>> My thought process is, can you build automatic recovery? Or easily
>> understood manual backup.
>>
>>
>>
>> And is the design something you can easily hand off to someone?
>>
>>
>>
>> Lots of things to consider.
>>
>>
>>
>> Sent from my iPhone
>>
>>
>>
>> On Aug 19, 2020, at 9:00 AM, Matthew Loraditch <
>> mloradi...@heliontechnologies.com> wrote:
>>
>> 
>>
>> *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
>>
>>
>>
>> We still use Call Handlers. We have fewer resources who can handle script
>> editing and somewhat frequent requests to change hours and such that we
>> need the regular techs to be able to handle.
>>
>>
>>
>> Definitely a preference thing.
>>
>>
>>
>>
>>
>> *Matthew Loraditch**​*
>>
>> *Sr. Network Engineer*
>>
>> p: *443.541.1518* <443.541.1518>
>>
>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>>
>>  |
>>
>> e: *mloradi...@heliontechnologies.com*
>> 
>>
>> <http://www.heliontechnologies.com/>
>>
>>  <http://www.heliontechnologies.com/>
>>
>>
>>
>> <https://facebook.com/heliontech>
>>
>>  <https://facebook.com/heliontech>
>>
>>
>>
>> <https://twitter.com/heliontech>
>>
>>  <https://twitter.com/heliontech>
>>
>>
>>
>> <https://www.linkedin.com/company/helion-technologies>
>>
>>  <https://www.linkedin.com/company/helion-technologies>
>>
>>
>>
>> *From:* cisco-voip  *On Behalf Of 
>> *Charles
>> Goldsmith
>> *Sent:* Wednesday, August 19, 2020 8:39 AM
>> *To:* Johnson, Tim 
>> *Cc:* cisco-voip@puck.nether.net
>> *Subject:* Re: [cisco-voip] [External] IPCC best practice
>>
>>
>>
>> [EXTERNAL]
>>
>>
>>
>> Agreed with TIm, it's just simpler to involve less systems if you can.
>> With 12.0 UCCX and higher, the calendar function is a nice addition, no
>> more XML files for schedules.
>>
>>
>>
>> On Wed, Aug 19, 2020 at 7:37 AM Johnson, Tim  wrote:
>>
>> It seems to me that there's not a "best practice" label for most
>> scenarios. When I started with UCCX, we went to a call handler first to
>> provide us with an easy way to provide a schedule, and a famil

Re: [cisco-voip] [External] IPCC best practice

[Anthony Holloway]

GTFO

On Wed, Aug 19, 2020 at 10:25 AM NateCCIE  wrote:

> What about IP IVR?
>
> Sent from my iPhone
>
> On Aug 19, 2020, at 9:16 AM, Lelio Fulgenzi  wrote:
>
> 
>
> +100 for Anthony! 😊
>
>
>
>
>
>
>
> *From:* Anthony Holloway 
> *Sent:* Wednesday, August 19, 2020 10:48 AM
> *To:* Lelio Fulgenzi 
> *Cc:* Matthew Loraditch ; Charles
> Goldsmith ; cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] [External] IPCC best practice
>
>
>
> *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
>
>
>
> Wait Lelio, CRA is older terminology than CRS, so it should go:
>
>
>
> +1 IPCC
>
> +2 CRS
>
> +3 CRA
>
>
>
> Right?
>
>
>
> On Wed, Aug 19, 2020 at 8:53 AM Lelio Fulgenzi  wrote:
>
>
>
> Not much more to add here, except +1 for calling in IPCC. :) you’d have
> gotten +2 if you called it CRA. ;)
>
>
>
> But, seriously, you have to weigh the pros and cons of injecting a point
> of failure vs ease of administration.
>
>
>
> My thought process is, can you build automatic recovery? Or easily
> understood manual backup.
>
>
>
> And is the design something you can easily hand off to someone?
>
>
>
> Lots of things to consider.
>
>
>
> Sent from my iPhone
>
>
>
> On Aug 19, 2020, at 9:00 AM, Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> 
>
> *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
>
>
>
> We still use Call Handlers. We have fewer resources who can handle script
> editing and somewhat frequent requests to change hours and such that we
> need the regular techs to be able to handle.
>
>
>
> Definitely a preference thing.
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> <http://www.heliontechnologies.com/>
>
>  <http://www.heliontechnologies.com/>
>
>
>
> <https://facebook.com/heliontech>
>
>  <https://facebook.com/heliontech>
>
>
>
> <https://twitter.com/heliontech>
>
>  <https://twitter.com/heliontech>
>
>
>
> <https://www.linkedin.com/company/helion-technologies>
>
>  <https://www.linkedin.com/company/helion-technologies>
>
>
>
> *From:* cisco-voip  *On Behalf Of *Charles
> Goldsmith
> *Sent:* Wednesday, August 19, 2020 8:39 AM
> *To:* Johnson, Tim 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] [External] IPCC best practice
>
>
>
> [EXTERNAL]
>
>
>
> Agreed with TIm, it's just simpler to involve less systems if you can.
> With 12.0 UCCX and higher, the calendar function is a nice addition, no
> more XML files for schedules.
>
>
>
> On Wed, Aug 19, 2020 at 7:37 AM Johnson, Tim  wrote:
>
> It seems to me that there's not a "best practice" label for most
> scenarios. When I started with UCCX, we went to a call handler first to
> provide us with an easy way to provide a schedule, and a familiar way for
> the customer to record a greeting. Later, we ended up building the schedule
> into our script and directing calls to the trigger. That's my preference,
> just to involve less systems.
>
> Tim Johnson
> Voice & Video Engineer
> Central Michigan University
> Call me: +19897744406
> Video Call me: johns...@cmich.edu
> Fax me: +19897795900
> Meet me: http://cmich.webex.com/meet/johns10t
>
>
> -Original Message-
> From: cisco-voip  On Behalf Of
> f...@browardcommunications.com
> Sent: Wednesday, August 19, 2020 8:19 AM
> To: cisco-voip@puck.nether.net
> Subject: [External] [cisco-voip] IPCC best practice
>
>
> Hello, I just have a quick question.
> When setting up a call center for a SMB, Is it best practice to have the
> main number go to a unity call handler 1st, with caller input going to uccx
> triggers, or is it considered best practice to have the main number go
> right to CCX?  I have seen both ways.
>
> Thank you.
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.

Re: [cisco-voip] [External] IPCC best practice

[Anthony Holloway]

Wait Lelio, CRA is older terminology than CRS, so it should go:

+1 IPCC
+2 CRS
+3 CRA

Right?

On Wed, Aug 19, 2020 at 8:53 AM Lelio Fulgenzi  wrote:

>
> Not much more to add here, except +1 for calling in IPCC. :) you’d have
> gotten +2 if you called it CRA. ;)
>
> But, seriously, you have to weigh the pros and cons of injecting a point
> of failure vs ease of administration.
>
> My thought process is, can you build automatic recovery? Or easily
> understood manual backup.
>
> And is the design something you can easily hand off to someone?
>
> Lots of things to consider.
>
> Sent from my iPhone
>
> On Aug 19, 2020, at 9:00 AM, Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> 
>
> 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
>
> We still use Call Handlers. We have fewer resources who can handle script
> editing and somewhat frequent requests to change hours and such that we
> need the regular techs to be able to handle.
>
>
>
> Definitely a preference thing.
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
>
> 
> 
>
> 
> 
>
> 
> 
>
> 
> 
>
> *From:* cisco-voip  *On Behalf Of *Charles
> Goldsmith
> *Sent:* Wednesday, August 19, 2020 8:39 AM
> *To:* Johnson, Tim 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] [External] IPCC best practice
>
>
>
> [EXTERNAL]
>
>
>
> Agreed with TIm, it's just simpler to involve less systems if you can.
> With 12.0 UCCX and higher, the calendar function is a nice addition, no
> more XML files for schedules.
>
>
>
> On Wed, Aug 19, 2020 at 7:37 AM Johnson, Tim  wrote:
>
> It seems to me that there's not a "best practice" label for most
> scenarios. When I started with UCCX, we went to a call handler first to
> provide us with an easy way to provide a schedule, and a familiar way for
> the customer to record a greeting. Later, we ended up building the schedule
> into our script and directing calls to the trigger. That's my preference,
> just to involve less systems.
>
> Tim Johnson
> Voice & Video Engineer
> Central Michigan University
> Call me: +19897744406
> Video Call me: johns...@cmich.edu
> Fax me: +19897795900
> Meet me: http://cmich.webex.com/meet/johns10t
>
>
> -Original Message-
> From: cisco-voip  On Behalf Of
> f...@browardcommunications.com
> Sent: Wednesday, August 19, 2020 8:19 AM
> To: cisco-voip@puck.nether.net
> Subject: [External] [cisco-voip] IPCC best practice
>
>
> Hello, I just have a quick question.
> When setting up a call center for a SMB, Is it best practice to have the
> main number go to a unity call handler 1st, with caller input going to uccx
> triggers, or is it considered best practice to have the main number go
> right to CCX?  I have seen both ways.
>
> 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
>
> ___
> 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] [External] IPCC best practice

[Anthony Holloway]

Fred,

There's no best practice for this question/scenario.  You have to do what
is best for the given set of parameters the business gives you to design a
solution.

On Wed, Aug 19, 2020 at 8:53 AM Lelio Fulgenzi  wrote:

>
> Not much more to add here, except +1 for calling in IPCC. :) you’d have
> gotten +2 if you called it CRA. ;)
>
> But, seriously, you have to weigh the pros and cons of injecting a point
> of failure vs ease of administration.
>
> My thought process is, can you build automatic recovery? Or easily
> understood manual backup.
>
> And is the design something you can easily hand off to someone?
>
> Lots of things to consider.
>
> Sent from my iPhone
>
> On Aug 19, 2020, at 9:00 AM, Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> 
>
> 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
>
> We still use Call Handlers. We have fewer resources who can handle script
> editing and somewhat frequent requests to change hours and such that we
> need the regular techs to be able to handle.
>
>
>
> Definitely a preference thing.
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
>
> 
> 
>
> 
> 
>
> 
> 
>
> 
> 
>
> *From:* cisco-voip  *On Behalf Of *Charles
> Goldsmith
> *Sent:* Wednesday, August 19, 2020 8:39 AM
> *To:* Johnson, Tim 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] [External] IPCC best practice
>
>
>
> [EXTERNAL]
>
>
>
> Agreed with TIm, it's just simpler to involve less systems if you can.
> With 12.0 UCCX and higher, the calendar function is a nice addition, no
> more XML files for schedules.
>
>
>
> On Wed, Aug 19, 2020 at 7:37 AM Johnson, Tim  wrote:
>
> It seems to me that there's not a "best practice" label for most
> scenarios. When I started with UCCX, we went to a call handler first to
> provide us with an easy way to provide a schedule, and a familiar way for
> the customer to record a greeting. Later, we ended up building the schedule
> into our script and directing calls to the trigger. That's my preference,
> just to involve less systems.
>
> Tim Johnson
> Voice & Video Engineer
> Central Michigan University
> Call me: +19897744406
> Video Call me: johns...@cmich.edu
> Fax me: +19897795900
> Meet me: http://cmich.webex.com/meet/johns10t
>
>
> -Original Message-
> From: cisco-voip  On Behalf Of
> f...@browardcommunications.com
> Sent: Wednesday, August 19, 2020 8:19 AM
> To: cisco-voip@puck.nether.net
> Subject: [External] [cisco-voip] IPCC best practice
>
>
> Hello, I just have a quick question.
> When setting up a call center for a SMB, Is it best practice to have the
> main number go to a unity call handler 1st, with caller input going to uccx
> triggers, or is it considered best practice to have the main number go
> right to CCX?  I have seen both ways.
>
> 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
>
> ___
> 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] 12.5 SU3 is Out - Important change (IMO)

[Anthony Holloway]

And the 911 Route Pattern annoyer...err.. I mean reminder.  I have yet to
experience it, but it reads like you simply check a box to acknowledge that
you know what you are doing, just in case your 911 pattern is a DN for CER
or an XLATE to avoid secondary dial-tone issues.

On Fri, Aug 14, 2020 at 2:08 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> Some may have heard of the work to help make performance better and here’s
> a neat little caveat for the new HAProxy for Tomcat:
>
>
>
> “Restart of the Cisco TFTP service will temporarily result in the
> unavailability of the web services up to 10 seconds on that node where
> HAProxy undergoes restart.”
>
>
>
> I know at least in my environments I restart TFTP during business hours
> when necessary. Need to think about that more in smaller environments since
> now you could be turning off AXL and such briefly.
>
>
>
> See here:
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/12_5_1/SU3/cucm_b_release-notes-for-cucm-imp-1251su3/cucm_m_about-this-release.html#concept_297A520DF0A0B5830F2B916C4CBC88E3
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] 
> [image: Facebook] 
> [image: Twitter] 
> [image: LinkedIn] 
> ___
> 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] Remote Phone Control

[Anthony Holloway]

I published a phone control firefox add-on that I've been sitting on for
over a decade now: it's not super polished, because it's just for me and my
friends to use, but I thought, what the hell, make it available publicly. I
might even polish it up and list it in the add-on store one day. Until
then: https://github.com/avholloway/cisco-phone-controller
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Unity xfer Getting 603 from carrier

[Anthony Holloway]

Most of the time it' the verbose nature of the systems to perform a
handoff.  I.e., They are chatty!

There are two methods to reduce the chatter that I know of:

1) On the CUBE the command mid-call signlaing passthru media-change
(spellcheck?)
2) On the CUCM a service param called Duplex Streaming Enabled set to True

Maybe others know of more.

Anyway, if neither of these commands reduce the delay, you would need to
look at a ladder diagram of the end-to-end (which is why sip end-to-end is
nice) signaling to see where the delay comes from.

On Fri, Aug 14, 2020 at 8:16 AM f...@browardcommunications.com <
f...@browardcommunications.com> wrote:

> Hello, thanks again for the help, a combination of Diversion and PAI is
> finally what let the call go through with ATT, so that is working now.
> Issue now is, there is a very long delay between the time the caller
> selects the option, and the call actually gets routed, any thoughts on what
> would cause this delay?
> Thank you.
>
>
>
>
> Sent from my iPhone
>
> On Jul 30, 2020, at 4:41 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> Midcall signaling wont help the calling number issue. The link I posted
> has examples.
>
> On Thu, Jul 30, 2020 at 3:29 PM f...@browardcommunications.com <
> f...@browardcommunications.com> wrote:
>
>> Thank you.
>> So, it looks like I have 3 options:
>> - Set the midcall signaling, which I am trying tonight
>>
>> - setting the sip trunk on calling party selection to “last redirect
>> number”
>> And reset
>>
>> - then if all else fails I will try the sip profile.
>>
>> Do you have an example sip profile / dial-peer config handy?
>>
>> Thank you much!
>>
>>
>>
>> Sent from my iPhone
>>
>> On Jul 30, 2020, at 3:46 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> If your assessment is correct about the calling number, the carrier will
>> see the original or outside caller's phone number in the From field and
>> reject your call.  I see this being solved most of the time with a SIP
>> Profile on the outgoing dial-peer, which adds either a Diversion header or
>> a P-Asserted-Identity header.
>>
>> E.g.,
>>
>> https://community.cisco.com/t5/collaboration-voice-and-video/configure-and-troubleshoot-call-forward-to-the-pstn-using-sip/ta-p/3118287
>>
>> On Wed, Jul 29, 2020 at 6:45 AM f...@browardcommunications.com <
>> f...@browardcommunications.com> wrote:
>>
>>>
>>> Greetings all, this might be simple fix, I just haven’t dealt with this
>>> in a while.
>>>
>>> We have a unity AA that, when external callers call, select menu
>>> options, etc. Unity will send the call back to. CtiRp, which then CFA to an
>>> external number. You hear the Unity transfer message, 1 second of MoH, then
>>> 10 seconds of nothing, then the call drops.
>>>
>>> Internal calls to the CFA ctirp works
>>>
>>> Internal calls to the unity ctirp then back to the CFA ctirp works.
>>>
>>> I tried having unity call the pstn number directly with same results
>>>
>>> I think the issue is with the calling number is why the carrier is
>>> sending the 603, but it is next to impossible to get them to tell us that.
>>>
>>> Call flow:
>>> Pstn>sipt>cucm >unity>cucm>ctirp-CFA-pstn
>>>
>>> Where would I change the calling number being CFA’ed from Unity to the
>>> PSTN?
>>>
>>> Any ideas?
>>>
>>> Thank you.
>>>
>>> /FW
>>>
>>> Sent from my iPhone
>>> ___
>>> 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] Jabber via MRA failover from one CUCM node to another

[Anthony Holloway]

Do you have access to this document?  It's limited to who can view it.

https://salesconnect.cisco.com/#/content-detail/8da1f8a8-1f29-4e56-bc09-eb43175a3bba


On Thu, Jul 30, 2020 at 7:20 PM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> " This is a surprise to me that this fundamental feature is still not
> supported after many years."
>
> Are you new to working with Cisco solutions?
>
> On Wed, Jul 29, 2020 at 12:02 AM Gerence Guan 
> wrote:
>
>> Hi All,
>>
>> I found this old post from Cisco community.
>>
>> https://community.cisco.com/t5/ip-telephony-and-phones/jabber-softphone-via-mra-does-not-fall-over-to-secondary-cucm/td-p/2807099
>>
>>
>> Is this still true for Jabber 12.8, MRA 12.5 and CUCM 12.5?
>>
>> In the MRA 12.6 deployment guide it says
>> Cisco *Jabber* clients support IM and Presence Service failover over
>> MRA. However, they *don't support* any other type of MRA-related
>> redundancy or *failover*—*including SIP*, voicemail, and User Data
>> Services (UDS). Clients use a single UDS server only.
>>
>> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-6/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_01.html
>>
>>
>>
>> In the Jabber 12.8 planning guide, it says High Availability(failover) of
>> audio and video service is not supported
>>
>> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/12_8/cjab_b_planning-guide-cisco-jabber-128/cjab_b_planning-guide-cisco-jabber-128_chapter_010.html
>>
>>
>> If anyone has a MRA lab, can you please help to test it buy just
>> disconnect the first cucm node in the jabber's ccm group and verify whether
>> jabber can register to the second node in the ccm group?
>>
>> This is a surprise to me that this fundamental feature is still not
>> supported after many years.
>>
>> Best Regards
>> Guan
>>
>> ___
>> 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] Jabber via MRA failover from one CUCM node to another

[Anthony Holloway]

" This is a surprise to me that this fundamental feature is still not
supported after many years."

Are you new to working with Cisco solutions?

On Wed, Jul 29, 2020 at 12:02 AM Gerence Guan  wrote:

> Hi All,
>
> I found this old post from Cisco community.
>
> https://community.cisco.com/t5/ip-telephony-and-phones/jabber-softphone-via-mra-does-not-fall-over-to-secondary-cucm/td-p/2807099
>
>
> Is this still true for Jabber 12.8, MRA 12.5 and CUCM 12.5?
>
> In the MRA 12.6 deployment guide it says
> Cisco *Jabber* clients support IM and Presence Service failover over MRA.
> However, they *don't support* any other type of MRA-related redundancy or
> *failover*—*including SIP*, voicemail, and User Data Services (UDS).
> Clients use a single UDS server only.
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-6/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_01.html
>
>
>
> In the Jabber 12.8 planning guide, it says High Availability(failover) of
> audio and video service is not supported
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/12_8/cjab_b_planning-guide-cisco-jabber-128/cjab_b_planning-guide-cisco-jabber-128_chapter_010.html
>
>
> If anyone has a MRA lab, can you please help to test it buy just
> disconnect the first cucm node in the jabber's ccm group and verify whether
> jabber can register to the second node in the ccm group?
>
> This is a surprise to me that this fundamental feature is still not
> supported after many years.
>
> Best Regards
> Guan
>
> ___
> 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] Unity xfer Getting 603 from carrier

[Anthony Holloway]

Midcall signaling wont help the calling number issue. The link I posted has
examples.

On Thu, Jul 30, 2020 at 3:29 PM f...@browardcommunications.com <
f...@browardcommunications.com> wrote:

> Thank you.
> So, it looks like I have 3 options:
> - Set the midcall signaling, which I am trying tonight
>
> - setting the sip trunk on calling party selection to “last redirect
> number”
> And reset
>
> - then if all else fails I will try the sip profile.
>
> Do you have an example sip profile / dial-peer config handy?
>
> Thank you much!
>
>
>
> Sent from my iPhone
>
> On Jul 30, 2020, at 3:46 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> If your assessment is correct about the calling number, the carrier will
> see the original or outside caller's phone number in the From field and
> reject your call.  I see this being solved most of the time with a SIP
> Profile on the outgoing dial-peer, which adds either a Diversion header or
> a P-Asserted-Identity header.
>
> E.g.,
>
> https://community.cisco.com/t5/collaboration-voice-and-video/configure-and-troubleshoot-call-forward-to-the-pstn-using-sip/ta-p/3118287
>
> On Wed, Jul 29, 2020 at 6:45 AM f...@browardcommunications.com <
> f...@browardcommunications.com> wrote:
>
>>
>> Greetings all, this might be simple fix, I just haven’t dealt with this
>> in a while.
>>
>> We have a unity AA that, when external callers call, select menu options,
>> etc. Unity will send the call back to. CtiRp, which then CFA to an external
>> number. You hear the Unity transfer message, 1 second of MoH, then 10
>> seconds of nothing, then the call drops.
>>
>> Internal calls to the CFA ctirp works
>>
>> Internal calls to the unity ctirp then back to the CFA ctirp works.
>>
>> I tried having unity call the pstn number directly with same results
>>
>> I think the issue is with the calling number is why the carrier is
>> sending the 603, but it is next to impossible to get them to tell us that.
>>
>> Call flow:
>> Pstn>sipt>cucm >unity>cucm>ctirp-CFA-pstn
>>
>> Where would I change the calling number being CFA’ed from Unity to the
>> PSTN?
>>
>> Any ideas?
>>
>> Thank you.
>>
>> /FW
>>
>> Sent from my iPhone
>> ___
>> 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] Unity xfer Getting 603 from carrier

[Anthony Holloway]

If your assessment is correct about the calling number, the carrier will
see the original or outside caller's phone number in the From field and
reject your call.  I see this being solved most of the time with a SIP
Profile on the outgoing dial-peer, which adds either a Diversion header or
a P-Asserted-Identity header.

E.g.,
https://community.cisco.com/t5/collaboration-voice-and-video/configure-and-troubleshoot-call-forward-to-the-pstn-using-sip/ta-p/3118287

On Wed, Jul 29, 2020 at 6:45 AM f...@browardcommunications.com <
f...@browardcommunications.com> wrote:

>
> Greetings all, this might be simple fix, I just haven’t dealt with this in
> a while.
>
> We have a unity AA that, when external callers call, select menu options,
> etc. Unity will send the call back to. CtiRp, which then CFA to an external
> number. You hear the Unity transfer message, 1 second of MoH, then 10
> seconds of nothing, then the call drops.
>
> Internal calls to the CFA ctirp works
>
> Internal calls to the unity ctirp then back to the CFA ctirp works.
>
> I tried having unity call the pstn number directly with same results
>
> I think the issue is with the calling number is why the carrier is sending
> the 603, but it is next to impossible to get them to tell us that.
>
> Call flow:
> Pstn>sipt>cucm >unity>cucm>ctirp-CFA-pstn
>
> Where would I change the calling number being CFA’ed from Unity to the
> PSTN?
>
> Any ideas?
>
> Thank you.
>
> /FW
>
> Sent from my iPhone
> ___
> 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] Is CME media flow through by default?

[Anthony Holloway]

I agree with you Brian, so then, why do so many people type the
command address-hiding in to their CUBE configuration?  It just baffles me.

On Wed, Jul 29, 2020 at 1:36 PM Brian Meade  wrote:

> Yea, CUBE is really just any config in which it's IP to IP on both sides
> of the router.  CME with a SIP or SCCP phone and a VoIP dial-peer to a SIP
> carrier would be flow-through/address-hiding by default just like any VoIP
> dial-peer by default.
>
> On Wed, Jul 29, 2020 at 4:13 AM Gerence Guan  wrote:
>
>> Hi all
>>
>> If using Cisco SIP IP phone on CME which terminates the SIP trunk from
>> service provider SBC, will it be media flow through by default? Can CME do
>> the IP address hiding between the voice vlan and service provider, like
>> what CUBE does?
>>
>> Best Regards,
>> Guan
>> ___
>> 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] UCCX Flex Licensing

[Anthony Holloway]

Thanks for the update.  Unfortunately, the only 12.5+Flex I had access to,
is now inaccessible to me (project engagement over, remote access disabled).

On Tue, Jul 28, 2020 at 9:18 AM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> So An update to this. After tac added a temp license to our system with
> the issue the error cleared AND it’s no longer reporting admin accounts
> with admin rights AND reporting rights as premium license consumers.
>
>
>
> I had a call with some BU people about the 12.5 SU1 EFT and I brought this
> up and they said admin rights should not use a license on a flex install.
>
>
>
> As I have their ear if anyone else is willing to confirm or test on their
> 12.5 Flex system, let me know!
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* cisco-voip  *On Behalf Of *Matthew
> Loraditch
> *Sent:* Thursday, June 11, 2020 6:00 PM
> *To:* Brian Meade 
> *Cc:* Cisco VoIP Group 
> *Subject:* Re: [cisco-voip] UCCX Flex Licensing
>
>
>
> [EXTERNAL]
>
>
>
> Premium Flex or a mix ? and you only have built in admin or sync’d users
> are also admin?
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Brian Meade 
> *Sent:* Thursday, June 11, 2020 5:56 PM
> *To:* Matthew Loraditch 
> *Cc:* Anthony Holloway ; Cisco VoIP
> Group 
> *Subject:* Re: [cisco-voip] UCCX Flex Licensing
>
>
>
> [EXTERNAL]
>
>
>
> I've got a customer on 12.5 UCCX with Flex licensing and I'm not seeing
> that behavior.  Only when someone logs in to Finesse does it increase
> counters on the licensing page in UCCX.
>
>
>
> On Thu, Jun 11, 2020 at 2:19 PM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> He is not, I didn’t get further response during the webcast. If you are
> comfortable DM’ing or Teamsing me his info, please do.
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Thursday, June 11, 2020 1:46 PM
> *To:* Matthew Loraditch 
> *Cc:* Pawlowski, Adam ; Cisco VoIP Group <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] UCCX Flex Licensing
>
>
>
> [EXTERNAL]
>
>
>
> Thanks for the action and the update.  Is the Flex PM, Kevin McPartlan, on
> that webcast?
>
>
>
> On Thu, Jun 11, 2020 at 11:59 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> I’m on a partner webcast now and asking about this. If you have premium
> flex licensing even the built-in admin requires a license!  I’m beating
> them up on this as it’s still not documented anywhere and I’ve got
> customers on flex that will have issues when upgrading to 12.5
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>

Re: [cisco-voip] H.323 Gateway call forward?

[Anthony Holloway]

I would think so James.

Do you not have the ability to do it in CUCM then?  Why not?

What's the PSTN connectivity like?  POTS?  If it's POTS then H323 doesn't
even come into play; it's pots-to-pots.  Does your provider allow
unscreened ANI?

Can you apply translation rules on the incoming call leg dial-peer?  Do you
already have this setup, or would you need to create it?

Can you translate late the incoming DID to an outgoing dialed number which
matches an outgoing call left dial-peer?

Pseudo Config:

voice translation-rule 1
 rule 1 /^6125551212$/ /96125551313/
!
voice translation-profile globalize
 translate called 1
!
dial-peer voice 1 pots
 description Incoming PSTN Call Leg
 translation-profile incoming globalize
!
dial-peer voice 2 pots
 description Outgoing PSTN Call Leg
 destination-pattern 9T
!

On Fri, Jul 17, 2020 at 2:45 PM James Dust 
wrote:

> Good evening all,
>
>
>
> I have a need to call forward a range of numbers, In a remote site using
> an old H.323 Gaetway.
>
>
>
> Is it possible to do this via the config on the gateway itself? Dial peer?
>
>
>
> 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/
>
> ___
> 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] OAuth for Unity Connection/Office 365

[Anthony Holloway]

Looks like CUCM 11.5 SU8 addresses oauth with o365.  Did you see that?

On Wed, Apr 22, 2020 at 3:02 PM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Matthew, What did you end up learning on this effort?
>
> On Tue, Feb 4, 2020 at 10:10 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
>> I did see that this morning and it fueled my confusion as it’s not needed
>> (or useful) when using oauth and the EWS APIs.
>>
>>
>>
>> They added OAuth because Microsoft is disabling the basic authentication
>> that the Autodiscover and the old method used to use.
>>
>>
>>
>> Really just hoping to get some insight from someone and hope to hear it’s
>> half baked and will be finished later and/or I found an issue and it’ll get
>> fixed. Will work with TAC eventually if I don’t get any feedback
>>
>>
>>
>> Matthew Loraditch​
>> Sr. Network Engineer
>> p: *443.541.1518* <443.541.1518>
>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
>> e: *mloradi...@heliontechnologies.com*
>> 
>> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>> [image: Facebook] <https://facebook.com/heliontech>
>> [image: Twitter] <https://twitter.com/heliontech>
>> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>>
>>
>>
>> *From:* Dave Goodwin 
>> *Sent:* Tuesday, February 4, 2020 10:32 AM
>> *To:* Matthew Loraditch 
>> *Cc:* cisco-voip@puck.nether.net
>> *Subject:* Re: [cisco-voip] OAuth for Unity Connection/Office 365
>>
>>
>>
>> [EXTERNAL]
>>
>>
>>
>> Matthew, yes it is pretty new, and I have no setup with which to
>> experiment or test, but have you read this section of the CUC 12.x doc? It
>> seems to indicate CUC will still use Auto Discovery and in Step 6 it shows
>> how to enable that in O365.
>>
>>
>> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/unified_messaging/b_12xcucumgx/b_12xcucumgx_chapter_01.html#ID-2370-05f5
>>
>>
>>
>> On Tue, Feb 4, 2020 at 10:04 AM Matthew Loraditch <
>> mloradi...@heliontechnologies.com> wrote:
>>
>> This just came out yesterday so this is more directed for anyone lurking
>> at Cisco, but how is this supposed to work?
>>
>>
>>
>> Our UM has been disabled for months because of MS security requirements
>> for resellers that broke the old way so I quickly installed this in my test
>> lab to see if it will fix my issue.
>>
>>
>>
>> According to all the MS documentation there should be no need to use the
>> old Autodiscover, etc that Unity was using. You just connect to the default
>> outlook.office365.com EWS url and use your oauth info and boom.
>>
>>
>>
>> However, the fields for the old account are still there and mandatory and
>> all the test options are going through and failing Autodiscover…
>>
>>
>>
>> If I look at the Mailbox Sync Logs I don’t see any evidence it’s trying
>> to use Oauth/EWS.
>>
>>
>>
>> Going down the rabbit hole so everyone else doesn’t have to!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Matthew Loraditch**​*
>>
>> *Sr. Network Engineer*
>>
>> p: *443.541.1518* <443.541.1518>
>>
>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>>
>>  |
>>
>> e: *mloradi...@heliontechnologies.com*
>> 
>>
>> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>>
>> [image: Facebook] <https://facebook.com/heliontech>
>>
>> [image: Twitter] <https://twitter.com/heliontech>
>>
>> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>>
>> ___
>> 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] digitized voice quality

[Anthony Holloway]

Who is hearing the poor audio, the jabber user?  the person the jabber user
is speaking to?  is this jabber to jabber only?  is this over wlan or lan?

One idea for why audio sucks but audio+video doesn't is that your priority
queue is dropping packets and when video is added both audio and video are
af41 and therefore circumvents the priority queue.

Can you confirm the dscp values on the voice stream for a voice only versus
voice+video call?

On Mon, Jul 13, 2020 at 9:51 AM Scott Voll  wrote:

> All--
>
> we are using Jabber 12.8 with CM 12.5 in a voice only mode.  we have users
> reporting digitized voice call quality.  has anyone else been dealing with
> this?
>
> we have had multiple users say if they add Video to the call it makes it
> better.  Anyone else seeing that?  Any ideas why that would be better?
>
> what else can we do to make this work better?  TAC has not been able to
> help with this after multiple weeks of engagement.
>
> any thoughts?
>
> TIA
>
> Scott
>
> ___
> 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] Fax line issue

[Anthony Holloway]

if your CUBE is SIP on both sides, then "debug ccsip message" and "debug
ccsip error" are the two I would start with. Feel free to post the output
here for us to review.

Also, is your FoIP designed for fax relay and if so, is it T.38 end to end?

On Sat, Jul 11, 2020, 4:44 AM James Dust 
wrote:

> Morning all,
>
> I have a strange issue with a fax number my organisation is trying to send
> to. When dialled the call initially connects at the far end, and I hear fax
> tone, then it just goes silent.
>
>
> The SIP cube sends the call, but I can then see what I think is a
> disconnect.
>
> What debug command would be best to use to confirm this please?
>
> I can call the number from a mobile phone with no issue, and it does not
> disconnect.
>
> 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/
>
> ___
> 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] [EXTERNAL] Re: UCCX 11.6 Real Time Port Usage

[Anthony Holloway]

What language did you write it in, and what details can you share?

On Fri, Jul 10, 2020 at 6:38 PM Tanner Ezell  wrote:

> You're correct, I wrote an app to capture the data and generate the JSON
> response
>
> On Fri, Jul 10, 2020 at 4:33 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> I'm confused.  Is the CTI API returning the JSON data?  I would have
>> guessed not.  Which means, you wrote an app that is sitting in the middle?
>>
>> On Fri, Jul 10, 2020 at 6:19 PM Tanner Ezell 
>> wrote:
>>
>>> Oh, in the response there is a snippet of generated JSON. The key name
>>> is the CTI Port dn number (could change this to device name, or include
>>> both in response), the presence of contactDetails key indicates the port is
>>> in-use but you're right, it might have been more clear to include a
>>> specific field indicating in-use.
>>>
>>> On Fri, Jul 10, 2020 at 4:15 PM Bill Talley  wrote:
>>>
>>>> Maybe I’m overlooking something.   Where in that data is the original
>>>> challenge fulfilled, at least without performing multiple queries to
>>>> determine the parameter from every active call?
>>>>
>>>> Sent from an iPhone mobile device with very tiny touchscreen input
>>>> keys.  Please excude my typtos.
>>>>
>>>> On Jul 10, 2020, at 5:59 PM, Tanner Ezell 
>>>> wrote:
>>>>
>>>> 
>>>> The challenge was only to indicate which ports were in use, but I
>>>> thought it'd be more fun to also include details about the caller, or
>>>> application information. All data is pretty much available (we could list
>>>> what queues they're in if we wanted to), just a matter of what information
>>>> is valuable.
>>>>
>>>> Imagine a dashboard that fired off when a counter variable exceeded a
>>>> certain value within a running script; VIP caller is identified by an ECC
>>>> variable while in queue and is manually handled by an agent or supervisor
>>>> (cherry pick); Imagine troubleshooting a callers actual call flow,
>>>> replaying their experience step by step, seeing variable values change with
>>>> each ste; Code coverage testing, automated application testing.. lots of
>>>> fun stuff we can do.
>>>>
>>>> On Fri, Jul 10, 2020 at 3:34 PM Bill Talley  wrote:
>>>>
>>>>> Getting data is easy, getting the right data, not so easy
>>>>>
>>>>> Sent from an iPhone mobile device with very tiny touchscreen input
>>>>> keys.  Please excude my typtos.
>>>>>
>>>>> On Jul 10, 2020, at 5:21 PM, Tanner Ezell 
>>>>> wrote:
>>>>>
>>>>> 
>>>>> Getting data is easy, giving you presentation is a bit more
>>>>> challenging... (sanitized)
>>>>>
>>>>>  "1103010": {
>>>>> "state": "In Service",
>>>>> "ccgId": "6"
>>>>>   },
>>>>>   "1103011": {
>>>>> "state": "In Service",
>>>>> "contactDetails": {
>>>>>   "callingNumber": "removed",
>>>>>   "calledNumber": "removed",
>>>>>   "originalDialedNumber": "null",
>>>>>   "arrivalType": "2",
>>>>>   "CLID": "null",
>>>>>   "DNIS": "null",
>>>>>   "lastRedirectedNumber": "null",
>>>>>   "eccDataMap": {
>>>>> "SCRIPTCFG": "null",
>>>>> "ACCOUNT_NUMBER": "null",
>>>>> "CALLVAR9": "null",
>>>>> "ANI": "null",
>>>>> "CALLER_ENTERED_DIGITS": "null",
>>>>> "SCRIPTID": "null",
>>>>> "CALLVAR7": "null",
>>>>> "CALLVAR8": "null",
>>>>> "CALLVAR5": "null",
>>>>> "CALLVAR6": "null",
>>>>> "CALLVAR10": "null",
>>>>> "CALLVAR3": "null&quo

Re: [cisco-voip] [EXTERNAL] Re: UCCX 11.6 Real Time Port Usage

[Anthony Holloway]

ot;value": "\"2286854\"",
>>> "type": "java.lang.String"
>>>   },
>>>   "pTerminalMenu": {
>>> "name": "pTerminalMenu",
>>> "value": "P[6886/688601.wav]",
>>> "type": "com.cisco.prompt.Playable"
>>>   },
>>>   "svoicemail": {
>>> "name": "svoicemail",
>>> "value": "\"2286856\"",
>>> "type": "java.lang.String"
>>>   }
>>> },
>>> "ccgId": "6"
>>>   },
>>> [CLIPPED]
>>> and if you're wondering, yes, those are real-time insights into the
>>> script variables and caller ECC. I could tell you the step they're
>>> currently on.. ;)
>>>
>>> It's too bad there isn't a market for these tools, lots of fun stuff we
>>> can do.
>>>
>>> On Fri, Jul 10, 2020 at 1:42 PM Bill Talley  wrote:
>>>
>>>> I ran some tests, and as Anthony suggested, there is no data returned
>>>> which indicates anything beyond the registration status of a device.   🤷‍♂️
>>>>
>>>> Sent from an iPhone mobile device with very tiny touchscreen input
>>>> keys.  Please excude my typtos.
>>>>
>>>> On Jul 10, 2020, at 2:56 PM, JASON BURWELL via cisco-voip <
>>>> cisco-voip@puck.nether.net> wrote:
>>>>
>>>> 
>>>>
>>>> Thank you for all the responses! Been a busy day so late getting back.
>>>>
>>>>
>>>>
>>>> I was able to see the data I needed in historical format by running the
>>>> licensing report shown in the thread Anthony posted. Very high level but
>>>> gives the overall numbers. I wish there was a way to monitor this real time
>>>> and in detail without having to do a lot of custom work which, unless I
>>>> missed something, sounds like what would need to happen.
>>>>
>>>>
>>>>
>>>> RTMT does show CTI ports but only shows IN/OUT of service status, not
>>>> what the port is actually doing. I’ve long wondered when a refresh was
>>>> coming to RTMT with more functionality as it feels a bit outdated and seems
>>>> like its been essentially unchanged as far back as I can remember. Although
>>>> maybe the newer versions have improvements I am not aware of?
>>>>
>>>>
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* cisco-voip  *On Behalf Of 
>>>> *Anthony
>>>> Holloway
>>>> *Sent:* Friday, July 10, 2020 2:03 PM
>>>> *To:* Tanner Ezell 
>>>> *Cc:* Charles Goldsmith ; cisco-voip@puck.nether.net
>>>> *Subject:* Re: [cisco-voip] [EXTERNAL] Re: UCCX 11.6 Real Time Port
>>>> Usage
>>>>
>>>>
>>>>
>>>> Looks like this has been asked and answered in the past:
>>>>
>>>>
>>>>
>>>>
>>>> https://community.cisco.com/t5/contact-center/cucm-uccx-how-monitoring-cti-ports/td-p/2328292
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.cisco.com_t5_contact-2Dcenter_cucm-2Duccx-2Dhow-2Dmonitoring-2Dcti-2Dports_td-2Dp_2328292&d=DwMFaQ&c=CrVsPA4meZ6vEtstSPLQqC5izq21_OrN_h8zxKzEuwc&r=cxTKAF4Iaor9PiEwHMcKcEgAJ-ObtwqWBXjTvqngqNk&m=AuUVwggfF1Gx1OoXF5cZeJc7sWQKhqsQDWdew4aUZqU&s=-wGoowBX4CRP0UqCU1n5Ewyor1xyF_ik4JowJwnA6Mk&e=>
>>>>
>>>>
>>>>
>>>> The two people responding seem familiar to me, but I can't quite put my
>>>> finger on who they are.
>>>>
>>>>
>>>>
>>>> On Fri, Jul 10, 2020 at 11:55 AM Tanner Ezell 
>>>> wrote:
>>>>
>>>> 
>>>>
>>>> I'll see what I can do.
>>>>
>>>>
>>>>
>>>> On Fri, Jul 10, 2020 at 9:45 AM UC Penguin 
>>>> wrote:
>>>>
>>>> It’s been a long time since I’ve used uccx as uccx.  Is the option for
>>>> real time reporting present under the Tools menu? (It is when licensed as
>>>> IP IVR)
>>>>
>>>>
>>>>
>>>> It requires Java and is finicky, but does report.
>>>>
>>>>
>

Re: [cisco-voip] UCCX 11.6 Real Time Port Usage

[Anthony Holloway]

My gut tells me no, but let's see what you find.

Use Cases

RisPort allows applications to retrieve the registration state of a device
and current IP address of a device or application. This information is
useful in scenarios such as:

   - A notification and alert application which obtains the IP address of a
   set of phones from RisPort in order to send an on-screen push notification
   via the IP Phone Services API
   <https://developer.cisco.com/site/ip-phone-services/overview/>
   - A system health and monitoring application which periodically checks
   the registration status of critical phone devices or CTI applications via
   RisPort in order to alert administrators of connection failures.

Source: https://developer.cisco.com/site/sxml/discover/overview/risport/

On Fri, Jul 10, 2020 at 12:58 PM Bill Talley  wrote:

> I believe RIS should but I will test and reply back to the list.
>
> Sent from an iPhone mobile device with very tiny touchscreen input keys.
> Please excude my typtos.
>
> On Jul 10, 2020, at 10:30 AM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 
> Bill, just to be clear, do either of the CUCM APIs show the active call
> and idle status of CTI ports?  Not just registration.
>
> On Fri, Jul 10, 2020 at 10:05 AM Bill Talley  wrote:
>
>> 
>> Do you need to gather that data directly from CCX?  It might be easier
>> to pull it from CCM using the PerfMon API or RisPort70 API.
>>
>>
>>
>> Sent from an iPhone mobile device with very tiny touchscreen input keys.
>> Please excude my typtos.
>>
>> On Jul 9, 2020, at 4:07 PM, JASON BURWELL via cisco-voip <
>> cisco-voip@puck.nether.net> wrote:
>>
>> 
>>
>> Is there any way to see real time CTI port usage with UCCX Admin API? I
>> did a quick search and it looks like it’s a supported function but having
>> trouble finding the correct name to use.
>>
>>
>>
>> Thanks
>>
>> Jason
>>
>>
>> ___
>> 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] [EXTERNAL] Re: UCCX 11.6 Real Time Port Usage

[Anthony Holloway]

It's a whole bunch of contacts, like even outbound agent calls,and I don't
mean outbound campaigns, rather just making a call to pizza hut.

So, while yes, it does include the inbound contacts, it includes way too
much data and you cannot filter it.  Additionally for callbacks, it's a
single contact record, but it consumes two ports.

On Fri, Jul 10, 2020 at 12:30 PM UC Penguin  wrote:

> What does Contacts/Contact Summary show?
>
> Doc says call, email, http. Does it have realtime data?
>
> On Jul 10, 2020, at 12:08, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 
> Unfortunately, nothing in RTR gives you port usage.  However, in a
> vanilla environment, like one where only JTAPI triggers are used and it's
> one per call, then your Applications running would equal your ports used
> for the most part.  However, once you have HTTP triggers, Callback, Trigger
> Application step, etc., this 1:1 goes out the door.
>
> 
>
>
> On Fri, Jul 10, 2020 at 11:47 AM UC Penguin  wrote:
>
>> It’s been a long time since I’ve used uccx as uccx.  Is the option for
>> real time reporting present under the Tools menu? (It is when licensed as
>> IP IVR)
>>
>> It requires Java and is finicky, but does report.
>>
>> In CCE instead I just look at the usage on the AW and dump that in AW Db
>> and graph it with Grafana.
>>
>> On Jul 10, 2020, at 10:58, JASON BURWELL via cisco-voip <
>> cisco-voip@puck.nether.net> wrote:
>>
>> 
>>
>> Sorry, been tied us this morning. Just looking for real time usage data
>> of the 300 UCCX Ports we are licensed for. Thanks!
>>
>>
>>
>>
>>
>> *From:* Tanner Ezell 
>> *Sent:* Friday, July 10, 2020 9:41 AM
>> *To:* Charles Goldsmith 
>> *Cc:* Anthony Holloway ; JASON BURWELL <
>> jason.burw...@foundersfcu.com>; cisco-voip@puck.nether.net
>> *Subject:* [EXTERNAL] Re: [cisco-voip] UCCX 11.6 Real Time Port Usage
>>
>>
>>
>> *CAUTION: This email originated outside of Founders Federal Credit Union.
>> Do not click links or open attachments unless you recognize the sender and
>> know the content is safe.*
>> * -- *
>>
>> What information do you need?
>>
>>
>>
>> On Thu, Jul 9, 2020 at 8:13 PM Charles Goldsmith  wrote:
>>
>> You can simply put Tanner in the To: field, old school I know, but it
>> still works :)
>>
>>
>>
>> On Thu, Jul 9, 2020 at 4:46 PM Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> That's nothing I've ever heard of.  I'd imagine you could use the CTI API
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.cisco.com_docs_contact-2Dcenter-2Dexpress_-23-21cti-2Dprotocol-2Doverview&d=DwMFaQ&c=CrVsPA4meZ6vEtstSPLQqC5izq21_OrN_h8zxKzEuwc&r=cxTKAF4Iaor9PiEwHMcKcEgAJ-ObtwqWBXjTvqngqNk&m=ggEpNPUJr1NlfZE1JKM7Cpap2ANTeuhAzqnEstabxds&s=CqzbG56fWHXUL9xOmsT2xuUbjmhpuDpxsKj3g6vGXug&e=>,
>> but not the Admin API.
>>
>>
>>
>> This isn't a REST based API though, and it is relatively harder to
>> implement and work with though.  My man Tanner at CTI Logic should be able
>> to help.  Yo Tanner! Where you at?  Ok, so one PRO for chat rooms are
>> mentions.  Email needs mentions.
>>
>> The CTI Protocol:
>>
>>
>>
>>- Is a TCP/IP socket based message protocol
>>- Allows clients to send and receive information/events about:
>>
>>
>>- Current system configuration and future updates.
>>   - Agents and their states
>>   - Calls and their states
>>   - *Statistics for agents, calls, and queues on a real-time basis*
>>   - Third-party call control
>>   - Device snapshots
>>
>>
>>- Provides support for two client modes for connecting with Unified
>>CCX:
>>
>>
>>- Bridge mode clients receive all agent-state and call events for all
>>   logged in agents in the system.
>>   - Agent mode clients only receives messages related to the agent.
>>
>>
>>- Has version control
>>
>>
>>
>> On Thu, Jul 9, 2020 at 4:07 PM JASON BURWELL via cisco-voip <
>> cisco-voip@puck.nether.net> wrote:
>>
>> Is there any way to see real time CTI port usage with UCCX Admin API? I
>> did a quick search and it looks like it’s a supported function but having
>> trouble finding the correct name to use.
>>
>>
>>
>> Thanks
>>
>> Jason
>>
>>
>>
>>

Re: [cisco-voip] [EXTERNAL] Re: UCCX 11.6 Real Time Port Usage

[Anthony Holloway]

Unfortunately, nothing in RTR gives you port usage.  However, in a
vanilla environment, like one where only JTAPI triggers are used and it's
one per call, then your Applications running would equal your ports used
for the most part.  However, once you have HTTP triggers, Callback, Trigger
Application step, etc., this 1:1 goes out the door.

[image: image.png]

On Fri, Jul 10, 2020 at 11:47 AM UC Penguin  wrote:

> It’s been a long time since I’ve used uccx as uccx.  Is the option for
> real time reporting present under the Tools menu? (It is when licensed as
> IP IVR)
>
> It requires Java and is finicky, but does report.
>
> In CCE instead I just look at the usage on the AW and dump that in AW Db
> and graph it with Grafana.
>
> On Jul 10, 2020, at 10:58, JASON BURWELL via cisco-voip <
> cisco-voip@puck.nether.net> wrote:
>
> 
>
> Sorry, been tied us this morning. Just looking for real time usage data of
> the 300 UCCX Ports we are licensed for. Thanks!
>
>
>
>
>
> *From:* Tanner Ezell 
> *Sent:* Friday, July 10, 2020 9:41 AM
> *To:* Charles Goldsmith 
> *Cc:* Anthony Holloway ; JASON BURWELL <
> jason.burw...@foundersfcu.com>; cisco-voip@puck.nether.net
> *Subject:* [EXTERNAL] Re: [cisco-voip] UCCX 11.6 Real Time Port Usage
>
>
>
> *CAUTION: This email originated outside of Founders Federal Credit Union.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.*
> * -- *
>
> What information do you need?
>
>
>
> On Thu, Jul 9, 2020 at 8:13 PM Charles Goldsmith  wrote:
>
> You can simply put Tanner in the To: field, old school I know, but it
> still works :)
>
>
>
> On Thu, Jul 9, 2020 at 4:46 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> That's nothing I've ever heard of.  I'd imagine you could use the CTI API
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.cisco.com_docs_contact-2Dcenter-2Dexpress_-23-21cti-2Dprotocol-2Doverview&d=DwMFaQ&c=CrVsPA4meZ6vEtstSPLQqC5izq21_OrN_h8zxKzEuwc&r=cxTKAF4Iaor9PiEwHMcKcEgAJ-ObtwqWBXjTvqngqNk&m=ggEpNPUJr1NlfZE1JKM7Cpap2ANTeuhAzqnEstabxds&s=CqzbG56fWHXUL9xOmsT2xuUbjmhpuDpxsKj3g6vGXug&e=>,
> but not the Admin API.
>
>
>
> This isn't a REST based API though, and it is relatively harder to
> implement and work with though.  My man Tanner at CTI Logic should be able
> to help.  Yo Tanner! Where you at?  Ok, so one PRO for chat rooms are
> mentions.  Email needs mentions.
>
> The CTI Protocol:
>
>
>
>- Is a TCP/IP socket based message protocol
>- Allows clients to send and receive information/events about:
>
>
>- Current system configuration and future updates.
>   - Agents and their states
>   - Calls and their states
>   - *Statistics for agents, calls, and queues on a real-time basis*
>   - Third-party call control
>   - Device snapshots
>
>
>- Provides support for two client modes for connecting with Unified
>CCX:
>
>
>- Bridge mode clients receive all agent-state and call events for all
>   logged in agents in the system.
>   - Agent mode clients only receives messages related to the agent.
>
>
>- Has version control
>
>
>
> On Thu, Jul 9, 2020 at 4:07 PM JASON BURWELL via cisco-voip <
> cisco-voip@puck.nether.net> wrote:
>
> Is there any way to see real time CTI port usage with UCCX Admin API? I
> did a quick search and it looks like it’s a supported function but having
> trouble finding the correct name to use.
>
>
>
> Thanks
>
> Jason
>
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dvoip&d=DwMFaQ&c=CrVsPA4meZ6vEtstSPLQqC5izq21_OrN_h8zxKzEuwc&r=cxTKAF4Iaor9PiEwHMcKcEgAJ-ObtwqWBXjTvqngqNk&m=ggEpNPUJr1NlfZE1JKM7Cpap2ANTeuhAzqnEstabxds&s=i4KxNblP8jrAxdHAIhmf0fJtwROUs2LVZWX68Qs7rFQ&e=>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dvoip&d=DwMFaQ&c=CrVsPA4meZ6vEtstSPLQqC5izq21_OrN_h8zxKzEuwc&r=cxTKAF4Iaor9PiEwHMcKcEgAJ-ObtwqWBXjTvqngqNk&m=ggEpNPUJr1NlfZE1JKM7Cpap2ANTeuhAzqnEstabxds&s=i4KxNblP8jrAxdHAIhmf0fJtwROUs2LVZWX68Qs7rFQ&e=>
>
> ___
> 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] UCCX 11.6 Real Time Port Usage

[Anthony Holloway]

Bill, just to be clear, do either of the CUCM APIs show the active call and
idle status of CTI ports?  Not just registration.

On Fri, Jul 10, 2020 at 10:05 AM Bill Talley  wrote:

> 
> Do you need to gather that data directly from CCX?  It might be easier to
> pull it from CCM using the PerfMon API or RisPort70 API.
>
>
>
> Sent from an iPhone mobile device with very tiny touchscreen input keys.
> Please excude my typtos.
>
> On Jul 9, 2020, at 4:07 PM, JASON BURWELL via cisco-voip <
> cisco-voip@puck.nether.net> wrote:
>
> 
>
> Is there any way to see real time CTI port usage with UCCX Admin API? I
> did a quick search and it looks like it’s a supported function but having
> trouble finding the correct name to use.
>
>
>
> Thanks
>
> Jason
>
>
> ___
> 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] UCCX 11.6 Real Time Port Usage

[Anthony Holloway]

LOL, I over-thought the process and forgot to look at the most simple
solution.  Thanks Charles.

On Thu, Jul 9, 2020 at 10:13 PM Charles Goldsmith  wrote:

> You can simply put Tanner in the To: field, old school I know, but it
> still works :)
>
> On Thu, Jul 9, 2020 at 4:46 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> That's nothing I've ever heard of.  I'd imagine you could use the CTI API
>> <https://developer.cisco.com/docs/contact-center-express/#!cti-protocol-overview>,
>> but not the Admin API.
>>
>> This isn't a REST based API though, and it is relatively harder to
>> implement and work with though.  My man Tanner at CTI Logic should be able
>> to help.  Yo Tanner! Where you at?  Ok, so one PRO for chat rooms are
>> mentions.  Email needs mentions.
>>
>> The CTI Protocol:
>>
>>
>>- Is a TCP/IP socket based message protocol
>>- Allows clients to send and receive information/events about:
>>   - Current system configuration and future updates.
>>   - Agents and their states
>>   - Calls and their states
>>   - *Statistics for agents, calls, and queues on a real-time basis*
>>   - Third-party call control
>>   - Device snapshots
>>- Provides support for two client modes for connecting with Unified
>>CCX:
>>   - Bridge mode clients receive all agent-state and call events for
>>   all logged in agents in the system.
>>   - Agent mode clients only receives messages related to the agent.
>>- Has version control
>>
>>
>> On Thu, Jul 9, 2020 at 4:07 PM JASON BURWELL via cisco-voip <
>> cisco-voip@puck.nether.net> wrote:
>>
>>> Is there any way to see real time CTI port usage with UCCX Admin API? I
>>> did a quick search and it looks like it’s a supported function but having
>>> trouble finding the correct name to use.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Jason
>>>
>>>
>>> ___
>>> 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] UCCX 11.6 Real Time Port Usage

[Anthony Holloway]

That's nothing I've ever heard of.  I'd imagine you could use the CTI API
,
but not the Admin API.

This isn't a REST based API though, and it is relatively harder to
implement and work with though.  My man Tanner at CTI Logic should be able
to help.  Yo Tanner! Where you at?  Ok, so one PRO for chat rooms are
mentions.  Email needs mentions.

The CTI Protocol:


   - Is a TCP/IP socket based message protocol
   - Allows clients to send and receive information/events about:
  - Current system configuration and future updates.
  - Agents and their states
  - Calls and their states
  - *Statistics for agents, calls, and queues on a real-time basis*
  - Third-party call control
  - Device snapshots
   - Provides support for two client modes for connecting with Unified CCX:
  - Bridge mode clients receive all agent-state and call events for all
  logged in agents in the system.
  - Agent mode clients only receives messages related to the agent.
   - Has version control


On Thu, Jul 9, 2020 at 4:07 PM JASON BURWELL via cisco-voip <
cisco-voip@puck.nether.net> wrote:

> Is there any way to see real time CTI port usage with UCCX Admin API? I
> did a quick search and it looks like it’s a supported function but having
> trouble finding the correct name to use.
>
>
>
> Thanks
>
> Jason
>
>
> ___
> 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] Automated SIP Testing

[Anthony Holloway]

I don't know of a tool, but if you want to board the devops train (choo
choo) I would recommend looking at Twilio for programmable voice, and using
it to make your phone calls, but you orchestrate it from anywhere.  You'll
get back status codes and the like, if that's all you're after, but you
could use it like a hammer too, and inject audio and/or dtmf, and even
record audio to confirm two-way media paths.

On Wed, Jul 8, 2020 at 11:54 AM UC Penguin  wrote:

> Need to send a call to MS Team and see if it returns an error. Ex. User
> not enabled for voice or unallocated DN.
>
> On Jul 8, 2020, at 10:34, Nick Britt  wrote:
>
> 
> Hi
>
> What sort of testing, load testing?
>
> Chrs
>
> On Wed, Jul 8, 2020 at 7:54 AM UC Penguin  wrote:
>
>> I’m curious if anyone has any experience with SIP testing tools.
>>
>> I’m looking for a tool to be able to script testing valid configurations.
>> Ex. Does MS Teams actually accept a call to this URI or does the group that
>> manages MS Teams need to fix something on there side.
>>
>> TIA
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> --
> - Nick
>
> ___
> 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] Expressway Cluster failover for MRA

[Anthony Holloway]

Brian,

This wouldn't support failover in all scenarios though, correct?  E.g.,
CUCM sub to sub failover.

Does anyone have a nice table of failover scenarios covered and not covered
by expressway clustering versus not?

On Mon, Jul 6, 2020 at 9:29 AM Brian Meade  wrote:

> I would not use Expressway clustering and just have 2 different C/E pairs
> with different SRV Weights/Priorities instead.
>
> On Mon, Jul 6, 2020 at 3:17 AM Gerence Guan  wrote:
>
>> Hi Everyone.
>>
>> I was googling the answer for MRA failover and found this maillist.
>> Got a similar setup as Jonathan's environment.
>> Having a pair of expressway C&E in primary DC, and planning to setup
>> another pair of expressway C&E in the DR site. All MRA should go via
>> primary DC, only use DR site when primary is down.
>>
>> Can I achieve this with different priorities in SRV? Anyone tested  or
>> make it working?
>>
>> Best Regards,
>> Guan
>>
>> >>>* On Jan 28, 2020, at 8:49 PM, Jonathan Charles > >>>> wrote:
>> *>>* We have two pairs of Expressway clusters (C/E) at two different
>> *>>>* locations (primary and DR)...
>> *>>* The cluster is up, however, we want to make sure that we are in
>> *>>>* Active/Standby.
>> *>>* Currently, we have one of our SRV records for collab-edge set at 5 
>> (the
>> *>>>* backup is at 10) with the same weight.
>> *>>* The clustering guide says we should set the priority and weight on 
>> both
>> *>>>* SRV records the same, which will cause half of the registrations to go 
>> to
>> *>>>* the DR site. It is far away and has less capability.
>> *>>* How do we:
>> *>>* 1 - Make sure the primary site handles all MRA registrations and 
>> the DR
>> *>>>* site is only used when the primary is down.
>> *>>>* 2 = Make sure failover occurs automatically... currently Jabber users
>> *>>>* have to log out and back in to connect to the DR site.
>> *>>>
>>
>> ___
>> 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] Creating Jabber for non-existent phones

[Anthony Holloway]

You tease!

Just kidding, thanks for sharing this.  Did you just get this from the logs
then?  Or some other dark magic?

On Wed, Jul 1, 2020 at 11:02 PM Brian Meade  wrote:

> Lelio,
>
> I'm actually starting to work on creating some Python scripts to allow
> bulk using the Quick User/Phone Add feature such as using it to add Jabber
> devices for all users very quickly.  I'm also going to use this for bulk
> deploying Remote Destination Profiles/Device Profiles.
>
> I'm not sure if I'll share the full code or keep that internal to ePlus
> but I'll share some of my findings around how these internal/non-documented
> API's seem to be working behind the scenes.
>
> Create a DN with a specific line template:
>
> POST https:///ucmadmin/directorynumber/addDn/ HTTP/1.1
>
> Body:
>
>
> {"dnorpattern":"88","universallinetemplate":"3a63b9c6-e867-4a37-82ca-9f5ad55d515c"}
>
> 200 OK response will contain the PKID of the new Directory Number.
>
> Set Primary Extension.  Replace PKID after /enduser/ with PKID of the end
> user, fknumplan/sortorder is the important part.
> This one may be easier to set via AXL API instead.
>
> PUT https:///ucmadmin/enduser/98735c00-12d6-6e16-f985-7778d05806b1
> HTTP/1.1
>
> Body:
>
>
> {"externData":{"groupAssociations":[],"extensions":[{"pkid":"","fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","sortorder":1,"lineDirectoryURI":{"fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","directoryuri":"","fkroutepartition":"","isprimary":false}}]},"credentialInfo":{"useDefaultCredential":false,"password":null,"passwordConfirm":null,"pin":null,"pinConfirm":null},"pkid":"98735c00-12d6-6e16-f985-7778d05806b1","firstname":"Brian","middlename":"","displayname":"","lastname":"Meade","userid":"bmeade-test","fkdirectorypluginconfig":null,"fkfeaturegrouptemplate":"41128559-bd7b-93cc-1166-01acf5b5bd4d","fkucuserprofile":"b2d3d9d0-a6bd-0136-d54f-bfee73f3ed74","userRank":"1","directoryuri":"","telephonenumber":"","mailid":"","manager":"","department":""}
>
>
>
> Find a phone to move to a user.  Replace PKID in POST URI with PKID of end
> user.  Device list shows PKID of device you want to move:
>
> POST 
> https:///ucmadmin/enduser/movePhones/98735c00-12d6-6e16-f985-7778d05806b1
> HTTP/1.1
>
> Body:
>
> {"devicelist":[{"pkid":"3784d3e8-62c9-4b26-bfaa-1e7c741511bd"}]}
>
>
>
> Add a new phone for a user.  Replace PKID in POST with PKID of end user.
> Replace device template PKID with the device template you want to use.
> tkproduct is the model number from the typeproduct table.  isProfile is
> used to say it's a device profile for extension mobility:
>
> POST 
> https:///ucmadmin/enduser/addPhone/98735c00-12d6-6e16-f985-7778d05806b1
> HTTP/1.1
>
> Body:
>
>
> {"tkproduct":"30041","tkdeviceprotocol":"0","name":"SEPBMEADE","fkcommondevicetemplate":"580497c1-15e1-4e27-91ef-6f1e00f2e417","isprofile":"f","moduleCount":0}
>
>
>
> On Wed, Jul 1, 2020 at 2:06 PM Lelio Fulgenzi  wrote:
>
>>
>> Hello all. Looking for feedback and opinions and caveats.
>>
>> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
>> need to start deploying Jabber for those individuals without phones/DNs.
>>
>> Our SOPs include using Quick Add feature. (Thanks a million time Brian
>> Meade for the pointer).
>>
>> My choices so far, to address Jabber for new those without phones:
>>
>> (a) Create a fake hardware phone first. This has many benefits, namely,
>> all SOPs remain the same. Hardware phone would be deleted afterwards.
>>
>> (b) Use Directory Number admin page to create/update a DN first, then use
>> Quick Add page to assign DN to user accordingly and then click manage
>> devices and follow remaining SOP steps.
>>
>> (c) create line templates and use those when creating new extensions
>> under quick add. The issue with this is we have so many combinations, I’d
>> need a lot of templates.
>>
>> I’m leaning towards (b), since it gives me the best of both worlds.
>>
>> Thoughts?
>>
>> Lelio
>>
>> Sent from my iPhone
>> ___
>> 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] Creating Jabber for non-existent phones

[Anthony Holloway]

Yeah, I have done a bulk assignment on 2,000 users once, and it was a data
collection/juggling nightmare for me.  BATing in CSF is a cakewalk if you
start with good data.  However, getting that good data on a brownfield
that's 10 years old with a lot garbage in it is painful to say the least.

On Wed, Jul 1, 2020 at 3:38 PM Lelio Fulgenzi  wrote:

>
> We may consider adding Jabber for any new phone requested. Not sure. There
> are disadvantages to adding a feature that someone hasn’t asked for.
>
> As far as bulk load assignment, it would require significant reconciling
> and fixing of existing configurations. Not all our devices are associated
> with a user. Not all voicemails are. Not all phones match directory
> entries. Not all phones are unique 1:1 primary extensions.
>
>
> Sent from my iPhone
>
> On Jul 1, 2020, at 4:11 PM, Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> 
>
> 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
>
> I would add, why not just bulk add jabber for everyone who is licensed for
> it and then include in your normal onboarding? Does someone care if it’s
> configured and not used?
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
>
> 
> <http://www.heliontechnologies.com/>
>
> 
> <https://facebook.com/heliontech>
>
> 
> <https://twitter.com/heliontech>
>
> 
> <https://www.linkedin.com/company/helion-technologies>
>
> *From:* cisco-voip  *On Behalf Of *Anthony
> Holloway
> *Sent:* Wednesday, July 1, 2020 4:00 PM
> *To:* Lelio Fulgenzi 
> *Cc:* cisco-voip voyp list 
> *Subject:* Re: [cisco-voip] Creating Jabber for non-existent phones
>
>
>
> [EXTERNAL]
>
>
>
> Forgive my ignorance here, since I do not do day 2 ops work often (thus
> quick add's set backs are not top of mind), I mostly focus on new
> deployments, which typically involve BAT, so what is the trouble/uniqueness
> in Jabber CSF devices versus a physical phone?  Also, how come Option A
> doesn't mention the Jabber piece?  Is that implied that you would come back
> around and add Jabber afterwards, like you would do in option B, post DN
> add?
>
>
>
> On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi  wrote:
>
>
> Hello all. Looking for feedback and opinions and caveats.
>
> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
> need to start deploying Jabber for those individuals without phones/DNs.
>
> Our SOPs include using Quick Add feature. (Thanks a million time Brian
> Meade for the pointer).
>
> My choices so far, to address Jabber for new those without phones:
>
> (a) Create a fake hardware phone first. This has many benefits, namely,
> all SOPs remain the same. Hardware phone would be deleted afterwards.
>
> (b) Use Directory Number admin page to create/update a DN first, then use
> Quick Add page to assign DN to user accordingly and then click manage
> devices and follow remaining SOP steps.
>
> (c) create line templates and use those when creating new extensions under
> quick add. The issue with this is we have so many combinations, I’d need a
> lot of templates.
>
> I’m leaning towards (b), since it gives me the best of both worlds.
>
> Thoughts?
>
> Lelio
>
> Sent from my iPhone
> ___
> 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] Creating Jabber for non-existent phones

[Anthony Holloway]

Forgive my ignorance here, since I do not do day 2 ops work often (thus
quick add's set backs are not top of mind), I mostly focus on new
deployments, which typically involve BAT, so what is the trouble/uniqueness
in Jabber CSF devices versus a physical phone?  Also, how come Option A
doesn't mention the Jabber piece?  Is that implied that you would come back
around and add Jabber afterwards, like you would do in option B, post DN
add?

On Wed, Jul 1, 2020 at 1:07 PM Lelio Fulgenzi  wrote:

>
> Hello all. Looking for feedback and opinions and caveats.
>
> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
> need to start deploying Jabber for those individuals without phones/DNs.
>
> Our SOPs include using Quick Add feature. (Thanks a million time Brian
> Meade for the pointer).
>
> My choices so far, to address Jabber for new those without phones:
>
> (a) Create a fake hardware phone first. This has many benefits, namely,
> all SOPs remain the same. Hardware phone would be deleted afterwards.
>
> (b) Use Directory Number admin page to create/update a DN first, then use
> Quick Add page to assign DN to user accordingly and then click manage
> devices and follow remaining SOP steps.
>
> (c) create line templates and use those when creating new extensions under
> quick add. The issue with this is we have so many combinations, I’d need a
> lot of templates.
>
> I’m leaning towards (b), since it gives me the best of both worlds.
>
> Thoughts?
>
> Lelio
>
> Sent from my iPhone
> ___
> 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] CUC Speech Connect Ports

[Anthony Holloway]

Thanks for the reply Lelio, but no this is not specific to the voice
enabled directory handler.

This is specific to the Speech Connect ports and accompanying licenses.
This affects generated spoken names and voice enabled directory handlers.

However, I would like to update you that you can search mailboxes and
contacts in the same search.  Also, the list is updated automatically,
especially after you add alternate names for a person, though the system
does come with a built-in list of common nicknames.  E.g., Mike for Michael.

Thanks again for the reply.

PS, What sparked this question was someone configured some ports (they
didn't know what they were doing), and then removed them (because it shows
0 by default), and now CUC is broken, because the GUI removes the 2 default
ports (which cannot be seen in the GUI).

This is documented here:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt31253

In fact, the only way I have seen that you can view the defaults, is in a
protected licensing table.

*CLI Method*

admin:run cuc dbquery unitydirdb select tagname, limit, clusterwidelimit,
restartlimit, usage from tbl_licensestatus where tagname in
('LicRealspeakSessionsMax', 'LicUnityVoiceRecSessionsMax')



This 'sql_statement' is not allowed. You are not allowed to perform CRUD
operations on License Tables through CLI.

Command Failed

*CUDLI Method*
[image: image.png]

On Mon, Jun 22, 2020 at 3:26 PM Lelio Fulgenzi  wrote:

>
> Are you talking ‘bout the voice activated auto attendant?
>
> If so, we investigated and stopped a project for the amount of work
> necessary to get it working in our environment.
>
> At the time you could only search mailboxes or a contact list, not both.
> Because we had more than just mailboxes, we went with contact list.
>
> There was no way to update the list at the time so it was a delete all and
> recreate via csv or something like that.
>
> I think the interpretation was ok. So was saying the names. But your stuck
> with what you got. No grammar updates.
>
> So Guelph would be “gwelp” no matter what.
>
> We ended up going with Nuance. Which has announced EOS at end of next year
> I believe.
>
> We might revisit connection.
>
> Sent from my iPhone
>
> On Jun 22, 2020, at 12:24 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 
>
> 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
>
> I'd like to hear your personal stories.  Do you configure these?
> ___
> 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] CUC Speech Connect Ports

[Anthony Holloway]

I'd like to hear your personal stories.  Do you configure these?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Wildcard certificates

[Anthony Holloway]

I've got some thoughts, though, I've never done this before, so it's just
guessing.

You don't need *.domain.com in your SAN.

Just generate your CSR on CUCM as if you were not using wildcard
certificates.  Then when you dupe your wildcard on digitcert's site,
manually add the exact same SANs in your CSR.

The resulting identity certificate will not have a CN which matches your
CSR, but the SANs will match, and according to the thread you linked:

*"The CN doesn't match but CUCM doesn't seem to care as long as the SAN
fields line up."*

On Thu, Jun 18, 2020 at 11:58 PM James Andrewartha <
jandrewar...@ccgs.wa.edu.au> wrote:

> Hi voipers,
>
> I'm trying to update the wildcard on our CUCM/IMP servers, and am
> hitting a problem. We have a digicert wildcard, which I used
> successfully before, but now when generating the certificate the UI
> complains that *.ccgs.wa.edu.au isn't a valid certificate name or SAN. I
> hacked the javascript to ignore this warning, and generated a CSR with
> *.ccgs.wa.edu.au in the SAN:
>
> $ openssl req -in tomcat\(8\).csr -text|grep DNS
> DNS:callmanager1.voip.ccgs.wa.edu.au,
> DNS:*.ccgs.wa.edu.au, DNS:ccgs.wa.edu.au,
> DNS:speeddial.voip.ccgs.wa.edu.au, DNS:callmanager2.voip.ccgs.wa.edu.au,
> DNS:voip.ccgs.wa.edu.au, DNS:callmanager.voip.ccgs.wa.edu.au,
> DNS:presence.voip.ccgs.wa.edu.au
>
> But when I try to upload the certificate to CUCM, it complains "CSR SAN
> and Certificate SAN does not match". But the SANs on the certificate are
> the same (albeit in a different order):
>
> $ openssl x509 -in ../ssl/digicert/cucm-star_ccgs_wa_edu_au.crt -text
> |grep DNS
> DNS:*.ccgs.wa.edu.au, DNS:ccgs.wa.edu.au,
> DNS:voip.ccgs.wa.edu.au, DNS:callmanager1.voip.ccgs.wa.edu.au,
> DNS:callmanager2.voip.ccgs.wa.edu.au, DNS:speedidal.voip.ccgs.wa.edu.au,
> DNS:callmanager.voip.ccgs.wa.edu.au, DNS:presence.voip.ccgs.wa.edu.au
>
> I found
>
> https://community.cisco.com/t5/unified-communications/wildcard-certificate-on-call-manager-10-5/td-p/2757989
> from 2016 which says they got it working then, and I also got it working
> in 2018 when the cert was last renewed, with *.ccgs.wa.edu.au as the
> common name and a SAN. But I can't get it working now. Anyone got any
> thoughts? Running CUCM 10.5.2.15900-8
>
> Thanks,
>
> --
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
> ___
> 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] Consolidating access to Cisco CUCM APIs via Service Mesh

[Anthony Holloway]

Yeahstill lost.  Possibly even more than I was before.  I'll just see
myself out now.

On Tue, Jun 16, 2020 at 6:44 PM Pete Brown  wrote:

> Thanks for mentioning AutomationFX.  That’s exactly the sort of API
> consolidation I was thinking of.  Should’ve guessed the guys at UnifiedFX
> had already done something along these lines!  I’ll probably still build a
> CUCM mesh agent just to demo the marrying of access to objects & their
> associated data streams.  But it won’t be near as complete as AutomationFX.
>
>
>
> Wouldn’t say ignorant at all.  Service meshes (Istio, etc) in their
> current form have only been around a few years.  Even most developers I
> talk to haven’t really touched them beyond POCs.  Mainly due to the
> complexity since they all require the use of Kubernetes.  The concept has
> never really been applied to infrastructure sources before, especially in a
> vendor agnostic way.  In infrastructure we’re dealing with a federation of
> loosely coupled data sets instead of something that a single architecture
> group came up with.
>
>
>
> To answer the question of “why” regarding the mesh I’m working on, it’s to
> eliminate a bunch of the common pitfalls in traditional integrations.
> Instead of finding and calling each source directly using different client
> libraries, the mesh provides a single method of executing RPC & pub/sub
> operations against backend services.  You can even navigate the resources
> like a directory structure.
>
>
>
> In this mesh, the backend services register themselves and declare their
> functions, object schemas, etc.  That’s why I say it’s sort of a hybrid
> between a service mesh and a data mesh; you can call service functions or
> search on object class attributes regardless of source.  Clients who need
> to access sources make calls to the Brokers.  Very roughly analogous to a
> “meshified” version of SNMP.
>
>
>
> Here’s a before and after of what an Ansible script might look like
> calling difference sources.
>
>
>
>
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Anthony Holloway 
> *Sent: *Tuesday, June 16, 2020 3:02 PM
> *To: *Pete Brown 
> *Cc: *cisco-voip@puck.nether.net
> *Subject: *Re: [cisco-voip] Consolidating access to Cisco CUCM APIs via
> Service Mesh
>
>
>
> You lost me there, as I'm too ignorant to understand what an API mesh is,
> but this sounds very familiar to what UnifiedFX is/was doing with
> AutomationFX, is it not?  Or am I again showing my ignorance?
>
>
>
> On Tue, Jun 16, 2020 at 12:32 PM Pete Brown  wrote:
>
> TLDR – Developing a hybrid service/data mesh for interacting with
> infrastructure services.  Thinking about what a modern, consolidated API
> might look like for CUCM.
>
>
>
> I was scheduled to give this talk at DevNet Create until everything was
> shut down…
>
>
> https://github.com/adhdtech/DRP/blob/master/DevNet%20Create%202020%20-%20Making%20a%20Mesh%20of%20the%20Infrastructure.pdf
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadhdtech%2FDRP%2Fblob%2Fmaster%2FDevNet%2520Create%25202020%2520-%2520Making%2520a%2520Mesh%2520of%2520the%2520Infrastructure.pdf&data=02%7C01%7C%7Cd6a891dd87c54621067108d8123041fd%7C84df9e7fe9f640afb435%7C1%7C0%7C637279345751719757&sdata=dyBvjV7Fh1Wk6XYSOaQGqXfl65bjxthF50%2FWuEKSz54%3D&reserved=0>
>
>
>
> For the demo I had data from a few of the CUCM APIs being piped into a
> consolidated logical model.  Nothing too complex; just users, devices and
> associated JTAPI streams.  It got me to thinking, though.  If you could
> snap your fingers and have a modern, consolidated API for interacting with
> CUCM services, what would it look like?  Not just RPC operations, but
> pub/sub as well.
>
>
>
> I’m considering creating a mesh service agent for CUCM.  Instead of
> leveraging the existing APIs, the goal would be to effectively replace them
> and inject their capabilities into the mesh.  Before I do, I’m trying to
> figure out what some of the “must have” features would be for a POC.
>
>
>
> The project README needs some updating, but it does give a general idea of
> how everything works.  Recently added a command shell; need to get that
> documented.
>
> https://github.com/adhdtech/DRP
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadhdtech%2FDRP&data=02%7C01%7C%7Cd6a891dd87c54621067108d8123041fd%7C84df9e7fe9f640afb435%7C1%7C0%7C637279345751729741&sdata=%2BayXqiSdtWHtbnS5ZsAfS1k3cU%2BZ3rLo59oA1NtX3nA%3D&reserved=0>
>
>
>
> -Pete
>
>
&

Re: [cisco-voip] CUBE Config Dial Peers

[Anthony Holloway]

There's literally no single best practice.  You build it how you need to.

No matter what you build, I bet someone could pick it apart.  The only
question you need to ask yourself is: does it meet the requirements?  If it
does, then great.  If not, change it.

Nothing needs to be built initially for the highest optimizations or
biggest scale or longest survivability.  It's ok for designs to evolve over
time.

On Tue, Jun 16, 2020 at 5:13 PM Loren Hillukka 
wrote:

> Getting a little off the “cube config” topic... if there are others with
> Best practices, tried and true config snippets it’d be nice to see.  If you
> don’t like server groups to reduce dial-peers you can resort to dns srv
> (even local!)
>
> But I have to say the first time I saw Nate’s CUCM/GW design I thought he
> was crazy. Route filters My first experience with them in 2003 wasn’t
> pleasant.  However, the method used to build, insert, and update them is
> what changed my thinking from “you’re crazy” to appreciating the logic
> behind the final product.
> I would never want to build something with that extensive NPA/NXX
> dialing/TEHO out by hand...
>
> Loren
>
> On Jun 16, 2020, at 4:31 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 
> I don't know what it is, but COR list people are also @ route filter
> people.  Nailed it.
>
> *"I think having NPA/NXX route patterns would be just too much to look
> at."*
>
> 
>
>
> There's a reason the SRND/PA/CVD isn't based off of the @ macro.
>
> *"But I just don’t see the point of completely ignoring the call routing
> engine in CUBE"*
>
> So, you must be against matching incoming legs on Via header too, as
> opposed to incoming called number?
>
> Lastly, you should know that you're wrong about these two points you made:
>
> *"If you have two destinations in the group, it just round-robins them"*
> *"...and just say if it comes in this dial-peer send it out any random one
> of these"*
>
> 
>
>
> On Tue, Jun 16, 2020 at 4:05 PM NateCCIE  wrote:
>
>> No more 9.@, I use \+.@ now.  I think having NPA/NXX route patterns
>> would be just too much to look at.  I do wish that route filters could be
>> longer than 1024 characters.
>>
>>
>>
>> But I just don’t see the point of completely ignoring the call routing
>> engine in CUBE and just say if it comes in this dial-peer send it out any
>> random one of these.  It doesn’t work with anything but the simplest of
>> configs, and I really appreciate a base config that works for everything
>> and can be expanded upon.  More and more when I keep things consistent
>> between deployments, I am quicker at figuring out what’s broken and can fix
>> it quickly, and customers are amazed that I remembered their system.
>>
>>
>>
>> 
>>
>> 
>>
>>
>>
>> *From:* Anthony Holloway 
>> *Sent:* Tuesday, June 16, 2020 1:56 PM
>> *To:* NateCCIE 
>> *Cc:* Loren Hillukka ; Cisco VoIP Group <
>> cisco-voip@puck.nether.net>
>> *Subject:* Re: [cisco-voip] CUBE Config Dial Peers
>>
>>
>>
>> "I cannot stand DPG"
>>
>> "I use cor-list"
>>
>>
>>
>> I bet you also are a sadist and use 9.@ too.  You and Lelio should form
>> a posse and fight Brian and I.  The losers must convert to the other's
>> design.
>>
>>
>>
>> On Tue, Jun 16, 2020 at 12:17 PM NateCCIE  wrote:
>>
>> Well once Loren speaks up you know it’s an interesting thread.
>>
>>
>>
>> My two cents, I cannot stand DPG.  Its crazy that it completely ignores
>> destination pattern.  If you have two destinations in the group, it just
>> round-robins them.  I got burned not understanding that DPG didn’t look at
>> destination pattern and I swore I would never use them again.
>>
>>
>>
>> I use cor-list to restrict the SP inbound dial-peer to the cucm outbound
>> dial-peer, and vice versa.  Matching the inbound dial-peer by URI works
>> great, I started with matching “FROM” but that fell apart in some cases, so
>> I use VIA by default now, and that has been solid.
>>
>>
>>
>> My numbering is usually 1X for CUCM, with the 0 for inbound in each
>> range, then 2X for the first SIP provider and 3X for the 2nd, maybe 5X
>> for CVP etc.
>>
>>
>>
>> I always localize on the CUBE, sending a full +E.164 from CUCM and then
>> use translation profiles to format to how the specific country/carrier
>> wants to see the calls.  The exception is US 11

Re: [cisco-voip] Consolidating access to Cisco CUCM APIs via Service Mesh

[Anthony Holloway]

You lost me there, as I'm too ignorant to understand what an API mesh is,
but this sounds very familiar to what UnifiedFX is/was doing with
AutomationFX, is it not?  Or am I again showing my ignorance?

On Tue, Jun 16, 2020 at 12:32 PM Pete Brown  wrote:

> TLDR – Developing a hybrid service/data mesh for interacting with
> infrastructure services.  Thinking about what a modern, consolidated API
> might look like for CUCM.
>
>
>
> I was scheduled to give this talk at DevNet Create until everything was
> shut down…
>
>
> https://github.com/adhdtech/DRP/blob/master/DevNet%20Create%202020%20-%20Making%20a%20Mesh%20of%20the%20Infrastructure.pdf
>
>
>
> For the demo I had data from a few of the CUCM APIs being piped into a
> consolidated logical model.  Nothing too complex; just users, devices and
> associated JTAPI streams.  It got me to thinking, though.  If you could
> snap your fingers and have a modern, consolidated API for interacting with
> CUCM services, what would it look like?  Not just RPC operations, but
> pub/sub as well.
>
>
>
> I’m considering creating a mesh service agent for CUCM.  Instead of
> leveraging the existing APIs, the goal would be to effectively replace them
> and inject their capabilities into the mesh.  Before I do, I’m trying to
> figure out what some of the “must have” features would be for a POC.
>
>
>
> The project README needs some updating, but it does give a general idea of
> how everything works.  Recently added a command shell; need to get that
> documented.
>
> https://github.com/adhdtech/DRP
>
>
>
> -Pete
>
>
> ___
> 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] CUBE Config Dial Peers

[Anthony Holloway]

"I cannot stand DPG"
"I use cor-list"

I bet you also are a sadist and use 9.@ too.  You and Lelio should form a
posse and fight Brian and I.  The losers must convert to the other's design.

On Tue, Jun 16, 2020 at 12:17 PM NateCCIE  wrote:

> Well once Loren speaks up you know it’s an interesting thread.
>
>
>
> My two cents, I cannot stand DPG.  Its crazy that it completely ignores
> destination pattern.  If you have two destinations in the group, it just
> round-robins them.  I got burned not understanding that DPG didn’t look at
> destination pattern and I swore I would never use them again.
>
>
>
> I use cor-list to restrict the SP inbound dial-peer to the cucm outbound
> dial-peer, and vice versa.  Matching the inbound dial-peer by URI works
> great, I started with matching “FROM” but that fell apart in some cases, so
> I use VIA by default now, and that has been solid.
>
>
>
> My numbering is usually 1X for CUCM, with the 0 for inbound in each range,
> then 2X for the first SIP provider and 3X for the 2nd, maybe 5X for CVP
> etc.
>
>
>
> I always localize on the CUBE, sending a full +E.164 from CUCM and then
> use translation profiles to format to how the specific country/carrier
> wants to see the calls.  The exception is US 11D/10D determination is done
> by the CUCM because I find it easier to load all of the local NPA-NXX into
> CUCM route filters via AXL, but then sometimes I am doing TEHO and have to
> control which outbound dial-peer it chooses.
>
>
>
> I also never let the CUBE choose the carrier, I think mostly because a
> long time ago I had the same carrier spread over multiple gateways along
> with multiple carriers in each gateway, and I wanted CUCM to re-route to
> the other gateway same carrier before CUBE used a less preferred route
> because it was local.  So when there is multiple carriers I usually will
> prefix 1#* or 2#* on up for each carrier.
>
>
>
> Anyway, that’s my 2 cents.
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *Loren
> Hillukka
> *Sent:* Tuesday, June 16, 2020 10:26 AM
> *To:* Anthony Holloway 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] CUBE Config Dial Peers
>
>
>
> Nice to see the examples and explanations - thank you!  I really like the
> naming structure to allow simple a show command to pull everything related
> to one side of the call flow.
>
> URI matching broke down in UCCE environments as uri match overrides all
> other matching.  I needed to match some ingress numbers from the ITSP to
> apply CVP .tcl scripts too and wasn’t able to when matching all inbound
> from ITSP via URI.  So the config gets a bit longer in UCCE environments
> due to this.
>
> I ended up using e164-pattern-maps as another means of collapsing
> dial-peers, with uri match for calls from CUCM, and also server-groups to
> reduce outbound peers.
>
> Based on the configs from Brian and Anthony, you wouldn’t need
> e164-pattern-maps in those environments.  Curious what direction others
> have taken to simplify dial-peers with UCCE in play.
>
>
>
> Loren
>
>
>
> On Jun 16, 2020, at 10:55 AM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 
>
> Sorry, transmission failed.  Try disabling NSF and re-sending.
>
>
>
> Back to the point of ABC123, it would be so nice if we could add comments
> to the show run.  Second best is to keep a commented copy of the config off
> box in your documentation repository.
>
>
>
> On Mon, Jun 15, 2020 at 11:31 PM Brian Meade  wrote:
>
> Anthony,
>
>
>
> I like the config.  Definitely is nice to have some standardization on the
> dial-peer tags.  I've usually done all my inbound dial-peers in the 1XX
> range but have gone outside of that lately with separating inbound ITSP and
> inbound CUCM dial-peers to make them more obvious but I like the idea of
> having more structure like yours.
>
>
>
> Using the destination-pattern ABC123 is a great idea to show that's not
> used as mentioned before.
>
>
>
> I try to always use voice-class codec for every dial-peer even if I've
> only got 1 codec configured there just to make it easier to change if ever
> needed but that was in the past when I had separate local/long
> distance/911/international/10-digit dial-peers.  Simplifying it down to a
> single inbound/outbound dial-peer with the ITSP makes it a toss-up if that
> helps anymore.
>
>
>
> I've tried to keep KPML on my ITSP facing dial-peers just in case they
> happen to support it.  I've found some say they don't but actually do use
> it if you advertise it.  No harm in advertising it from ou

Re: [cisco-voip] CUBE Config Dial Peers

[Anthony Holloway]

Yeah so in that case, ditch the URI matching and go with phone numbers.
That's perfectly fine.  I don't think anyone was saying that it's the only
way to do it.  It's just the simplest, for the simplest cases.  More
complex environment require more complex configurations.  You may even end
up mixing the solutions within the same CUBE, as you've articulated with
using URI matching for CUCM peers.

You might have noticed in my reply this commentary:

"Most I ever used was like 15 i think.  E.g., 2215  But that was not using
IP addresses in the matching and DPGs, that was using phone number
matching, and I was using steering codes."

This is clearly an indication that the design must match the requirements,
and there's not a one size fits all approach.

On Tue, Jun 16, 2020 at 11:26 AM Loren Hillukka 
wrote:

> Nice to see the examples and explanations - thank you!  I really like the
> naming structure to allow simple a show command to pull everything related
> to one side of the call flow.
> URI matching broke down in UCCE environments as uri match overrides all
> other matching.  I needed to match some ingress numbers from the ITSP to
> apply CVP .tcl scripts too and wasn’t able to when matching all inbound
> from ITSP via URI.  So the config gets a bit longer in UCCE environments
> due to this.
> I ended up using e164-pattern-maps as another means of collapsing
> dial-peers, with uri match for calls from CUCM, and also server-groups to
> reduce outbound peers.
> Based on the configs from Brian and Anthony, you wouldn’t need
> e164-pattern-maps in those environments.  Curious what direction others
> have taken to simplify dial-peers with UCCE in play.
>
> Loren
>
> On Jun 16, 2020, at 10:55 AM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 
> Sorry, transmission failed.  Try disabling NSF and re-sending.
>
> Back to the point of ABC123, it would be so nice if we could add comments
> to the show run.  Second best is to keep a commented copy of the config off
> box in your documentation repository.
>
> On Mon, Jun 15, 2020 at 11:31 PM Brian Meade  wrote:
>
>> Anthony,
>>
>> I like the config.  Definitely is nice to have some standardization on
>> the dial-peer tags.  I've usually done all my inbound dial-peers in the 1XX
>> range but have gone outside of that lately with separating inbound ITSP and
>> inbound CUCM dial-peers to make them more obvious but I like the idea of
>> having more structure like yours.
>>
>> Using the destination-pattern ABC123 is a great idea to show that's not
>> used as mentioned before.
>>
>> I try to always use voice-class codec for every dial-peer even if I've
>> only got 1 codec configured there just to make it easier to change if ever
>> needed but that was in the past when I had separate local/long
>> distance/911/international/10-digit dial-peers.  Simplifying it down to a
>> single inbound/outbound dial-peer with the ITSP makes it a toss-up if that
>> helps anymore.
>>
>> I've tried to keep KPML on my ITSP facing dial-peers just in case they
>> happen to support it.  I've found some say they don't but actually do use
>> it if you advertise it.  No harm in advertising it from our side.
>>
>> I like the aliases you've got there as well.  I feel like I'm always on
>> some random customer's box so not sure I'd remember to always put them in
>> first but definitely nice to have when you make the full CUBE config.
>>
>> Looks like all you're missing is your fax config!  I can fax that over to
>> you! :)
>>
>> On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> All great points, thanks for taking the time to respond.
>>>
>>> The only one I think that I need to reply to is the DPG and
>>> destination-pattern one.  I was actually troubleshooting a customer CUBE
>>> wherein this exact scenario was in place and the only negative was getting
>>> options to work.  Otherwise, it was routing the call just fine.  Granted, I
>>> couldn't tell you what version that was, as it was like a year or so ago,
>>> but either way, I always put a destination-pattern on because you need one
>>> for options to function.
>>>
>>> I guess I could reply to one more, and that has to do with tweaking
>>> retries from 6 to 2 AND using options.  Why stick to one, when you can do
>>> both?
>>>
>>> Here's the one I use which I said was very similar to yours.
>>>
>>> The first thing to note is the numeric 

Re: [cisco-voip] CUBE Config Dial Peers

[Anthony Holloway]

Sorry, transmission failed.  Try disabling NSF and re-sending.

Back to the point of ABC123, it would be so nice if we could add comments
to the show run.  Second best is to keep a commented copy of the config off
box in your documentation repository.

On Mon, Jun 15, 2020 at 11:31 PM Brian Meade  wrote:

> Anthony,
>
> I like the config.  Definitely is nice to have some standardization on the
> dial-peer tags.  I've usually done all my inbound dial-peers in the 1XX
> range but have gone outside of that lately with separating inbound ITSP and
> inbound CUCM dial-peers to make them more obvious but I like the idea of
> having more structure like yours.
>
> Using the destination-pattern ABC123 is a great idea to show that's not
> used as mentioned before.
>
> I try to always use voice-class codec for every dial-peer even if I've
> only got 1 codec configured there just to make it easier to change if ever
> needed but that was in the past when I had separate local/long
> distance/911/international/10-digit dial-peers.  Simplifying it down to a
> single inbound/outbound dial-peer with the ITSP makes it a toss-up if that
> helps anymore.
>
> I've tried to keep KPML on my ITSP facing dial-peers just in case they
> happen to support it.  I've found some say they don't but actually do use
> it if you advertise it.  No harm in advertising it from our side.
>
> I like the aliases you've got there as well.  I feel like I'm always on
> some random customer's box so not sure I'd remember to always put them in
> first but definitely nice to have when you make the full CUBE config.
>
> Looks like all you're missing is your fax config!  I can fax that over to
> you! :)
>
> On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> All great points, thanks for taking the time to respond.
>>
>> The only one I think that I need to reply to is the DPG and
>> destination-pattern one.  I was actually troubleshooting a customer CUBE
>> wherein this exact scenario was in place and the only negative was getting
>> options to work.  Otherwise, it was routing the call just fine.  Granted, I
>> couldn't tell you what version that was, as it was like a year or so ago,
>> but either way, I always put a destination-pattern on because you need one
>> for options to function.
>>
>> I guess I could reply to one more, and that has to do with tweaking
>> retries from 6 to 2 AND using options.  Why stick to one, when you can do
>> both?
>>
>> Here's the one I use which I said was very similar to yours.
>>
>> The first thing to note is the numeric structure of my tags.
>>
>> 1000 series numbers are the ITSP side
>> 2000 series numbers are the CUCM side
>>
>> I would expand this to 3000, 4000, etc., for additional integrations like
>> PRIs, FXO, second ITSP, second PBX, etc.  Most I ever had was 6
>> integrations into a single CUBE i think.
>>
>> The second digit is 1 for incoming and 2 for outgoing.
>>
>> The 4rd and fourth digit are generally not used, unless I need additional
>> dial-peers for the same peer and direction, but doing something slightly
>> different.  Most I ever used was like 15 i think.  E.g., 2215  But that was
>> not using IP addresses in the matching and DPGs, that was using phone
>> number matching, and I was using steering codes.
>>
>> This numbering structure allows me to do something like this:
>>
>> show run | section 12..
>>
>> Which would then show me the following all at once: URI, Server Group,
>> Profile and Dial Peers all pertaining to the outgoing ITSP leg.
>>
>> Also, in this example, we pass +E164 through the gateway
>> bi-directionally, so no digit manip needed.
>>
>> voice class uri 1100 sip
>>  host ipv4:8.8.8.8
>>  host ipv4:9.9.9.9
>> !
>> voice class server-group 1200
>>  description ITSP Peers
>>  ipv4 8.8.8.8 preference 1
>>  ipv4 9.9.9.9 preference 2
>> !
>> voice class sip-options-keepalive 1200
>>  description ITSP Peers (Intentionally Left Blank)
>> !
>> voice class uri 2100 sip
>>  host ipv4:10.1.1.2
>>  host ipv4:10.1.1.3
>> !
>> voice class server-group 2200
>>  description CUCM Nodes
>>  ipv4 10.1.1.2 preference 1
>>  ipv4 10.1.1.3 preference 2
>> !
>> voice class sip-options-keepalive 2200
>>  description CUCM Nodes (Intentionally Left Blank)
>> !
>> voice class dpg 1200
>>  dial-peer 1200
>> !
>> voice class dpg 2200
>>  dial-peer 2200
>> !
>> dial-

Re: [cisco-voip] [EXTERNAL] Re: CUBE Config Dial Peers

[Anthony Holloway]

It's not wrong to do digit manipulation on the CUBE, I just chose not to,
since it didn't make sense to me to make the CUBE configuration any more
complex, and CUCM is perfectly suited for digit manipulations.

Consider posting your config for review.  :)

On Sat, Jun 13, 2020 at 8:26 AM JASON BURWELL 
wrote:

> Thanks Brian an Anthony for all the great information and examples. My
> config does not look anything like this so it looks like I’ve got some work
> ahead of me. I’m glad to see no digit manipulation is needed in the
> example. I’ve been told that we have to do digit manipulation on the CUBE
> which I questioned and part of what led me to ask here.
>
>
>
> Jason
>
>
>
>
>
> *From:* Anthony Holloway 
> *Sent:* Friday, June 12, 2020 8:53 PM
> *To:* Brian Meade 
> *Cc:* JASON BURWELL ;
> cisco-voip@puck.nether.net
> *Subject:* [EXTERNAL] Re: [cisco-voip] CUBE Config Dial Peers
>
>
>
> *CAUTION: This email originated outside of Founders Federal Credit Union.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.*
> * -- *
>
> All great points, thanks for taking the time to respond.
>
>
>
> The only one I think that I need to reply to is the DPG and
> destination-pattern one.  I was actually troubleshooting a customer CUBE
> wherein this exact scenario was in place and the only negative was getting
> options to work.  Otherwise, it was routing the call just fine.  Granted, I
> couldn't tell you what version that was, as it was like a year or so ago,
> but either way, I always put a destination-pattern on because you need one
> for options to function.
>
>
>
> I guess I could reply to one more, and that has to do with tweaking
> retries from 6 to 2 AND using options.  Why stick to one, when you can do
> both?
>
>
>
> Here's the one I use which I said was very similar to yours.
>
>
>
> The first thing to note is the numeric structure of my tags.
>
>
>
> 1000 series numbers are the ITSP side
>
> 2000 series numbers are the CUCM side
>
>
>
> I would expand this to 3000, 4000, etc., for additional integrations like
> PRIs, FXO, second ITSP, second PBX, etc.  Most I ever had was 6
> integrations into a single CUBE i think.
>
>
>
> The second digit is 1 for incoming and 2 for outgoing.
>
>
>
> The 4rd and fourth digit are generally not used, unless I need additional
> dial-peers for the same peer and direction, but doing something slightly
> different.  Most I ever used was like 15 i think.  E.g., 2215  But that was
> not using IP addresses in the matching and DPGs, that was using phone
> number matching, and I was using steering codes.
>
>
>
>
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUBE Config Dial Peers

[Anthony Holloway]

 that look cleaner.
> 4. Why didn't you should your translation profiles and rules too?
> These seem to be so customer/SIP carrier specific that I didn't think it
> was worth it.  My most recent one had 80 rules in it because the carrier
> really cares about 10-digit/11-digit calling for the local area code.  So
> we actually had to split it up for different NPA-NXX whether or not we
> added a 1.
> 5. I don't specify UDP as the transport, since it's the default, but
> again, being explicit doesn't hurt anything
> I also make UDP my default but it is nice to have it called out in a
> template so people know where to change it if needed.
> 6. I like the extra dtmf on there.  too many configs are limited to
> rtp-nte only and mtps are being invoked for every call to UCCX as one
> example
> Yea, I always add both to make sure we never have to pull in an MTP.  I'm
> not aware of a way to do this globally but would be nice.
> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard?  I
> might learn something here, as faxing is not my strongest area.
> I'm always debugging faxing it seems like.  Disabling ECM and reducing
> speed to 9600 has seemed to help a lot over the years.  It's slower but
> seems to work more reliably with every source/destination fax device.  And
> people don't expect their fax to send quickly anyways.
> 8. Since you're doing DPGs, you don't need the destination-pattern .T
> command on the outbound DPs.
> It seems like IOS-XE will show a dial-peer as down and skip it if there is
> no destination-pattern configured.  This looks to be called out as
> explicitely required here even though it isn't used-
> https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
>
> Using something like ABC123 for the destination-pattern may make more
> sense to not confuse anyone.  Good call.
> 9a. Why are you not doing sip options ping?  I would, and in which case
> you need a voice class sip options-keepalive profile
> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
>  since
> you're using server groups.
> I've never been a fan of SIP Options ping.  I've always used SIP timers
> for failover instead.  I guess I've had a few outages where waiting for
> Options Ping to come back up after we fixed the underlying issue added
> additional delay.  For monitoring purposes though, it probably is a good
> idea to get back into doing that for customers where we're monitoring their
> CUBEs.
> 9b. Also, if you do end up turning on options, you do in fact need a
> destination-pattern command, and in which case, since it's not being used
> for call routing, I just use like ABC123 as the pattern to ensure it never
> can be used, but also, mildly clear it's not supposed to be used
> I like that idea and referenced it in 8 above.
>
>
>
> On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Brian,
>>
>> Nice and clean, I like it!  Very similar to what I do.  I'd like to
>> comment/question yours a bit.
>>
>> 1. While I like that you can give a uri profile a name like ISP, I much
>> prefer to stick with numbers, since for most things, you must use numbers
>> when naming, so this keeps it consistent.
>> 2. I don't specify the port in my server groups, since 5060 is default,
>> but I can see how it might help be more explicit for some people
>> 3. Speaking of being explicit though, if that is your intention, I would
>> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>> 4. Why didn't you should your translation profiles and rules too?
>> 5. I don't specify UDP as the transport, since it's the default, but
>> again, being explicit doesn't hurt anything
>> 6. I like the extra dtmf on there.  too many configs are limited to
>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>> example
>> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard?
>> I might learn something here, as faxing is not my strongest area.
>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>> command on the outbound DPs.
>> 9a. Why are you not doing sip options ping?  I would, and in which case
>> you need a voice class sip options-keepalive profile
>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
>> since you're using server groups.
>> 9b. Also, if you

Re: [cisco-voip] CUBE Config Dial Peers

[Anthony Holloway]

Brian,

Nice and clean, I like it!  Very similar to what I do.  I'd like to
comment/question yours a bit.

1. While I like that you can give a uri profile a name like ISP, I much
prefer to stick with numbers, since for most things, you must use numbers
when naming, so this keeps it consistent.
2. I don't specify the port in my server groups, since 5060 is default, but
I can see how it might help be more explicit for some people
3. Speaking of being explicit though, if that is your intention, I would
recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
4. Why didn't you should your translation profiles and rules too?
5. I don't specify UDP as the transport, since it's the default, but again,
being explicit doesn't hurt anything
6. I like the extra dtmf on there.  too many configs are limited to rtp-nte
only and mtps are being invoked for every call to UCCX as one example
7. Why do you drop your fax rate down from 14400 to 9600 as a standard?  I
might learn something here, as faxing is not my strongest area.
8. Since you're doing DPGs, you don't need the destination-pattern .T
command on the outbound DPs.
9a. Why are you not doing sip options ping?  I would, and in which
case you need
a voice class sip options-keepalive profile

since you're using server groups.
9b. Also, if you do end up turning on options, you do in fact need a
destination-pattern command, and in which case, since it's not being used
for call routing, I just use like ABC123 as the pattern to ensure it never
can be used, but also, mildly clear it's not supposed to be used

I'll post a config as well, in a bit, and please feel free to
comment/question mine.




On Fri, Jun 12, 2020 at 3:20 PM Brian Meade  wrote:

> I've been trying to make a standardized CUBE configuration using a lot of
> the newer features like dial-peer groups.
>
> This is what I have now.  It's an inbound dial-peer for CUCM matching the
> CUCM IP's via Via header.  Then an inbound dial-peer for the ISP.  Then an
> outbound dial-peer to CUCM and an outbound dial-peer to the ISP.  If you
> have more IP's for the ISP or CUCM, you can easily add them.
> destination-pattern .T is not used at all due to using dial-peer group
> matching.  This doesn't account for bindings that must be done per
> dial-peer.  It also doesn't show translation-profiles/rules.
>
> This gives you 4 total dial-peers to match any number.
>
> If it comes in from CUCM, it will route to the SIP carrier.  If it comes
> in from the SIP carrier, it will route to CUCM.
>
> voice class uri ISP sip
>  host ipv4:8.8.8.8
>
> voice class uri CUCM sip
>  host ipv4:192.168.100.100
>  host ipv4:192.168.100.200
>
> voice class server-group 100
>  ipv4 8.8.8.8 port 5060
>
> voice class server-group 200
>  ipv4 192.168.100.100 port 5060
>  ipv4 192.168.100.200 port 5060 preference 1
>
> voice class dpg 100
>
> voice class dpg 200
>
> dial-peer voice 100 voip
>  description Incoming Dial-peer from ISP
>  translation-profile incoming ISPInbound
>  session protocol sipv2
>  session transport udp
>  destination dpg 200
>  incoming uri via ISP
>  voice-class codec 1
>  dtmf-relay rtp-nte sip-kpml
>  fax-relay ecm disable
>  fax rate 9600
>
> dial-peer voice 200 voip
>  description Incoming Dial-peer from CUCM
>  session protocol sipv2
>  destination dpg 100
>  incoming uri via CUCM
>  voice-class codec 1
>  dtmf-relay rtp-nte sip-kpml
>  fax-relay ecm disable
>  fax rate 9600
>
> dial-peer voice 300 voip
>  description Outbound to ISP
>  translation-profile outgoing ISPOutbound
>  destination-pattern .T
>  session protocol sipv2
>  session transport udp
>  session server-group 100
>  voice-class codec 1
>  dtmf-relay rtp-nte sip-kpml
>  fax-relay ecm disable
>  fax rate 9600
>
> dial-peer voice 400 voip
>  description Outbound to CUCM
>  destination-pattern .T
>  session protocol sipv2
>  session server-group 200
>  voice-class codec 1
>  dtmf-relay rtp-nte sip-kpml
>  fax-relay ecm disable
>  fax rate 9600
>
> voice class dpg 100
>  dial-peer 300
>
> voice class dpg 200
>  dial-peer 400
>
> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
> cisco-voip@puck.nether.net> wrote:
>
>> Does anyone have a good, straightforward reference doc to configuring
>> CUBE dial peers? I have what I would have thought should be a fairly basic
>> config but I’m having trouble getting everything to work properly. I’ve had
>> some assistance but it seems like a whole lot of configuration to do what
>> little I really need to do. Basically, I just need to send whatever comes
>> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
>> inbound calls the provider sends me 10 digits in the invite, I just need to
>> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
>> adding and stripping digits going on between CUCM and CUBE to make this
>> work. Just try

Re: [cisco-voip] UCCX Flex Licensing

[Anthony Holloway]

Thanks for the action and the update.  Is the Flex PM, Kevin McPartlan, on
that webcast?

On Thu, Jun 11, 2020 at 11:59 AM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> I’m on a partner webcast now and asking about this. If you have premium
> flex licensing even the built-in admin requires a license!  I’m beating
> them up on this as it’s still not documented anywhere and I’ve got
> customers on flex that will have issues when upgrading to 12.5
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Tuesday, May 12, 2020 1:22 PM
> *To:* Matthew Loraditch 
> *Cc:* Pawlowski, Adam ; Cisco VoIP Group <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] UCCX Flex Licensing
>
>
>
> [EXTERNAL]
>
>
>
> Thank you for the testing you're doing, and I look forward to the results.
>
>
>
> On Tue, May 12, 2020 at 9:57 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> So I was basing this on documentation and my colleague saying we were good
> after our admin account was de-supervisored
>
>
>
> However I am seeing contrary information in the one 12.5 install we have.
> CCX doesn’t have an auto update button/function so I’m waiting for things
> to cycle to verify
>
>
>
> Further though the documentation does not say this at all:
>
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_12_5/features/guide/uccx_b_125features-guide/uccx_b_125features-guide_chapter_0111.html
>
>
>
> Nor the ordering guide (partners only):
> https://www.cisco.com/c/en/us/products/collateral/customer-collaboration/guide-c07-741219.html
>
>
>
> And that is some garbage if true and needs to be fixed.
>
>
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Tuesday, May 12, 2020 10:29 AM
> *To:* Matthew Loraditch 
> *Cc:* Pawlowski, Adam ; Cisco VoIP Group <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] UCCX Flex Licensing
>
>
>
> [EXTERNAL]
>
>
>
> Matthew,
>
>
>
> I just got word from the Flex-CC owner, Kevin McPartlan, that Admins do
> require a Premium license.  Can you prove this wrong in some way?
>
>
>
> On Mon, May 11, 2020 at 4:36 PM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> A-FLEX-CC has Standard and Premium Licenses.
>
>
>
> These are different from non flex licensing.
>
>
>
> Standard is inbound agent licensing essentially
>
>
>
> Premium is supervisor licensing,   email/chat agents, outbound campaign
> licensing.
>
>
>
> 2 CTI ports per agent/license.
>
>
>
> Admin still works no specific license needed as long as admin isn’t also
> supervisor/agent, HA is included, outside of the 3 features above, it’s
> like perpetual premium with SQL, etc included.
>
>
>
> See here for specifics:
>
>
>
>
> https://www.cisco.com/c/en/us/products/collateral/unified-communications/cisco-collaboration-flex-plan/datasheet-c78-741220.html
> Table 8.
>
>
>
>
>
> License enforcement is only in UCCX 12.5. Older versions don’t know and
> you end up with Perpetual Premium with HA feature set but with a license
> that expires at the end of your contract term.
>
>
>
> Suffice it to say if you don’t need 12.5 features you could ride the gravy
> train for a while.
>
>
>
> Licensing is still concurrent users.
>
>
>
> There are grace periods so if you need to test something you can make the
> admin a supervisor or something w/o breakage, just remember to remove later.
>
>
>
> If your customer has on-prem premium, with perpetual trade-i

Re: [cisco-voip] SX80 Camera Tracking and Face Masks

[Anthony Holloway]

My mind was wandering, but I arrived there all on my own.  Thanks for
confirming it wasn't just all in my head.

On Tue, Jun 9, 2020 at 11:10 PM Lelio Fulgenzi  wrote:

>
> Sorry. I forgot to add something. If it wasn’t obvious, the camera diag
> identified our crotches as faces. Green squares and all.
>
> Sent from my iPhone
>
> On Jun 9, 2020, at 8:00 PM, Lelio Fulgenzi  wrote:
>
> 
>
> When I tested a roomkit mini under diagnostics, the camera identified four
> faces.
>
> There were only two of us.
>
> We both were wearing jeans and had our legs crossed.
>
> This was reproducible without fail.
>
> ¯\_(ツ)_/¯
>
> Sent from my iPhone
>
> On Jun 9, 2020, at 1:30 PM, ROZA, Ariel 
> wrote:
>
> 
>
> 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
>
> Hi Guys,
>
>
>
> Did anyone experience problems with speaker tracking while people using
> facemasks?
>
> I received reports from people that verified lack of tracking while using
> a mask, and that it works properly when they take them off.
>
> This is not weird, and somehow expected. But wanted to know if there´s any
> kind of solution/fix/workaround.
>
> Tried looking for bugs in the BST, but does not show anything for SX80
>
>
>
> Regards,
>
>
>
>
>
> 
> *Ariel Roza*
> *Support & Maintenance* *Engineer** | Latam*
>
> t: +54 11 5282-0458 / c: +54 11 5017-4417 / webex:
> https://logicalis-la.webex.com/join/ariel.roza
>
> Av. Belgrano 955 – Piso 20 – CABA – Argentina – C1092AAJ
>
> www.la.logicalis.com
>
> *Business **and technology working as one*
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> 
>
> Logicalis Argentina S.A. solo puede ser obligado por sus representantes
> legales conforme los límites establecidos en el acto constitutivo y la
> legislación en vigor.
>
> El contenido del presente correo electrónico e inclusive sus anexos
> contienen información confidencial.
>
> El mismo no puede ser divulgado y/o utilizado por cualquiera otro distinto
> al destinatario, ni puede ser copiado de cualquier forma
>
>
> ___
> 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 mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] 7900 Factory Reset w/out connecting to the network

[Anthony Holloway]

Will it blend?

On Mon, Jun 8, 2020 at 4:21 PM Charles Goldsmith  wrote:

> No DHCP is needed, don't even need a live network to reset, just need power
>
> you only need option 150 if you want it to try and update firmware, and of
> course, it needs a phone config on CUCM to do that
>
> for what a 7970 is worth as trade in or resell, it's too much work, a
> hammer works better/faster :)
>
>
> On Mon, Jun 8, 2020 at 4:12 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Adam,  I've always been under the impression that either of these options
>> require DHCP Option 150 with a working TFTP and files to work properly.
>> Are you saying they don't?  I've never tested it though.
>>
>>
>> On Mon, Jun 8, 2020 at 3:26 PM Pawlowski, Adam  wrote:
>>
>>> Sean,
>>>
>>>
>>>
>>> The two codes for it, are to hold the pound key when powering it on.
>>>
>>>
>>>
>>> When the line keys flash, key go of pound and enter: 123456789*0# ,
>>> which should erase the configuration.
>>>
>>>
>>>
>>> If you observe that it is still showing internal information, try
>>> 3491672850*# , which in my experience rips it down to a bootstrap, but,
>>> I’ve never loaded the term default on it to see if there’s anything left by
>>> the time it recovers.
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> Adam
>>>
>>>
>>>
>>> *From:* cisco-voip  *On Behalf Of 
>>> *Riley,
>>> Sean
>>> *Sent:* Monday, June 8, 2020 3:59 PM
>>> *To:* cisco-voip@puck.nether.net
>>> *Subject:* [cisco-voip] 7900 Factory Reset w/out connecting to the
>>> network
>>>
>>>
>>>
>>> We are finally refreshing our 7970’s.  We wanted to factory reset the
>>> old phones before sending out for scrap.  Is there a way to factory reset
>>> without having to connect to the network?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Sean.
>>> ___
>>> 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] 7900 Factory Reset w/out connecting to the network

[Anthony Holloway]

Adam,  I've always been under the impression that either of these options
require DHCP Option 150 with a working TFTP and files to work properly.
Are you saying they don't?  I've never tested it though.


On Mon, Jun 8, 2020 at 3:26 PM Pawlowski, Adam  wrote:

> Sean,
>
>
>
> The two codes for it, are to hold the pound key when powering it on.
>
>
>
> When the line keys flash, key go of pound and enter: 123456789*0# , which
> should erase the configuration.
>
>
>
> If you observe that it is still showing internal information, try
> 3491672850*# , which in my experience rips it down to a bootstrap, but,
> I’ve never loaded the term default on it to see if there’s anything left by
> the time it recovers.
>
>
>
> Best,
>
>
>
> Adam
>
>
>
> *From:* cisco-voip  *On Behalf Of *Riley,
> Sean
> *Sent:* Monday, June 8, 2020 3:59 PM
> *To:* cisco-voip@puck.nether.net
> *Subject:* [cisco-voip] 7900 Factory Reset w/out connecting to the network
>
>
>
> We are finally refreshing our 7970’s.  We wanted to factory reset the old
> phones before sending out for scrap.  Is there a way to factory reset
> without having to connect to the network?
>
>
>
> Thanks.
>
>
>
> Sean.
> ___
> 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] Third Party CDR Analysis

[Anthony Holloway]

I think my words my have been confusing.  When I said "They just don't turn
data into knowledge."  I didn't mean Donoma.  In fact, I really only was
referring to CDR tools which stop at backing up the call log truck to your
desk and dumping a mountain of records on you for you to sort through.
Telling a story (like your video example of the runner) is precisely what
people need.  They want to understand their systems.  That's the difference
between data and knowledge.  That's what CUIC is missing too.

On Thu, Jun 4, 2020 at 8:27 AM Parker Pearson - Donoma <
par...@donomasoftware.com> wrote:

> Hey Anthony:
>
>
>
> Would love to hear more from you so we can make sure we are communicating
> the capabilities correctly.  Feel free to reach out to me directly.  I’ll
> even throw in some virtual coffee or a virtual lunch for your time.
>
>
>
> Feedback from people in the field means more to us than anything… so if
> there is a better way we can explain what we do, if there are ideas about
> improvements – we’re all ears.
>
>
>
> Cheers,
>
>
>
> Parker Pearson
>
>
> [image: Donoma Software Web Page] <http://donomasoftware.com/>
> Parker​
> Pearson
> Vice President, Marketing & Business Development
> Donoma Software
> t: *540.443.3577* <540.443.3577>
> e: *par...@donomasoftware.com* 
> *Access Donoma's COVID-19 Free Resources Here*
> <https://www.donomasoftware.com/covid19-response-resources/>
> [image: Facebook] <https://www.facebook.com/DonomaSoftware>
> [image: Twitter] <https://twitter.com/donomasoftware>
> [image: LinkedIn] <https://www.linkedin.com/company/donoma-software>
>
> *From: *cisco-voip  on behalf of
> Anthony Holloway 
> *Date: *Wednesday, June 3, 2020 at 8:02 PM
> *To: *UC Penguin 
> *Cc: *cisco-voip voyp list 
> *Subject: *Re: [cisco-voip] Third Party CDR Analysis
>
>
>
>
>
> *Caution: *This email originated from an outside source.
>
>
>
> My personal experience is that it gets talked about a lot, but then never
> purchased.  For mostly cost reasons, but I think it's also the fact that
> it's one more vendor, one more contract, one more vm, one more management
> touch point, etc., and is the data you'll get really that useful, to
> warrant all that?
>
>
>
> I personally have really wanted to see someone buy the Variphy suite, as
> it also does DID management and a few other things.
>
>
>
> I know the Donoma people post to this list often, so we might hear from
> them.  Their website touts "telling a story" about the call, which I think
> is what most are missing.  They just don't turn data into knowledge.  I'd
> like to see Donoma pull that off, but again, I just don't see people buying
> anything.
>
>
>
> On Wed, Jun 3, 2020 at 3:58 PM UC Penguin  wrote:
>
> I’m curious what third party CDR Analysis software is commonly used today
> and pros/cons of each?
>
> Looking for something friendly for non-Engineers to run reports.
>
> Thanks in advance
> ___
> 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] Cisco Webex Serviceability Connector

[Anthony Holloway]

Never heard of it.  Looks like we're all learning something new from the
list today.  Thanks for sharing.

On Wed, Jun 3, 2020 at 7:54 PM Tim Smith  wrote:

> Hi guys,
>
> Crossposting here possibly for some of you.
> This tool is truly awesome. IMHO - If we all get on board, this will
> definitely help drastically decrease time to resolve TAC cases.
> I'm sure that will benefit us all!
>
> This works to collect pretty much everything TAC needs - i.e. you can
> shelve your RTMT collection process 🙂
> Oh, it works with CUBE too!
>
> Also, don't know if anyone is using TAC bot yet either, but I'm loving
> that too.
>
>
> See below:
>
> If you are a hybrid Cisco UC customer with Webex Control Hub and
> On-Premise UC (CUCM, IMP, Expressway etc).
> Here is an amazing piece of kit that is currently flying a little under
> the radar.
>
> Meet the Cisco Webex Serviceability Connector!
> Deploy the serviceability connector on an on-premise Expressway. Then
> connect it to your on-premise CUCM, IMP, UCCX, Expressways.
>
> Add the Connector in your Control Hub, and now Cisco TAC will be able to
> interrogate your on-premise UC apps for diagnostics. (Including running
> debugs through the Collaboration Solutions Analyser - looking for common
> issues)
>
> https://lnkd.in/g6caifH
>
> Cheers,
>
> Tim
> ___
> 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] vCUBE Experiences

[Anthony Holloway]

Was that trunk to Twilio for CME?  If not, what was on the backside of your
gateway?  CUCM?  If so, was that in AWS too?

On Wed, Jun 3, 2020 at 6:54 PM Tim Smith  wrote:

> Great question, also interested in hearing production stories.
>
> I've deployed Virtual Acme Packet's previously - same limitations - no
> DSP's etc.
> It was a little early and we had teething issues of appliance to virtual
> machine type stuff.. but through the updates this improved.
>
> I've played with CUBE on CSR1000V on AWS - SIP trunks to Twilio - and it
> works great.
> It's certainly so nice and easy to spin up.
> I've also run CSR1000V in AWS for dynamic VPN's.. which again works great.
>
> The DSP's are a nice fallback. You don't need them 99% of the time.. but
> when that 1% case comes up later - then it's certainly handy.
> I think that's a big reason vCUBE is not quoted in customer land.
> I assume it could be popular in service provider land though.
>
> With that Acme deployment (and this was actually years ago now) - we were
> migrating, so we still had PRI gateways with plenty of free DSP's, which we
> could use for Transcoders if required.
>
> Cheers,
>
> Tim.
>
>
>
>
>
> --
> *From:* cisco-voip  on behalf of
> Anthony Holloway 
> *Sent:* Thursday, 4 June 2020 7:06 AM
> *To:* Cisco VoIP Group 
> *Subject:* [cisco-voip] vCUBE Experiences
>
>
> EXTERNAL SENDER WARNING. This message was sent from outside your
> organisation. Please do not click links or open attachments unless you
> recognise the source of this email and know the content is safe.
> Anyone have some vCUBEs out in production for a while, and willing to
> share their feelings and/or experiences with it?
>
> Anything from deployment, to restrictions, to licensing, to upgrade
> processes, lessons learned, etc?
>
> I think the obvious thing is the lack of DSP/PVDM since this is a virtual
> machine, but what else?
>
> I don't come across these in the field at all, and I don't see them being
> proposed or quoted these days, despite vCUBE having been around for a few
> years now.
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] vCUBE Experiences

[Anthony Holloway]

What versions are you using/seeing out there?  Any 17 code?

I noticed that when you download the OVA you pick an IOS version.  How does
that affect upgrades?  Do you upgrade like an ISR, or do you do something
else?

On Wed, Jun 3, 2020 at 6:38 PM Erick Bergquist  wrote:

> Been using for awhile now without issue. Typical setup (bunch of dial
> peers, server groups, e164 pattern maps, etc).
>
> The only problem was a tcl script media playback issue in earlier ios
> version which we worked through with TAC and bug fixed in newer ios
> versions for awhile now.
>
>
> On Wed, Jun 3, 2020 at 4:30 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Anyone have some vCUBEs out in production for a while, and willing to
>> share their feelings and/or experiences with it?
>>
>> Anything from deployment, to restrictions, to licensing, to upgrade
>> processes, lessons learned, etc?
>>
>> I think the obvious thing is the lack of DSP/PVDM since this is a virtual
>> machine, but what else?
>>
>> I don't come across these in the field at all, and I don't see them being
>> proposed or quoted these days, despite vCUBE having been around for a few
>> years now.
>> ___
>> 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] Third Party CDR Analysis

[Anthony Holloway]

My personal experience is that it gets talked about a lot, but then never
purchased.  For mostly cost reasons, but I think it's also the fact that
it's one more vendor, one more contract, one more vm, one more management
touch point, etc., and is the data you'll get really that useful, to
warrant all that?

I personally have really wanted to see someone buy the Variphy suite, as it
also does DID management and a few other things.

I know the Donoma people post to this list often, so we might hear from
them.  Their website touts "telling a story" about the call, which I think
is what most are missing.  They just don't turn data into knowledge.  I'd
like to see Donoma pull that off, but again, I just don't see people buying
anything.

On Wed, Jun 3, 2020 at 3:58 PM UC Penguin  wrote:

> I’m curious what third party CDR Analysis software is commonly used today
> and pros/cons of each?
>
> Looking for something friendly for non-Engineers to run reports.
>
> Thanks in advance
> ___
> 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] vCUBE Experiences

[Anthony Holloway]

Anyone have some vCUBEs out in production for a while, and willing to share
their feelings and/or experiences with it?

Anything from deployment, to restrictions, to licensing, to upgrade
processes, lessons learned, etc?

I think the obvious thing is the lack of DSP/PVDM since this is a virtual
machine, but what else?

I don't come across these in the field at all, and I don't see them being
proposed or quoted these days, despite vCUBE having been around for a few
years now.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Yeah, good question. Certificate monitor in cucm (and others) is really
handy for this, but I've also seen it fail due to a defect.

I wonder if the one cisco is using in cucm (and others) is the #8 one
listed in this article:
https://geekflare.com/monitor-ssl-certificate-expiry/

Either way, there's a few other cloud and on-prem solutions mentioned in
that link.

On Wed, Jun 3, 2020 at 1:24 PM Pawlowski, Adam  wrote:

> This is the boat we were in as well, and I’ve learned some lessons here.
>
>
>
> The bug that I posted about for Jabber mobile devices got me – since we’re
> MRA only I thought I broke it again and it took a while to figure out why.
> The bugs in Expressway  login banner got me for a while thinking I’d just broken the cluster due to
> the replication failed alarms.  I nearly forgot to reset all the phones
> after restarting TVS but … well fool me once on that one.
>
>
>
> I learned that the Expressway doesn’t have any real certificate “monitor”,
> and if you put an EC cert from an intermediate into the ipsec-trust
> keychain you will break that service, it will just core endlessly.
>
>
>
> How is everyone keeping track of the certificates that they have out
> there, and that they’re coming up due for replacement? Outlook calendars
> are no good, and neither are the notices from the issuing CA. I have to be
> missing something obvious.
>
>
>
> Best,
>
>
>
> Adam
>
>
>
> *From:* cisco-voip  *On Behalf Of *Derek
> Andrew
> *Sent:* Wednesday, June 3, 2020 10:20 AM
> *To:* Anthony Holloway 
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Resolving Sectigo root expiration affecting
> MRA
>
>
>
> If you had previously installed the certs on CUCM CUP CUC and CER as we
> did, they would also have expired.
>
>
>
> On Wed, Jun 3, 2020 at 7:34 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> CAUTION: This email originated from outside of the University of
> Saskatchewan. Do not click links or open attachments unless you recognize
> the sender and know the content is safe. If in doubt, please forward
> suspicious emails to phish...@usask.ca
>
>
>
> Hunter,
>
>
>
> I might be exposing a gap in my knowledge here, but why did you need these
> certs on CUCM?
>
>
>
> Cisco has now published a troubleshooting guide for this issue, and the
> article does not mention modifying CUCM cert store.
>
>
>
>
> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>
>
>
> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>
> All,
>
>
>
> If you use certs whose trust is derived from the Sectigo root that expired
> today, and your MRA isn’t working, I’ll try to save you a call to TAC.
>
>
>
> Do all of these things:
>
>
>
>  - Load the new intermediates and root into callmanager-trust and
> tomcat-trust on all your UCMs
>
>  - restart tomcat, tftp, and callmanager on those boxes
>
>  - load the new intermediates and root into the CA trust store on all
> expressways
>
>  - reboot the Expressway-Es
>
>
>
> If you need more detail or help, let me know, we just got off the phone
> with TAC. Hope it helps.
>
>
>
> --
>
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> --
>
> Copyright 2020 Derek Andrew (excluding quotations)
>
> +1 306 966 4808
>
> Communication and Network Services
>
> Information and Communications Technology
>
>
> *University of Saskatchewan *Peterson 120; 54 Innovation Boulevard
> Saskatoon,Saskatchewan,Canada. S7N 2V3
> Timezone GMT-6
>
>
>
> Typed but not read.
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] [External] Re: Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Ah ok, in your original email you only mentioned MRA, and so I was very
focused on how CUCM might need certs in the store for MRA.  You are in fact
doing more than just MRA.  Got it.

On Wed, Jun 3, 2020 at 11:35 AM Hunter Fuller  wrote:

> We have a handful of reasons for the certs in CUCM, some to do with MRA,
> some not.
>
>  - Users use the Self Care Portal, and some pickier browsers don't like
> being sent the wrong root.
>  - Something to do with SSO? I was never super clear on this. Either our
> SSO IdP didn't trust the cert from UCM or the other way around. We fixed
> both at the same time, so I guess I will never know.
>  - We are, in fact, checking crypto for all the Expressway tunnels
> (ExpE-ExpC tunnel as well as ExpC-CUCM).
>
> Honorable mention:
>  - Because it's a bad idea to leave expired certs laying around in there,
> and I never know what one of my colleagues may have configured that relies
> on the TLS verify working. :)
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
>
> On Wed, Jun 3, 2020 at 8:28 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Hunter,
>>
>> I might be exposing a gap in my knowledge here, but why did you need
>> these certs on CUCM?
>>
>> Cisco has now published a troubleshooting guide for this issue, and the
>> article does not mention modifying CUCM cert store.
>>
>>
>> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>>
>> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>>
>>> All,
>>>
>>> If you use certs whose trust is derived from the Sectigo root that
>>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>>> TAC.
>>>
>>> Do all of these things:
>>>
>>>  - Load the new intermediates and root into callmanager-trust and
>>> tomcat-trust on all your UCMs
>>>  - restart tomcat, tftp, and callmanager on those boxes
>>>  - load the new intermediates and root into the CA trust store on all
>>> expressways
>>>  - reboot the Expressway-Es
>>>
>>> If you need more detail or help, let me know, we just got off the phone
>>> with TAC. Hope it helps.
>>>
>>> --
>>>
>>> --
>>> Hunter Fuller (they)
>>> Router Jockey
>>> VBH Annex B-5
>>> +1 256 824 5331
>>>
>>> Office of Information Technology
>>> The University of Alabama in Huntsville
>>> Network Engineering
>>> ___
>>> 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] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Actually, I'm starting to think on this some more, I think it might be
because of two facts, but please confirm:

1) You signed your C certs with a public CA which leverages these expired
CA certs
2) You enabled TLS verification between CUCM and C (both MRA and B2B?)

I don't typically see encryption on the inside like this, though, I do see
it mentioned in the steps for MRA as if it were a requirement (e.g., how it
says to copy the names of the phone sec prof for the cert).  Though, I also
don't see a lot of B2B deployments where you might want E2E encryption
either.

On Wed, Jun 3, 2020 at 8:28 AM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Hunter,
>
> I might be exposing a gap in my knowledge here, but why did you need these
> certs on CUCM?
>
> Cisco has now published a troubleshooting guide for this issue, and the
> article does not mention modifying CUCM cert store.
>
>
> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>
> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>
>> All,
>>
>> If you use certs whose trust is derived from the Sectigo root that
>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>> TAC.
>>
>> Do all of these things:
>>
>>  - Load the new intermediates and root into callmanager-trust and
>> tomcat-trust on all your UCMs
>>  - restart tomcat, tftp, and callmanager on those boxes
>>  - load the new intermediates and root into the CA trust store on all
>> expressways
>>  - reboot the Expressway-Es
>>
>> If you need more detail or help, let me know, we just got off the phone
>> with TAC. Hope it helps.
>>
>> --
>>
>> --
>> Hunter Fuller (they)
>> Router Jockey
>> VBH Annex B-5
>> +1 256 824 5331
>>
>> Office of Information Technology
>> The University of Alabama in Huntsville
>> Network Engineering
>> ___
>> 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] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

True, however, if they're not being used, it causes no issue, correct?
Much like the expiring root cert of Feb 2020 for Smart Call Home.

On Wed, Jun 3, 2020 at 9:20 AM Derek Andrew  wrote:

> If you had previously installed the certs on CUCM CUP CUC and CER as we
> did, they would also have expired.
>
> On Wed, Jun 3, 2020 at 7:34 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> CAUTION: This email originated from outside of the University of
>> Saskatchewan. Do not click links or open attachments unless you recognize
>> the sender and know the content is safe. If in doubt, please forward
>> suspicious emails to phish...@usask.ca
>>
>> Hunter,
>>
>> I might be exposing a gap in my knowledge here, but why did you need
>> these certs on CUCM?
>>
>> Cisco has now published a troubleshooting guide for this issue, and the
>> article does not mention modifying CUCM cert store.
>>
>>
>> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>>
>> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>>
>>> All,
>>>
>>> If you use certs whose trust is derived from the Sectigo root that
>>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>>> TAC.
>>>
>>> Do all of these things:
>>>
>>>  - Load the new intermediates and root into callmanager-trust and
>>> tomcat-trust on all your UCMs
>>>  - restart tomcat, tftp, and callmanager on those boxes
>>>  - load the new intermediates and root into the CA trust store on all
>>> expressways
>>>  - reboot the Expressway-Es
>>>
>>> If you need more detail or help, let me know, we just got off the phone
>>> with TAC. Hope it helps.
>>>
>>> --
>>>
>>> --
>>> Hunter Fuller (they)
>>> Router Jockey
>>> VBH Annex B-5
>>> +1 256 824 5331
>>>
>>> Office of Information Technology
>>> The University of Alabama in Huntsville
>>> Network Engineering
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>
> --
> Copyright 2020 Derek Andrew (excluding quotations)
>
> +1 306 966 4808
> Communication and Network Services
> Information and Communications Technology
>
> *University of Saskatchewan*Peterson 120; 54 Innovation Boulevard
> Saskatoon,Saskatchewan,Canada. S7N 2V3
> Timezone GMT-6
>
> Typed but not read.
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Hunter,

I might be exposing a gap in my knowledge here, but why did you need these
certs on CUCM?

Cisco has now published a troubleshooting guide for this issue, and the
article does not mention modifying CUCM cert store.

https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html

On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:

> All,
>
> If you use certs whose trust is derived from the Sectigo root that expired
> today, and your MRA isn’t working, I’ll try to save you a call to TAC.
>
> Do all of these things:
>
>  - Load the new intermediates and root into callmanager-trust and
> tomcat-trust on all your UCMs
>  - restart tomcat, tftp, and callmanager on those boxes
>  - load the new intermediates and root into the CA trust store on all
> expressways
>  - reboot the Expressway-Es
>
> If you need more detail or help, let me know, we just got off the phone
> with TAC. Hope it helps.
>
> --
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
> ___
> 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] call forward is not working in this scenario

[Anthony Holloway]

There are two call forwarding settings there today (no answer and busy).
Was it something more than that?

It would be great if you had more details about it.  My google searching
has turned up nothing so far.

On Tue, Jun 2, 2020 at 11:35 AM Norton, Mike 
wrote:

> I haven’t been into CUCM in ages, but there used to be a secret field in
> some advanced area I forget the name of, where you could type in the name
> of a particular Cisco Bug ID, and then when you go to a hunt pilot there
> will magically be call forwarding settings there that you can specify
> directly on the hunt pilot.
>
> -mn
>
>
>
> *From:* cisco-voip  *On Behalf Of *Arun
> Kumar
> *Sent:* June 2, 2020 6:25 AM
> *To:* cisco-voip@puck.nether.net
> *Subject:* [cisco-voip] call forward is not working in this scenario
>
>
>
> Hi
>
>
>
> can anybody please help to fix this call flow issue
>
>
>
> the call flow is like this
>
>
>
> Hunt pilot number --> linegroup --> algorithm set as broadcast and LG -
> Phone ext() set CFA To Mobile number(X). Please let me know is
> there any alternate for apart from SNR ?
>
> --
>
>
> *Thanks, Arun*
> ___
> 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] call forward is not working in this scenario

[Anthony Holloway]

Ok, well, if your base configuration is hunt groups, and you want mobility,
the answer is likely SNR.  Any reason you wanted to stay away from SNR
based solutions?

On Tue, Jun 2, 2020 at 10:50 AM Arun Kumar  wrote:

> agents are not at the office because of COVID situation and they want to
> attend the calls, hence they requested to forward the calls to their mobile
> phones
>
> On Tue, Jun 2, 2020 at 9:14 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Nope.  The forward no coverage is for the following scenario only:
>>
>>1. Caller calls phone DN directly
>>2. DN is set to forward to a Hunt Pilot
>>3. Hunt Group (HP+HL+LG) cannot cover to a member for some reason
>>(e.g., RNA)
>>4. Call is now forwarded to the DN's Forward No Coverage destination
>>
>> Seems like a strange scenario, one in which I have never needed nor been
>> asked to configure.  I wonder who the hell uses that and why?
>>
>> On Tue, Jun 2, 2020 at 10:22 AM Lelio Fulgenzi  wrote:
>>
>>> Could you not use “forward no coverage” for this ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* cisco-voip  *On Behalf Of 
>>> *Anthony
>>> Holloway
>>> *Sent:* Tuesday, June 2, 2020 10:52 AM
>>> *To:* Arun Kumar 
>>> *Cc:* Cisco VoIP Group 
>>> *Subject:* Re: [cisco-voip] call forward is not working in this scenario
>>>
>>>
>>>
>>> *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
>>>
>>>
>>>
>>> Call forwarding is ignored for members of hunt groups.
>>>
>>>
>>>
>>> If you actually configure SNR (like with RDP/RD) then that does work.
>>> In fact, you don't even need a Cisco phone in the membership of the LG to
>>> ring a cell phone.  Once you build the DN on the RDP you can add the DN to
>>> the LG.
>>>
>>>
>>>
>>> On Tue, Jun 2, 2020 at 7:27 AM Arun Kumar 
>>> wrote:
>>>
>>> Hi
>>>
>>>
>>>
>>> can anybody please help to fix this call flow issue
>>>
>>>
>>>
>>> the call flow is like this
>>>
>>>
>>>
>>> Hunt pilot number --> linegroup --> algorithm set as broadcast and LG -
>>> Phone ext() set CFA To Mobile number(X). Please let me know is
>>> there any alternate for apart from SNR ?
>>>
>>> --
>>>
>>>
>>> *Thanks, Arun*
>>>
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>
> --
>
> *Thanks,Arun*
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] call forward is not working in this scenario

[Anthony Holloway]

Nope.  The forward no coverage is for the following scenario only:

   1. Caller calls phone DN directly
   2. DN is set to forward to a Hunt Pilot
   3. Hunt Group (HP+HL+LG) cannot cover to a member for some reason (e.g.,
   RNA)
   4. Call is now forwarded to the DN's Forward No Coverage destination

Seems like a strange scenario, one in which I have never needed nor been
asked to configure.  I wonder who the hell uses that and why?

On Tue, Jun 2, 2020 at 10:22 AM Lelio Fulgenzi  wrote:

> Could you not use “forward no coverage” for this ?
>
>
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *Anthony
> Holloway
> *Sent:* Tuesday, June 2, 2020 10:52 AM
> *To:* Arun Kumar 
> *Cc:* Cisco VoIP Group 
> *Subject:* Re: [cisco-voip] call forward is not working in this scenario
>
>
>
> *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
>
>
>
> Call forwarding is ignored for members of hunt groups.
>
>
>
> If you actually configure SNR (like with RDP/RD) then that does work.  In
> fact, you don't even need a Cisco phone in the membership of the LG to ring
> a cell phone.  Once you build the DN on the RDP you can add the DN to the
> LG.
>
>
>
> On Tue, Jun 2, 2020 at 7:27 AM Arun Kumar  wrote:
>
> Hi
>
>
>
> can anybody please help to fix this call flow issue
>
>
>
> the call flow is like this
>
>
>
> Hunt pilot number --> linegroup --> algorithm set as broadcast and LG -
> Phone ext() set CFA To Mobile number(X). Please let me know is
> there any alternate for apart from SNR ?
>
> --
>
>
> *Thanks, Arun*
>
> ___
> 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] call forward is not working in this scenario

[Anthony Holloway]

Call forwarding is ignored for members of hunt groups.

If you actually configure SNR (like with RDP/RD) then that does work.  In
fact, you don't even need a Cisco phone in the membership of the LG to ring
a cell phone.  Once you build the DN on the RDP you can add the DN to the
LG.

On Tue, Jun 2, 2020 at 7:27 AM Arun Kumar  wrote:

> Hi
>
> can anybody please help to fix this call flow issue
>
> the call flow is like this
>
> Hunt pilot number --> linegroup --> algorithm set as broadcast and LG -
> Phone ext() set CFA To Mobile number(X). Please let me know is
> there any alternate for apart from SNR ?
> --
>
> *Thanks,Arun*
> ___
> 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] [External] Re: Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Probably confusion with the tomcat cert, versus the tomcat-trust.

Remember this defect?
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy13916

On Sat, May 30, 2020 at 7:11 PM Hunter Fuller  wrote:

> I was wondering the same thing. You may be able to skip that one, but it
> advises you to restart it when updating the callmanager-trust store, so we
> did it.
>
> On Sat, May 30, 2020 at 19:10 Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> MVP
>>
>> But why restart TFTP?
>>
>> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>>
>>> All,
>>>
>>> If you use certs whose trust is derived from the Sectigo root that
>>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>>> TAC.
>>>
>>> Do all of these things:
>>>
>>>  - Load the new intermediates and root into callmanager-trust and
>>> tomcat-trust on all your UCMs
>>>  - restart tomcat, tftp, and callmanager on those boxes
>>>  - load the new intermediates and root into the CA trust store on all
>>> expressways
>>>  - reboot the Expressway-Es
>>>
>>> If you need more detail or help, let me know, we just got off the phone
>>> with TAC. Hope it helps.
>>>
>>> --
>>>
>>> --
>>> Hunter Fuller (they)
>>> Router Jockey
>>> VBH Annex B-5
>>> +1 256 824 5331
>>>
>>> Office of Information Technology
>>> The University of Alabama in Huntsville
>>> Network Engineering
>>>
>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>> --
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

MVP

But why restart TFTP?

On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:

> All,
>
> If you use certs whose trust is derived from the Sectigo root that expired
> today, and your MRA isn’t working, I’ll try to save you a call to TAC.
>
> Do all of these things:
>
>  - Load the new intermediates and root into callmanager-trust and
> tomcat-trust on all your UCMs
>  - restart tomcat, tftp, and callmanager on those boxes
>  - load the new intermediates and root into the CA trust store on all
> expressways
>  - reboot the Expressway-Es
>
> If you need more detail or help, let me know, we just got off the phone
> with TAC. Hope it helps.
>
> --
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
> ___
> 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] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

I like that use case.  It makes sense to me if you were doing exports often
enough.  I don't think most customers are however, exporting their own
configurations.  But I still like the use case nonetheless.

On Thu, May 28, 2020 at 3:02 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> We name most things by the site name or similar. If you were looking a
> device export or something it can get mighty confusing IMO if you just saw
> several columns all saying SITENAME as the values.  Easier to mix up data
> when you have non unique values.
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Thursday, May 28, 2020 3:42 PM
> *To:* Matthew Loraditch 
> *Cc:* Pawlowski, Adam ; James B <
> james.buchan...@gmail.com>; cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> [EXTERNAL]
>
>
>
> Can anyone give a use case where appending or prepending the object type
> identifier on the name is helpful?  E.g., why put -css on a css at all?
>
>
>
> On Thu, May 28, 2020 at 2:19 PM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
>
>1. PT-, CSS-, etc
>2. FQDN
>3. My setups are always distributed. Certainly could have central if
>it’s one site.
>4. Usually always
>5. SIP, SIP, SIP
>6. Unfortunately no, drives my OCD crazy. I hate lower/mixed case
>naming of devices with a passion. I’m also born of a Windows world where
>case never mattered.
>
>
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Pawlowski, Adam 
> *Sent:* Thursday, May 28, 2020 3:08 PM
> *To:* James B ; Anthony Holloway <
> avholloway+cisco-v...@gmail.com>; Matthew Loraditch <
> mloradi...@heliontechnologies.com>
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* RE: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> [EXTERNAL]
>
>
>
> Sure I can fire this up
>
>
>
>1. part_ , like part_local, part_ld, part_ld_privacy , etc.
>2. FQDN, but, make sure your DNS/NTP/etc works with resiliency.
>3. Depends on if you’re distributed, using hardware conf, transcoder
>cause you have some people on some sort of twizzler based connection using
>g729, etc
>4. Yes, unless you have something on the other side that can’t handle
>these requests coming from the whole group, or again a distributed system.
>5. SIP. MGCP is nice in a set it and forget it way, but if you want to
>use the gateway to do anything else like custom intercepts, redirection,
>hairpinning, it won’t help you. There are some features that don’t work
>when you go to SIP but whatever.
>6. Why would you give anything an upper case hostname
>
>
>
> *From:* cisco-voip  *On Behalf Of *James
> B
> *Sent:* Thursday, May 28, 2020 2:28 PM
> *To:* Anthony Holloway ; Matthew
> Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> I was thinking of the community configuration approach Anthony suggested
> and was thinking of the debates we’d have if we did that:
>
>
>
>1. Do you use “_PT”, “PT_”, or just the site name? Same for “CSS”,
>“LOC”, and the ever-debated “RGN” or “REG”?.
>    2. FQDN or IP addresses?
>3. Do all the media resources go into a single MRG or not?
>4. Do we click “Run on all Nodes” for route lists and trunks or not?
>5. MGCP, SIP, or H323 (if using PRIs)?
>6. Can UCCX have upper-case hostnames or not?
>
>
>
> The debates would take us so long, version 14.0 would be out, and then
> we’d have to debate about whether a “.0” versoin is stable or not or 

Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

Fun fact, you can name a sip trunk and an mgcp gateway the same name and it
will break mgcp configuration, as the internal lookup for the device config
file looks for a config file for the trunk first, will not find it, and
then return an error.

On Thu, May 28, 2020 at 2:50 PM Johnson, Tim  wrote:

> That bothers me too. I think the only option where that makes sense is for
> RGs and RLs because they cannot share the same name.
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *Anthony
> Holloway
> *Sent:* Thursday, May 28, 2020 3:42 PM
> *To:* Matthew Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> Can anyone give a use case where appending or prepending the object type
> identifier on the name is helpful?  E.g., why put -css on a css at all?
>
>
>
> On Thu, May 28, 2020 at 2:19 PM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
>
>1. PT-, CSS-, etc
>2. FQDN
>3. My setups are always distributed. Certainly could have central if
>it’s one site.
>4. Usually always
>5. SIP, SIP, SIP
>6. Unfortunately no, drives my OCD crazy. I hate lower/mixed case
>naming of devices with a passion. I’m also born of a Windows world where
>case never mattered.
>
>
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Pawlowski, Adam 
> *Sent:* Thursday, May 28, 2020 3:08 PM
> *To:* James B ; Anthony Holloway <
> avholloway+cisco-v...@gmail.com>; Matthew Loraditch <
> mloradi...@heliontechnologies.com>
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* RE: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> [EXTERNAL]
>
>
>
> Sure I can fire this up
>
>
>
>1. part_ , like part_local, part_ld, part_ld_privacy , etc.
>2. FQDN, but, make sure your DNS/NTP/etc works with resiliency.
>3. Depends on if you’re distributed, using hardware conf, transcoder
>cause you have some people on some sort of twizzler based connection using
>g729, etc
>4. Yes, unless you have something on the other side that can’t handle
>these requests coming from the whole group, or again a distributed system.
>5. SIP. MGCP is nice in a set it and forget it way, but if you want to
>use the gateway to do anything else like custom intercepts, redirection,
>hairpinning, it won’t help you. There are some features that don’t work
>when you go to SIP but whatever.
>6. Why would you give anything an upper case hostname
>
>
>
> *From:* cisco-voip  *On Behalf Of *James
> B
> *Sent:* Thursday, May 28, 2020 2:28 PM
> *To:* Anthony Holloway ; Matthew
> Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> I was thinking of the community configuration approach Anthony suggested
> and was thinking of the debates we’d have if we did that:
>
>
>
>1. Do you use “_PT”, “PT_”, or just the site name? Same for “CSS”,
>“LOC”, and the ever-debated “RGN” or “REG”?.
>2. FQDN or IP addresses?
>3. Do all the media resources go into a single MRG or not?
>    4. Do we click “Run on all Nodes” for route lists and trunks or not?
>5. MGCP, SIP, or H323 (if using PRIs)?
>6. Can UCCX have upper-case hostnames or not?
>
>
>
> The debates would take us so long, version 14.0 would be out, and then
> we’d have to debate about whether a “.0” versoin is stable or not or should
> we wait for “.5”? Still, could be fun!
>
>
>
>
>
>
>
> *From: *Anthony Holloway 
> *Sent: *28 May 2020 19:15
> *To: *Matthew Loraditch 
> *Cc: *cisco-voip@puck.nether.net
> *Subject: *Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> Keep in mind that PCD network migrations, while awesome for CUCM, do not
> work for other products.
>
>
>
> Typically with a project like this, you'll likely have a different
> approach for each app, and not a one size fits all solution.
>
>
>
> With the app upgrades, you will also have to change OVA sizes (or want to
> in some cases), and at that point, it might be better t

Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

Can anyone give a use case where appending or prepending the object type
identifier on the name is helpful?  E.g., why put -css on a css at all?

On Thu, May 28, 2020 at 2:19 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

>
>1. PT-, CSS-, etc
>2. FQDN
>3. My setups are always distributed. Certainly could have central if
>it’s one site.
>4. Usually always
>5. SIP, SIP, SIP
>6. Unfortunately no, drives my OCD crazy. I hate lower/mixed case
>naming of devices with a passion. I’m also born of a Windows world where
>case never mattered.
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Pawlowski, Adam 
> *Sent:* Thursday, May 28, 2020 3:08 PM
> *To:* James B ; Anthony Holloway <
> avholloway+cisco-v...@gmail.com>; Matthew Loraditch <
> mloradi...@heliontechnologies.com>
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* RE: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> [EXTERNAL]
>
>
>
> Sure I can fire this up
>
>
>
>1. part_ , like part_local, part_ld, part_ld_privacy , etc.
>2. FQDN, but, make sure your DNS/NTP/etc works with resiliency.
>3. Depends on if you’re distributed, using hardware conf, transcoder
>cause you have some people on some sort of twizzler based connection using
>g729, etc
>4. Yes, unless you have something on the other side that can’t handle
>these requests coming from the whole group, or again a distributed system.
>5. SIP. MGCP is nice in a set it and forget it way, but if you want to
>use the gateway to do anything else like custom intercepts, redirection,
>hairpinning, it won’t help you. There are some features that don’t work
>when you go to SIP but whatever.
>6. Why would you give anything an upper case hostname
>
>
>
> *From:* cisco-voip  *On Behalf Of *James
> B
> *Sent:* Thursday, May 28, 2020 2:28 PM
> *To:* Anthony Holloway ; Matthew
> Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> I was thinking of the community configuration approach Anthony suggested
> and was thinking of the debates we’d have if we did that:
>
>
>
>1. Do you use “_PT”, “PT_”, or just the site name? Same for “CSS”,
>“LOC”, and the ever-debated “RGN” or “REG”?.
>2. FQDN or IP addresses?
>3. Do all the media resources go into a single MRG or not?
>4. Do we click “Run on all Nodes” for route lists and trunks or not?
>5. MGCP, SIP, or H323 (if using PRIs)?
>6. Can UCCX have upper-case hostnames or not?
>
>
>
> The debates would take us so long, version 14.0 would be out, and then
> we’d have to debate about whether a “.0” versoin is stable or not or should
> we wait for “.5”? Still, could be fun!
>
>
>
>
>
>
>
> *From: *Anthony Holloway 
> *Sent: *28 May 2020 19:15
> *To: *Matthew Loraditch 
> *Cc: *cisco-voip@puck.nether.net
> *Subject: *Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> Keep in mind that PCD network migrations, while awesome for CUCM, do not
> work for other products.
>
>
>
> Typically with a project like this, you'll likely have a different
> approach for each app, and not a one size fits all solution.
>
>
>
> With the app upgrades, you will also have to change OVA sizes (or want to
> in some cases), and at that point, it might be better to install fresh, and
> use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get
> data exported/imported from old to new.
>
>
>
> Or like Kent said, tell yourself it's a toshiba system, and treat it like
> a greenfield.
>
>
>
> On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> Here’s a fun one. We have taken over support of these ancient servers
> hosted on Esxi 4.1 on UCS-C200-M2s!
>
>
>
> Exact Versions are:
>
> 8.5 SU2 for CUCM/UCXN
>
> 8.5 FCS for UCCX
>
>
>
> Each  is a pair of servers.
>
>
>
> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
&

Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

I see it, and I see that it's not 100% clear. However, if you listen to the
presentation recording for this section, Brandon does mention the lengthy
process for multi-step upgrades, and how PCD solves that, though, either
are valid.

On Thu, May 28, 2020 at 2:07 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> Slide 92
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Thursday, May 28, 2020 2:51 PM
> *To:* Matthew Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> [EXTERNAL]
>
>
>
> Which slide says you can go direct with osadmin?
>
>
>
> On Thu, May 28, 2020 at 1:41 PM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> Interesting thing is this preso (which is not official for TAC Purposes)
> says I can go from 8.6 to 12.5 directly in OS admin, but docs say use PCD.
> Not going to try it, but nevertheless curious.
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Thursday, May 28, 2020 2:29 PM
> *To:* Matthew Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> [EXTERNAL]
>
>
>
> Another thing, CUCM 12.5 specific, Cisco wants all of us to run through
> the Collaboration Sizing Tool every time we upgrade to 12.5 now.
>
>
>
> See slide 13
>
>
> https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKUCC-2011.pdf
>
>
>
> On Thu, May 28, 2020 at 1:08 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> Keep in mind that PCD network migrations, while awesome for CUCM, do not
> work for other products.
>
>
>
> Typically with a project like this, you'll likely have a different
> approach for each app, and not a one size fits all solution.
>
>
>
> With the app upgrades, you will also have to change OVA sizes (or want to
> in some cases), and at that point, it might be better to install fresh, and
> use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get
> data exported/imported from old to new.
>
>
>
> Or like Kent said, tell yourself it's a toshiba system, and treat it like
> a greenfield.
>
>
>
> On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> Here’s a fun one. We have taken over support of these ancient servers
> hosted on Esxi 4.1 on UCS-C200-M2s!
>
>
>
> Exact Versions are:
>
> 8.5 SU2 for CUCM/UCXN
>
> 8.5 FCS for UCCX
>
>
>
> Each  is a pair of servers.
>
>
>
> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
> available publicly.
>
>
>
> Also fun wrinkle the new host are across the WAN and for many logistical
> reasons are staying there. The migration to the new hosts will have to be
> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
> data across will be fast enough to finish in the allotted time period. My
> plan was a change freeze window and copy/restore the backups and then
> activate the new servers and move the subnet to the new location.
>
>
>
> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
> migration to Finesse!)
>
>
>
> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
> then to 12x
>
>
>
> I think my plan is to do the upgrades to the interim versions on the old
> hosts then migrate to the new and then finish

Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

Which slide says you can go direct with osadmin?

On Thu, May 28, 2020 at 1:41 PM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> Interesting thing is this preso (which is not official for TAC Purposes)
> says I can go from 8.6 to 12.5 directly in OS admin, but docs say use PCD.
> Not going to try it, but nevertheless curious.
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway 
> *Sent:* Thursday, May 28, 2020 2:29 PM
> *To:* Matthew Loraditch 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> [EXTERNAL]
>
>
>
> Another thing, CUCM 12.5 specific, Cisco wants all of us to run through
> the Collaboration Sizing Tool every time we upgrade to 12.5 now.
>
>
>
> See slide 13
>
>
> https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKUCC-2011.pdf
>
>
>
> On Thu, May 28, 2020 at 1:08 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> Keep in mind that PCD network migrations, while awesome for CUCM, do not
> work for other products.
>
>
>
> Typically with a project like this, you'll likely have a different
> approach for each app, and not a one size fits all solution.
>
>
>
> With the app upgrades, you will also have to change OVA sizes (or want to
> in some cases), and at that point, it might be better to install fresh, and
> use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get
> data exported/imported from old to new.
>
>
>
> Or like Kent said, tell yourself it's a toshiba system, and treat it like
> a greenfield.
>
>
>
> On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> Here’s a fun one. We have taken over support of these ancient servers
> hosted on Esxi 4.1 on UCS-C200-M2s!
>
>
>
> Exact Versions are:
>
> 8.5 SU2 for CUCM/UCXN
>
> 8.5 FCS for UCCX
>
>
>
> Each  is a pair of servers.
>
>
>
> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
> available publicly.
>
>
>
> Also fun wrinkle the new host are across the WAN and for many logistical
> reasons are staying there. The migration to the new hosts will have to be
> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
> data across will be fast enough to finish in the allotted time period. My
> plan was a change freeze window and copy/restore the backups and then
> activate the new servers and move the subnet to the new location.
>
>
>
> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
> migration to Finesse!)
>
>
>
> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
> then to 12x
>
>
>
> I think my plan is to do the upgrades to the interim versions on the old
> hosts then migrate to the new and then finish the upgrades. The old hosts
> will need ESXi upgrades to an interim version.
>
>
>
> Anyone have thoughts on what they would do here? This is partially
> depending on TAC being able to provide me the ISOs I will need, but I
> presume there is an archive.
>
>
>
> In theory some sort of PCD migration is also an option, but I’ve never
> done one and not sure how it could handle the subnet situation that will
> have to exist.
>
>
>
> Welcome to my fun life!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> ___
> 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] [External] Re: Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

Correct.  Today, it's basically the standard to involve DNS in your
deployment.  However, there's always exceptions to the rule.

On Thu, May 28, 2020 at 1:35 PM Hunter Fuller  wrote:

> I swear, really, that I'm not trying to stir anything up here.
>
> But is there any reason to turn up a new cluster with IPs?? You have to
> use FQDNs for at least some stuff (Jabber and web portal related stuff in
> particular)...
>
> I promise I'm not trying to start something.
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
>
> On Thu, May 28, 2020 at 1:28 PM James B  wrote:
>
>> I was thinking of the community configuration approach Anthony suggested
>> and was thinking of the debates we’d have if we did that:
>>
>>
>>
>>1. Do you use “_PT”, “PT_”, or just the site name? Same for “CSS”,
>>“LOC”, and the ever-debated “RGN” or “REG”?.
>>2. FQDN or IP addresses?
>>3. Do all the media resources go into a single MRG or not?
>>4. Do we click “Run on all Nodes” for route lists and trunks or not?
>>5. MGCP, SIP, or H323 (if using PRIs)?
>>6. Can UCCX have upper-case hostnames or not?
>>
>>
>>
>> The debates would take us so long, version 14.0 would be out, and then
>> we’d have to debate about whether a “.0” versoin is stable or not or should
>> we wait for “.5”? Still, could be fun!
>>
>>
>>
>>
>>
>>
>>
>> *From: *Anthony Holloway 
>> *Sent: *28 May 2020 19:15
>> *To: *Matthew Loraditch 
>> *Cc: *cisco-voip@puck.nether.net
>> *Subject: *Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>>
>>
>>
>> Keep in mind that PCD network migrations, while awesome for CUCM, do not
>> work for other products.
>>
>>
>>
>> Typically with a project like this, you'll likely have a different
>> approach for each app, and not a one size fits all solution.
>>
>>
>>
>> With the app upgrades, you will also have to change OVA sizes (or want to
>> in some cases), and at that point, it might be better to install fresh, and
>> use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get
>> data exported/imported from old to new.
>>
>>
>>
>> Or like Kent said, tell yourself it's a toshiba system, and treat it like
>> a greenfield.
>>
>>
>>
>> On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch <
>> mloradi...@heliontechnologies.com> wrote:
>>
>> Here’s a fun one. We have taken over support of these ancient servers
>> hosted on Esxi 4.1 on UCS-C200-M2s!
>>
>>
>>
>> Exact Versions are:
>>
>> 8.5 SU2 for CUCM/UCXN
>>
>> 8.5 FCS for UCCX
>>
>>
>>
>> Each  is a pair of servers.
>>
>>
>>
>> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
>> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
>> available publicly.
>>
>>
>>
>> Also fun wrinkle the new host are across the WAN and for many logistical
>> reasons are staying there. The migration to the new hosts will have to be
>> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
>> data across will be fast enough to finish in the allotted time period. My
>> plan was a change freeze window and copy/restore the backups and then
>> activate the new servers and move the subnet to the new location.
>>
>>
>>
>> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
>> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
>> migration to Finesse!)
>>
>>
>>
>> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
>> then to 12x
>>
>>
>>
>> I think my plan is to do the upgrades to the interim versions on the old
>> hosts then migrate to the new and then finish the upgrades. The old hosts
>> will need ESXi upgrades to an interim version.
>>
>>
>>
>> Anyone have thoughts on what they would do here? This is partially
>> depending on TAC being able to provide me the ISOs I will need, but I
>> presume there is an archive.
>>
>>
>>
>> In theory some sort of PCD migration is also an option, but I’ve never
>> done one and not sure how it could handle the subnet situation that will
>> have to exist.
>>
>>
>>
>> Welcome to 

Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

Easy

1. Clearly it's "-pt"
2. FQDN or die
3. Design specific, but generally no, just so you can predict which
resource will be used easier
4. Obviously yes, it's superior in 90% of cases unless you're doing geo-sme
5. SIP or die
6. Documented as lower case. End. of. story.

"Hostname must be in lower case and the character limit is 24 characters."
Source:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_12_5/install/guide/uccx_b_125install-and-upgrade-guide/uccx_b_125install-and-upgrade-guide_chapter_00.html#reference_6AA69DFAE265C92FB0D4AAC7D2FDCA35

On Thu, May 28, 2020 at 1:27 PM James B  wrote:

> I was thinking of the community configuration approach Anthony suggested
> and was thinking of the debates we’d have if we did that:
>
>
>
>1. Do you use “_PT”, “PT_”, or just the site name? Same for “CSS”,
>“LOC”, and the ever-debated “RGN” or “REG”?.
>2. FQDN or IP addresses?
>3. Do all the media resources go into a single MRG or not?
>4. Do we click “Run on all Nodes” for route lists and trunks or not?
>5. MGCP, SIP, or H323 (if using PRIs)?
>6. Can UCCX have upper-case hostnames or not?
>
>
>
> The debates would take us so long, version 14.0 would be out, and then
> we’d have to debate about whether a “.0” versoin is stable or not or should
> we wait for “.5”? Still, could be fun!
>
>
>
>
>
>
>
> *From: *Anthony Holloway 
> *Sent: *28 May 2020 19:15
> *To: *Matthew Loraditch 
> *Cc: *cisco-voip@puck.nether.net
> *Subject: *Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> Keep in mind that PCD network migrations, while awesome for CUCM, do not
> work for other products.
>
>
>
> Typically with a project like this, you'll likely have a different
> approach for each app, and not a one size fits all solution.
>
>
>
> With the app upgrades, you will also have to change OVA sizes (or want to
> in some cases), and at that point, it might be better to install fresh, and
> use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get
> data exported/imported from old to new.
>
>
>
> Or like Kent said, tell yourself it's a toshiba system, and treat it like
> a greenfield.
>
>
>
> On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> Here’s a fun one. We have taken over support of these ancient servers
> hosted on Esxi 4.1 on UCS-C200-M2s!
>
>
>
> Exact Versions are:
>
> 8.5 SU2 for CUCM/UCXN
>
> 8.5 FCS for UCCX
>
>
>
> Each  is a pair of servers.
>
>
>
> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
> available publicly.
>
>
>
> Also fun wrinkle the new host are across the WAN and for many logistical
> reasons are staying there. The migration to the new hosts will have to be
> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
> data across will be fast enough to finish in the allotted time period. My
> plan was a change freeze window and copy/restore the backups and then
> activate the new servers and move the subnet to the new location.
>
>
>
> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
> migration to Finesse!)
>
>
>
> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
> then to 12x
>
>
>
> I think my plan is to do the upgrades to the interim versions on the old
> hosts then migrate to the new and then finish the upgrades. The old hosts
> will need ESXi upgrades to an interim version.
>
>
>
> Anyone have thoughts on what they would do here? This is partially
> depending on TAC being able to provide me the ISOs I will need, but I
> presume there is an archive.
>
>
>
> In theory some sort of PCD migration is also an option, but I’ve never
> done one and not sure how it could handle the subnet situation that will
> have to exist.
>
>
>
> Welcome to my fun life!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> ___
> 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] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

lol, not exactly off list there buddy.  ;)

On Thu, May 28, 2020 at 1:32 PM Lelio Fulgenzi  wrote:

> *Replying off-list…*
>
>
>
> Yes, I took down our telephone system once by inserting a blank
> translation in the none partition.
>
>
>
> What did I know? I was young and naïve. 😉
>
>
>
> Of course, with CCM v2 or v3, anything was possible. 😉
>
>
>
> *From:* cisco-voip  *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Thursday, May 28, 2020 2:30 PM
> *To:* Anthony Holloway ; Kent Roberts <
> k...@fredf.org>
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> I call blank translation patterns. 😉
>
>
>
> *From:* cisco-voip  *On Behalf Of *Anthony
> Holloway
> *Sent:* Thursday, May 28, 2020 2:02 PM
> *To:* Kent Roberts 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5
>
>
>
> *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
>
>
>
> Or turn it into the first cisco-voip community project, and we all jump in
> and help?  I call translation patterns!
>
>
>
> On Thu, May 28, 2020 at 12:57 PM Kent Roberts  wrote:
>
>
>
> Might be less work to just start over…..
>
>
>
>
>
> On May 28, 2020, at 10:25 AM, Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
>
>
> Here’s a fun one. We have taken over support of these ancient servers
> hosted on Esxi 4.1 on UCS-C200-M2s!
>
>
>
> Exact Versions are:
>
> 8.5 SU2 for CUCM/UCXN
>
> 8.5 FCS for UCCX
>
>
>
> Each  is a pair of servers.
>
>
>
> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
> available publicly.
>
>
>
> Also fun wrinkle the new host are across the WAN and for many logistical
> reasons are staying there. The migration to the new hosts will have to be
> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
> data across will be fast enough to finish in the allotted time period. My
> plan was a change freeze window and copy/restore the backups and then
> activate the new servers and move the subnet to the new location.
>
>
>
> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
> migration to Finesse!)
>
>
>
> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
> then to 12x
>
>
>
> I think my plan is to do the upgrades to the interim versions on the old
> hosts then migrate to the new and then finish the upgrades. The old hosts
> will need ESXi upgrades to an interim version.
>
>
>
> Anyone have thoughts on what they would do here? This is partially
> depending on TAC being able to provide me the ISOs I will need, but I
> presume there is an archive.
>
>
>
> In theory some sort of PCD migration is also an option, but I’ve never
> done one and not sure how it could handle the subnet situation that will
> have to exist.
>
>
>
> Welcome to my fun life!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Matthew Loraditch**​*
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *mloradi...@heliontechnologies.com* 
>
>  <http://www.heliontechnologies.com/>
>
>  <https://facebook.com/heliontech>
>
>  <https://twitter.com/heliontech>
>
>  <https://www.linkedin.com/company/helion-technologies>
>
> ___
> 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] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

Another thing, CUCM 12.5 specific, Cisco wants all of us to run through the
Collaboration Sizing Tool every time we upgrade to 12.5 now.

See slide 13
https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKUCC-2011.pdf

On Thu, May 28, 2020 at 1:08 PM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Keep in mind that PCD network migrations, while awesome for CUCM, do not
> work for other products.
>
> Typically with a project like this, you'll likely have a different
> approach for each app, and not a one size fits all solution.
>
> With the app upgrades, you will also have to change OVA sizes (or want to
> in some cases), and at that point, it might be better to install fresh, and
> use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get
> data exported/imported from old to new.
>
> Or like Kent said, tell yourself it's a toshiba system, and treat it like
> a greenfield.
>
> On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
>> Here’s a fun one. We have taken over support of these ancient servers
>> hosted on Esxi 4.1 on UCS-C200-M2s!
>>
>>
>>
>> Exact Versions are:
>>
>> 8.5 SU2 for CUCM/UCXN
>>
>> 8.5 FCS for UCCX
>>
>>
>>
>> Each  is a pair of servers.
>>
>>
>>
>> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
>> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
>> available publicly.
>>
>>
>>
>> Also fun wrinkle the new host are across the WAN and for many logistical
>> reasons are staying there. The migration to the new hosts will have to be
>> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
>> data across will be fast enough to finish in the allotted time period. My
>> plan was a change freeze window and copy/restore the backups and then
>> activate the new servers and move the subnet to the new location.
>>
>>
>>
>> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
>> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
>> migration to Finesse!)
>>
>>
>>
>> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
>> then to 12x
>>
>>
>>
>> I think my plan is to do the upgrades to the interim versions on the old
>> hosts then migrate to the new and then finish the upgrades. The old hosts
>> will need ESXi upgrades to an interim version.
>>
>>
>>
>> Anyone have thoughts on what they would do here? This is partially
>> depending on TAC being able to provide me the ISOs I will need, but I
>> presume there is an archive.
>>
>>
>>
>> In theory some sort of PCD migration is also an option, but I’ve never
>> done one and not sure how it could handle the subnet situation that will
>> have to exist.
>>
>>
>>
>> Welcome to my fun life!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Matthew Loraditch​
>> Sr. Network Engineer
>> p: *443.541.1518* <443.541.1518>
>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
>> e: *mloradi...@heliontechnologies.com*
>> 
>> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>> [image: Facebook] <https://facebook.com/heliontech>
>> [image: Twitter] <https://twitter.com/heliontech>
>> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>> ___
>> 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] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

Keep in mind that PCD network migrations, while awesome for CUCM, do not
work for other products.

Typically with a project like this, you'll likely have a different approach
for each app, and not a one size fits all solution.

With the app upgrades, you will also have to change OVA sizes (or want to
in some cases), and at that point, it might be better to install fresh, and
use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get
data exported/imported from old to new.

Or like Kent said, tell yourself it's a toshiba system, and treat it like a
greenfield.

On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch <
mloradi...@heliontechnologies.com> wrote:

> Here’s a fun one. We have taken over support of these ancient servers
> hosted on Esxi 4.1 on UCS-C200-M2s!
>
>
>
> Exact Versions are:
>
> 8.5 SU2 for CUCM/UCXN
>
> 8.5 FCS for UCCX
>
>
>
> Each  is a pair of servers.
>
>
>
> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
> available publicly.
>
>
>
> Also fun wrinkle the new host are across the WAN and for many logistical
> reasons are staying there. The migration to the new hosts will have to be
> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
> data across will be fast enough to finish in the allotted time period. My
> plan was a change freeze window and copy/restore the backups and then
> activate the new servers and move the subnet to the new location.
>
>
>
> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
> migration to Finesse!)
>
>
>
> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
> then to 12x
>
>
>
> I think my plan is to do the upgrades to the interim versions on the old
> hosts then migrate to the new and then finish the upgrades. The old hosts
> will need ESXi upgrades to an interim version.
>
>
>
> Anyone have thoughts on what they would do here? This is partially
> depending on TAC being able to provide me the ISOs I will need, but I
> presume there is an archive.
>
>
>
> In theory some sort of PCD migration is also an option, but I’ve never
> done one and not sure how it could handle the subnet situation that will
> have to exist.
>
>
>
> Welcome to my fun life!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
> [image: Helion Technologies] 
> [image: Facebook] 
> [image: Twitter] 
> [image: LinkedIn] 
> ___
> 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] Migration from CUCM/UCXN/UCCX 8.5 to 12.5

[Anthony Holloway]

Or turn it into the first cisco-voip community project, and we all jump in
and help?  I call translation patterns!

On Thu, May 28, 2020 at 12:57 PM Kent Roberts  wrote:

>
> Might be less work to just start over…..
>
>
> On May 28, 2020, at 10:25 AM, Matthew Loraditch <
> mloradi...@heliontechnologies.com> wrote:
>
> Here’s a fun one. We have taken over support of these ancient servers
> hosted on Esxi 4.1 on UCS-C200-M2s!
>
> Exact Versions are:
> 8.5 SU2 for CUCM/UCXN
> 8.5 FCS for UCCX
>
> Each  is a pair of servers.
>
> Have new M5s and flex licensing… need to get to 12.5..  8.5 docs are dead
> for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not
> available publicly.
>
> Also fun wrinkle the new host are across the WAN and for many logistical
> reasons are staying there. The migration to the new hosts will have to be
> via DRS or maybe PCD somehow? Not sure if the bandwidth available to get
> data across will be fast enough to finish in the allotted time period. My
> plan was a change freeze window and copy/restore the backups and then
> activate the new servers and move the subnet to the new location.
>
> As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to
> 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a
> migration to Finesse!)
>
> For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and
> then to 12x
>
> I think my plan is to do the upgrades to the interim versions on the old
> hosts then migrate to the new and then finish the upgrades. The old hosts
> will need ESXi upgrades to an interim version.
>
> Anyone have thoughts on what they would do here? This is partially
> depending on TAC being able to provide me the ISOs I will need, but I
> presume there is an archive.
>
> In theory some sort of PCD migration is also an option, but I’ve never
> done one and not sure how it could handle the subnet situation that will
> have to exist.
>
> Welcome to my fun life!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Matthew Loraditch​
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com*   |
> e: *mloradi...@heliontechnologies.com* 
>  
>  
>  
>  
> ___
> 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