[cisco-voip] Assistance if you are able.

[Tim Smith]

Hi Terry,

So if it was me.. for paging
- You could leave phones in place as endpoints for InformaCast only
- You should be able to trigger them from a Teams device - just by routing
calls to it (same way you can from external etc)
- If you are using panic buttons on the phones themselves, you could still
leave them in place for that
- Maybe this sounds confusing - but it's probably still less confusing than
mixing users and SNR (it should be simpler to say - cisco phones are
emergency paging only - you could even sticker them)

For contact centre queues...
- I'd leave those users and queues on Cisco
- For simpler queues - the queuing in Teams is nice.. and it's worth
playing with.. you may be able to migrate those across (but of course.. all
phones in the groups would need to go at same time)

I don't have it all top of mind right now.. it's been a busy week..
But there are problems with this Teams integration both ways.. and I don't
think there are any answers except user awareness.

The thing is.. once a user starts using Teams for Meetings.. they probably
have a good enough headset..
So at this point.. they should likely give up their deskphone.. because it
will be simpler

One problem is, once a user is on Teams.. they start searching that
directory and clicking users names.. if that user is on Teams... then that
call is likely defaulting straight through to Teams... this would never get
intercepted / sent back to CUCM for SNR.
To go around.. that.. you'd have to tell users.. dial with the extension
numbers (not by the name) - they can do via keypad, or I think we can load
into a directory attribute.. but again.. this is a little confusing.
They could also set speed dials for common contacts with extension numbers.
Extension numbers can be sent back to CUCM, and via SNR.. (I don't like
this tromboning though).

I don't think there is any great answer for the people left on Cisco..
except.. for people to know how to dial different people.. and perhaps for
individuals to advertise the preference somewhere while in this
co-existence.

Teams also has sim ring.. and it's nice and easy to set up by the user
themselves in the Teams client.. but again similar issues in terms of
tromboning etc.

As Brian said.. in terms of the mechanics.. it's using prefixes to steer.
So initially we have a prefix setup that will route across to the Teams
environment, and we can use CFWD ALL with the prefix to test.
Then later.. we hide the DN, and we have an RP that points to Teams for
each migrated DN or range.
Using the same old logic for intercluster trunks etc.. (PT / CSS etc.. to
avoid loops.. and being careful what you route).

So I would try to keep this as simple as possible..
Try to avoid any sim ring.. put people in one camp or the other
And if Teams is the direction.. think about trying to get people there
quite quickly to avoid these interop scenarios and pain

I'm not sure what you were using for the Teams SBC's.. was it CUBE or did
you put in dedicated?
At some point you want these SBC's in front.. they usually have smarter
features for routing based on LDAP attributes for Teams users.
And if possible some kind of monitoring that can see as much as possible..
(like AudioCodes OVOC).. troubleshooting Teams without this.. or even just
trying to keep tabs on Teams / monitoring etc.. it's not fun.

Bit of a brain dump - hope some of that helps :)

Cheers,

Tim.


On Thu, 8 Sept 2022 at 02:21, Terry Oakley <Terry.Oakley at rdpolytech.ca>
wrote:

> Thanks Tim…   Answers below.
>
>
>
> I would probably try and avoid SNR.  Ok although SNR may have use based
> on below.
>
> I think overall, it's going to give you problems.
> I think experience is going to be better if people are fully running on
> one or the other - and you just route between them.   Agreed but based on
> below.
>
> If you are moving away from Cisco.. what's the reasoning for still ringing
> a desk phone?   We have a number of queues/contact center that we need to
> leave in place for the next term(s) and we use our Cisco phones (using
> Singlewire InformaCast) to provide panic buttons in critical areas as well
> as the emergency notifier in all of our meeting/classroom and lecture
> spaces, so at this point we will continue to use both the Cisco phone and
> Teams Voice client.   That is our mess right now.  With that being said I
> am curious how you would proceed.
>
>
>
>
>
> *From:* Tim Smith <tim.smith at enject.com.au>
> *Sent:* Tuesday, September 6, 2022 4:39 PM
> *To:* Terry Oakley <Terry.Oakley at rdpolytech.ca>
> *Cc:* voip puck <cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] Assistance if you are able.
>
>
>
> CAUTION: This email is from an external source. Do not click links or open
> attachments unless you recognize the sender and know the content is safe.
>
> Hi Terry,
>
>
>
> I would probably try and avoid SNR.
>
> I think overall, it's going to give you problems.
> I think experience is going to be better if people are fully running on
> one or the other - and you just route between them.
>
> If you are moving away from Cisco.. what's the reasoning for still ringing
> a desk phone?
>
>
>
> What SBC are you using for Teams?
>
>
>
> Cheers,
>
>
>
> Tim
>
>
>
>
>
> On Wed, 7 Sept 2022 at 07:12, Terry Oakley <Terry.Oakley at rdpolytech.ca>
> wrote:
>
> We are adding MS Teams voice to our Cisco environment.    What I am hoping
> to do is use the feature of Single Number Reach (SNR) with Remote
> destination so that callers into our PRI will continue to be handled by the
> CUCM but also ring at the MS Teams voice device if setup.   So what I am
> trying to do is take a call from the PSTN into the CUCM and using Single
> Number Reach ring the Cisco phone (if present) and also send the call out
> to the trunk and SBC to be sent to the MS Teams voice device.     I have
> been able to get the SNR to work to my cell phone but I have hit a mental
> block, namely me, in now making this work to move the call to the SBC via
> the configured trunk.
>
>
>
> I am thinking I need to setup a translation pattern to make this work but
> I am only about 67% sure I am heading in the right direction.   The other
> issue is that our Cisco support has been canceled in an effort to save
> money so I am working on a production system with very little support.
> Such fun.
>
>
>
> Any assistance would be wonderfully accepted.
>
>
>
> Terry
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20220908/ca582ab8/attachment.htm>