Re: [cisco-voip] 8851 Rollout

[Stephen Welsh]

Absolutely, and incredibly simply ;)

If you have not heard of our new product ‘MigrationFX’ this marketing video 
summarises the benefits (https://youtu.be/pRuVKyhgSbs) but here are some key 
points:

* Zero-Touch Migration automatically detects the phone replacement and migrate 
the phone automatically (Demo - https://youtu.be/AwRsswdmwPA)
* Self Service Migration allows the end user to replace their phone by logging 
in with their username/password
* Search by Extension allows the ‘old’ phone to be found by extension number 
then migrated
* All device/user/button/services/speed-dials etc. are maintained
*

Note: The next update will also provision new phones too (i.e. a simpler 
version of TAPS), so if it’s an upgrade of endpoints, RMA replacement of a 
faulty device or a new handset deployment MigrationFX has you covered.

The best thing of all is the price, if you trade-in 100 or more phones via 
Cisco’s trade-in program courtesy of Cisco it’s FREE :)
Just use the ‘L-CP-MGFX-PROMO=’ GPL part code as part of the TMP order. It’s 
also order able via the Cisco GPL if you don’t want to use the trade-in program

http://www.unifiedfx.com/get-migrationfx-for-free/

Also,
If you (or anyone else) is attending the Cisco SEVT session on CUCM 11.5 etc. 
in San Jose next week, Cisco are running a hands-on lab on MigrationFX at the 
event.

Kind Regards

Stephen Welsh
CTO
UnifiedFX


On 12 May 2016, at 22:53, Haas, Neal 
> wrote:

We are going from 7900 series phones to 8851 phones.

Is there a software that will copy SCCP phones to SIP phones?

Neal Haas

___
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-VoIP] UCCE agents on wireless IP Communicator?

[Norton, Mike]

The thing people always seem to forget about Wi-Fi deployments is this:

“This device complies with part 15 of the FCC Rules. Operation is subject to 
the following two conditions: (1) This device may not cause harmful 
interference, and (2) this device must accept any interference received, 
including interference that may cause undesired operation.”

You have NO CONTROL over the Layer 1 medium and you share it with everybody. 
Pretending otherwise is futile.

-mn

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Ratliff (rratliff)
Sent: May-12-16 1:27 PM
To: Anthony Holloway 
Cc: Cisco VoIP Group 
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

I’m sure nothing in wireless is as simple as my tiny brain can comprehend :)

-Ryan

On May 12, 2016, at 2:58 PM, Anthony Holloway 
> wrote:

I don't think it's that simple Ryan.

The first and most important document is the Enterprise Mobility Design Guide

Reference Link:
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide.html

However, that document is really big and covers a lot more than just Jabber.  
When you get down to the topic at hand, a more manageable and bite sized 
version of that document can be read here:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/Jabber_in_WLAN/b_Jabber_in_WLAN.html

As a contrast, Jabber on a wired connection, is simply a matter of matching 
traffic flows from the client device (PC, Mac, mobile, etc.), and marking the 
packets.  This allows us to maintain our trust boundary, but provide an 
exception for the traffic flows matching Jabber.

Reference Link:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/10_6/CJAB_BK_C56DE1AB_00_cisco-jabber-106-deployment-and-installation-guide/CJAB_BK_C56DE1AB_00_cisco-jabber-106-deployment-and-installation-guide_appendix_0.html#CJAB_TK_DD601B77_00

On Thu, May 12, 2016 at 1:22 PM, Ryan Ratliff (rratliff) 
> wrote:
The difference between computers and 7925s primarily being that one walks down 
the hall and the other sits on a desk.
If you can keep the PC from roaming then it’s just a matter of proper QOS and 
available bandwidth, yes?

-Ryan

On May 12, 2016, at 2:18 PM, NateCCIE 
> wrote:

But I have yet to see a 7925 deployment that the end users are happy with. It 
is seemingly impossible for the wireless guys to get it perfect.

Sent from my iPhone

On May 12, 2016, at 10:29 AM, Ryan Ratliff (rratliff) 
> wrote:
I’ll take a slight issue with the original response about CIPC not being stable 
over wireless.

I believe the intent of the response is that realtime voice and video over 
wireless can be a challenge for a wifi environment that isn’t designed 
specifically to handle it.

Personally I’ve used CIPC and now Jabber (as a softphone) for voice and video 
calls on my laptop both in the Cisco office and at home with very little issue.
The apps themselves can handle the transport just fine, it’s the network that 
sometimes can’t handle the apps.

-Ryan

On May 12, 2016, at 7:23 AM, Thomas LeMay 
> wrote:

Hi, Ryan,

Thank you for the information.

Tom

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Wednesday, May 11, 2016 11:15 PM
To: Thomas LeMay; 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

Many moons ago in a land called Ohio, I rescued a small agent base from doing 
this ...

Aside from the obvious QOS and reliable connection issues; in that client's 
case the agents would also occasionally want to use the speakerphone function 
without a headset (PC Speaker / Mic) and without an HD/noise canceling mic this 
will usually inject audio artifacts from the speaker into the audio stream. The 
net effect is duplicated/mis understood DTMF (when using rtp-nte).

If this is unavoidable though, and your client is going to travel this path 
despite all your warnings otherwise; I would recommend the agent's PC on a 
separate SSID / Interface from the Corporate SSID / Interface and put all the 
agent's PC traffic in the EF queue (or at least trust/mark the CIPC traffic) 
and make sure there is adequate radio coverage by each agent.

If the client is looking at this as a telecommute option for employees, the 
issues are further exacerbated by the nature of having heterogeneous wireless 
connectivity (unless the business standardizes and issues wireless devices to 
employees).

Thanks,

= Ryan =


From: cisco-voip 

Re: [cisco-voip] 8851 Rollout

[Brian Meade]

MigrationFX- http://www.unifiedfx.com/

On Thu, May 12, 2016 at 5:53 PM, Haas, Neal  wrote:

> We are going from 7900 series phones to 8851 phones.
>
>
>
> Is there a software that will copy SCCP phones to SIP phones?
>
>
>
> Neal Haas
>
>
>
> ___
> 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] 8851 Rollout

[Haas, Neal]

We are going from 7900 series phones to 8851 phones.

Is there a software that will copy SCCP phones to SIP phones?

Neal Haas

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

Re: [cisco-voip] How Important is Running "Supported?"

[Norton, Mike]

When deciding whether to venture into unsupported territory, I think it is 
worth distinguishing between different types of “unsupported.”

One type of “unsupported” is when a vendor says certain pieces must be certain 
things and at certain versions, but you choose to go against their requirement.

Another type of “unsupported” is when a vendor declares that they are 
discontinuing all maintenance/development on a certain piece and that it must 
be migrated away from immediately.

Your situation is both. Cisco says browser must be a certain flavour/version to 
work with their particular solution, *and* Microsoft told EVERYBODY to get off 
IE9 months ago.

There are lots of environments where intentionally going “unsupported” is an 
acceptable risk, but IMO mixing both types of unsupported simultaneously is 
probably asking for trouble in almost all cases.

-mn


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: May-12-16 10:07 AM
To: Cisco VoIP Group 
Subject: [cisco-voip] How Important is Running "Supported?"

All,

Over the past 10 years, I have seen a multitude of deployments that were not in 
a 100% supported configuration.  Most of the time, this simply results in 
"don't ask, don't tell" and as long as you didn't need TAC support, everything 
should be fine.  I don't necessarily mean UCCX server compatibility with CUCM, 
but like phone models, firmware, IOS code, gateway models, web browsers, OS, 
Agent shared lines or LG membership, etc.

Well, recently I just ran into a non-supported setup, where it caused the 
server to hit 100% CPU utilization and cause all sorts of problems in the 
application.

It was UCCX v11 and using IE9 for Finesse.

You can read more about the difference in the browser here, if you have access:
https://communities.cisco.com/message/215058/

Otherwise the summary is basically this:
UCCX v11 introduced a new technology to support Live Data feeds from Finesse to 
CUIC: Socket.IOhttp://socket.io/.  Socket.IO uses HTTP 
WebSockets to open a single TCP 
connection from Finesse to UCCX, and then passes all updates to the data via 
this single connection.

IE9 lacks the feature to support WebSockets and the Socket.IO software 
automatically allows older browser clients to fallback to single HTTP 
GET 
calls for each data refresh interval.

This means that instead of having 100 Agents using 1 socket each, for a total 
of 100 connections that are persistent, you'll end up 100 Agents using hundreds 
of connections (quickly setup and then closed) throughout the day, resulting in 
what is essentially a DoS attack on the SocketIO service.

In theory, this would happen with any browser that doesn't support WebSockets.

So, how important is being in compliance when it comes to what's supported and 
not supported?  Do you typically bend the rules, or are you rigid and strict?


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

Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

[Ryan Ratliff (rratliff)]

I’m sure nothing in wireless is as simple as my tiny brain can comprehend :)

-Ryan

On May 12, 2016, at 2:58 PM, Anthony Holloway 
> wrote:

I don't think it's that simple Ryan.

The first and most important document is the Enterprise Mobility Design Guide

Reference Link:
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide.html

However, that document is really big and covers a lot more than just Jabber.  
When you get down to the topic at hand, a more manageable and bite sized 
version of that document can be read here:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/Jabber_in_WLAN/b_Jabber_in_WLAN.html

As a contrast, Jabber on a wired connection, is simply a matter of matching 
traffic flows from the client device (PC, Mac, mobile, etc.), and marking the 
packets.  This allows us to maintain our trust boundary, but provide an 
exception for the traffic flows matching Jabber.

Reference Link:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/10_6/CJAB_BK_C56DE1AB_00_cisco-jabber-106-deployment-and-installation-guide/CJAB_BK_C56DE1AB_00_cisco-jabber-106-deployment-and-installation-guide_appendix_0.html#CJAB_TK_DD601B77_00

On Thu, May 12, 2016 at 1:22 PM, Ryan Ratliff (rratliff) 
> wrote:
The difference between computers and 7925s primarily being that one walks down 
the hall and the other sits on a desk.
If you can keep the PC from roaming then it’s just a matter of proper QOS and 
available bandwidth, yes?

-Ryan

On May 12, 2016, at 2:18 PM, NateCCIE 
> wrote:

But I have yet to see a 7925 deployment that the end users are happy with. It 
is seemingly impossible for the wireless guys to get it perfect.

Sent from my iPhone

On May 12, 2016, at 10:29 AM, Ryan Ratliff (rratliff) 
> wrote:

I’ll take a slight issue with the original response about CIPC not being stable 
over wireless.

I believe the intent of the response is that realtime voice and video over 
wireless can be a challenge for a wifi environment that isn’t designed 
specifically to handle it.

Personally I’ve used CIPC and now Jabber (as a softphone) for voice and video 
calls on my laptop both in the Cisco office and at home with very little issue.
The apps themselves can handle the transport just fine, it’s the network that 
sometimes can’t handle the apps.

-Ryan

On May 12, 2016, at 7:23 AM, Thomas LeMay 
> wrote:

Hi, Ryan,

Thank you for the information.

Tom

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Wednesday, May 11, 2016 11:15 PM
To: Thomas LeMay; 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

Many moons ago in a land called Ohio, I rescued a small agent base from doing 
this ...

Aside from the obvious QOS and reliable connection issues; in that client's 
case the agents would also occasionally want to use the speakerphone function 
without a headset (PC Speaker / Mic) and without an HD/noise canceling mic this 
will usually inject audio artifacts from the speaker into the audio stream. The 
net effect is duplicated/mis understood DTMF (when using rtp-nte).

If this is unavoidable though, and your client is going to travel this path 
despite all your warnings otherwise; I would recommend the agent's PC on a 
separate SSID / Interface from the Corporate SSID / Interface and put all the 
agent's PC traffic in the EF queue (or at least trust/mark the CIPC traffic) 
and make sure there is adequate radio coverage by each agent.

If the client is looking at this as a telecommute option for employees, the 
issues are further exacerbated by the nature of having heterogeneous wireless 
connectivity (unless the business standardizes and issues wireless devices to 
employees).

Thanks,

= Ryan =


From: cisco-voip 
> 
on behalf of Thomas LeMay 
>
Sent: Wednesday, May 11, 2016 10:42 PM
To: 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

How about Jabber? Is Jabber stable enough even though it does not support 
multiple lines? My thought would be no based on the same reason for CIPC.

Tom

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Burtch
Sent: Wednesday, May 11, 2016 2:58 PM
To: Nick Barnett
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] UCCE agents on wireless IP Communicator?

This is a terrible idea. CIPC not stable enough on wireless. Introduce VPN and 
this is a disaster 

Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

[Anthony Holloway]

I don't think it's that simple Ryan.

The first and most important document is the Enterprise Mobility Design
Guide

Reference Link:
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide.html

However, that document is really big and covers a lot more than just
Jabber.  When you get down to the topic at hand, a more manageable and bite
sized version of that document can be read here:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/Jabber_in_WLAN/b_Jabber_in_WLAN.html

As a contrast, Jabber on a wired connection, is simply a matter of matching
traffic flows from the client device (PC, Mac, mobile, etc.), and marking
the packets.  This allows us to maintain our trust boundary, but provide an
exception for the traffic flows matching Jabber.

Reference Link:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/10_6/CJAB_BK_C56DE1AB_00_cisco-jabber-106-deployment-and-installation-guide/CJAB_BK_C56DE1AB_00_cisco-jabber-106-deployment-and-installation-guide_appendix_0.html#CJAB_TK_DD601B77_00

On Thu, May 12, 2016 at 1:22 PM, Ryan Ratliff (rratliff)  wrote:

> The difference between computers and 7925s primarily being that one walks
> down the hall and the other sits on a desk.
> If you can keep the PC from roaming then it’s just a matter of proper QOS
> and available bandwidth, yes?
>
> -Ryan
>
> On May 12, 2016, at 2:18 PM, NateCCIE  wrote:
>
> But I have yet to see a 7925 deployment that the end users are happy with.
> It is seemingly impossible for the wireless guys to get it perfect.
>
> Sent from my iPhone
>
> On May 12, 2016, at 10:29 AM, Ryan Ratliff (rratliff) 
> wrote:
>
> I’ll take a slight issue with the original response about CIPC not being
> stable over wireless.
>
> I believe the intent of the response is that realtime voice and video over
> wireless can be a challenge for a wifi environment that isn’t designed
> specifically to handle it.
>
> Personally I’ve used CIPC and now Jabber (as a softphone) for voice and
> video calls on my laptop both in the Cisco office and at home with very
> little issue.
> The apps themselves can handle the transport just fine, it’s the network
> that sometimes can’t handle the apps.
>
> -Ryan
>
> On May 12, 2016, at 7:23 AM, Thomas LeMay  wrote:
>
> Hi, Ryan,
>
> Thank you for the information.
>
> Tom
>
> *From:* Ryan Huff [mailto:ryanh...@outlook.com ]
> *Sent:* Wednesday, May 11, 2016 11:15 PM
> *To:* Thomas LeMay; 'Ryan Burtch'; 'Nick Barnett'
> *Cc:* 'Cisco VoIP Group'
> *Subject:* Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP
> Communicator?
>
> Many moons ago in a land called Ohio, I rescued a small agent base from
> doing this ...
>
> Aside from the obvious QOS and reliable connection issues; in that
> client's case the agents would also occasionally want to use the
> speakerphone function without a headset (PC Speaker / Mic) and without an
> HD/noise canceling mic this will usually inject audio artifacts from the
> speaker into the audio stream. The net effect is duplicated/mis understood
> DTMF (when using rtp-nte).
>
> If this is unavoidable though, and your client is going to travel this
> path despite all your warnings otherwise; I would recommend the agent's PC
> on a separate SSID / Interface from the Corporate SSID / Interface and put
> all the agent's PC traffic in the EF queue (or at least trust/mark the CIPC
> traffic) and make sure there is adequate radio coverage by each agent.
>
> If the client is looking at this as a telecommute option for employees,
> the issues are further exacerbated by the nature of having heterogeneous
> wireless connectivity (unless the business standardizes and issues wireless
> devices to employees).
>
> Thanks,
>
> = Ryan =
>
> --
> *From:* cisco-voip  on behalf of
> Thomas LeMay 
> *Sent:* Wednesday, May 11, 2016 10:42 PM
> *To:* 'Ryan Burtch'; 'Nick Barnett'
> *Cc:* 'Cisco VoIP Group'
> *Subject:* Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP
> Communicator?
>
> How about Jabber? Is Jabber stable enough even though it does not support
> multiple lines? My thought would be no based on the same reason for CIPC.
>
> Tom
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net
> ] *On Behalf Of *Ryan Burtch
> *Sent:* Wednesday, May 11, 2016 2:58 PM
> *To:* Nick Barnett
> *Cc:* Cisco VoIP Group
> *Subject:* Re: [cisco-voip] UCCE agents on wireless IP Communicator?
>
> This is a terrible idea. CIPC not stable enough on wireless. Introduce VPN
> and this is a disaster waiting to happen.
>
>
>
>
> Sincerely,
>
> Ryan Burtch
>
> On Tue, May 10, 2016 at 1:25 PM, Nick Barnett 
> wrote:
> Does anyone have any experiences running 

Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

[Ryan Ratliff (rratliff)]

The difference between computers and 7925s primarily being that one walks down 
the hall and the other sits on a desk.
If you can keep the PC from roaming then it’s just a matter of proper QOS and 
available bandwidth, yes?

-Ryan

On May 12, 2016, at 2:18 PM, NateCCIE 
> wrote:

But I have yet to see a 7925 deployment that the end users are happy with. It 
is seemingly impossible for the wireless guys to get it perfect.

Sent from my iPhone

On May 12, 2016, at 10:29 AM, Ryan Ratliff (rratliff) 
> wrote:

I’ll take a slight issue with the original response about CIPC not being stable 
over wireless.

I believe the intent of the response is that realtime voice and video over 
wireless can be a challenge for a wifi environment that isn’t designed 
specifically to handle it.

Personally I’ve used CIPC and now Jabber (as a softphone) for voice and video 
calls on my laptop both in the Cisco office and at home with very little issue.
The apps themselves can handle the transport just fine, it’s the network that 
sometimes can’t handle the apps.

-Ryan

On May 12, 2016, at 7:23 AM, Thomas LeMay 
> wrote:

Hi, Ryan,

Thank you for the information.

Tom

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Wednesday, May 11, 2016 11:15 PM
To: Thomas LeMay; 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

Many moons ago in a land called Ohio, I rescued a small agent base from doing 
this ...

Aside from the obvious QOS and reliable connection issues; in that client's 
case the agents would also occasionally want to use the speakerphone function 
without a headset (PC Speaker / Mic) and without an HD/noise canceling mic this 
will usually inject audio artifacts from the speaker into the audio stream. The 
net effect is duplicated/mis understood DTMF (when using rtp-nte).

If this is unavoidable though, and your client is going to travel this path 
despite all your warnings otherwise; I would recommend the agent's PC on a 
separate SSID / Interface from the Corporate SSID / Interface and put all the 
agent's PC traffic in the EF queue (or at least trust/mark the CIPC traffic) 
and make sure there is adequate radio coverage by each agent.

If the client is looking at this as a telecommute option for employees, the 
issues are further exacerbated by the nature of having heterogeneous wireless 
connectivity (unless the business standardizes and issues wireless devices to 
employees).

Thanks,

= Ryan =


From: cisco-voip 
> 
on behalf of Thomas LeMay 
>
Sent: Wednesday, May 11, 2016 10:42 PM
To: 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

How about Jabber? Is Jabber stable enough even though it does not support 
multiple lines? My thought would be no based on the same reason for CIPC.

Tom

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Burtch
Sent: Wednesday, May 11, 2016 2:58 PM
To: Nick Barnett
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] UCCE agents on wireless IP Communicator?

This is a terrible idea. CIPC not stable enough on wireless. Introduce VPN and 
this is a disaster waiting to happen.




Sincerely,

Ryan Burtch

On Tue, May 10, 2016 at 1:25 PM, Nick Barnett 
> wrote:
Does anyone have any experiences running CIPC on wireless for UCCE agents? It 
sounds like a...um, bad idea to me.  One of my customers is moving to this 
"design."

A cursory look at the 10.0 SRND didn't show any hits for "wired" or "wireless".

thanks,
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

___
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-VoIP] UCCE agents on wireless IP Communicator?

[NateCCIE]

But I have yet to see a 7925 deployment that the end users are happy with. It 
is seemingly impossible for the wireless guys to get it perfect. 

Sent from my iPhone

> On May 12, 2016, at 10:29 AM, Ryan Ratliff (rratliff)  
> wrote:
> 
> I’ll take a slight issue with the original response about CIPC not being 
> stable over wireless.
> 
> I believe the intent of the response is that realtime voice and video over 
> wireless can be a challenge for a wifi environment that isn’t designed 
> specifically to handle it. 
> 
> Personally I’ve used CIPC and now Jabber (as a softphone) for voice and video 
> calls on my laptop both in the Cisco office and at home with very little 
> issue. 
> The apps themselves can handle the transport just fine, it’s the network that 
> sometimes can’t handle the apps. 
> 
> -Ryan
> 
> On May 12, 2016, at 7:23 AM, Thomas LeMay  wrote:
> 
> Hi, Ryan,
>  
> Thank you for the information.
>  
> Tom
>  
> From: Ryan Huff [mailto:ryanh...@outlook.com] 
> Sent: Wednesday, May 11, 2016 11:15 PM
> To: Thomas LeMay; 'Ryan Burtch'; 'Nick Barnett'
> Cc: 'Cisco VoIP Group'
> Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP 
> Communicator?
>  
> Many moons ago in a land called Ohio, I rescued a small agent base from doing 
> this ...
>  
> Aside from the obvious QOS and reliable connection issues; in that client's 
> case the agents would also occasionally want to use the speakerphone function 
> without a headset (PC Speaker / Mic) and without an HD/noise canceling mic 
> this will usually inject audio artifacts from the speaker into the audio 
> stream. The net effect is duplicated/mis understood DTMF (when using rtp-nte).
>  
> If this is unavoidable though, and your client is going to travel this path 
> despite all your warnings otherwise; I would recommend the agent's PC on a 
> separate SSID / Interface from the Corporate SSID / Interface and put all the 
> agent's PC traffic in the EF queue (or at least trust/mark the CIPC traffic) 
> and make sure there is adequate radio coverage by each agent. 
>  
> If the client is looking at this as a telecommute option for employees, the 
> issues are further exacerbated by the nature of having heterogeneous wireless 
> connectivity (unless the business standardizes and issues wireless devices to 
> employees).
>  
> Thanks,
>  
> = Ryan =
>  
> From: cisco-voip  on behalf of Thomas 
> LeMay 
> Sent: Wednesday, May 11, 2016 10:42 PM
> To: 'Ryan Burtch'; 'Nick Barnett'
> Cc: 'Cisco VoIP Group'
> Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP 
> Communicator?
>  
> How about Jabber? Is Jabber stable enough even though it does not support 
> multiple lines? My thought would be no based on the same reason for CIPC.
>  
> Tom
>  
> From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
> Ryan Burtch
> Sent: Wednesday, May 11, 2016 2:58 PM
> To: Nick Barnett
> Cc: Cisco VoIP Group
> Subject: Re: [cisco-voip] UCCE agents on wireless IP Communicator?
>  
> This is a terrible idea. CIPC not stable enough on wireless. Introduce VPN 
> and this is a disaster waiting to happen.
> 
>  
>  
>  
> Sincerely,
>  
> Ryan Burtch
>  
> On Tue, May 10, 2016 at 1:25 PM, Nick Barnett  wrote:
> Does anyone have any experiences running CIPC on wireless for UCCE agents? It 
> sounds like a...um, bad idea to me.  One of my customers is moving to this 
> "design."
>  
> A cursory look at the 10.0 SRND didn't show any hits for "wired" or 
> "wireless".
>  
> thanks,
> 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
> 
> ___
> 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-VoIP] UCCE agents on wireless IP Communicator?

[Ryan Ratliff (rratliff)]

I’ll take a slight issue with the original response about CIPC not being stable 
over wireless.

I believe the intent of the response is that realtime voice and video over 
wireless can be a challenge for a wifi environment that isn’t designed 
specifically to handle it.

Personally I’ve used CIPC and now Jabber (as a softphone) for voice and video 
calls on my laptop both in the Cisco office and at home with very little issue.
The apps themselves can handle the transport just fine, it’s the network that 
sometimes can’t handle the apps.

-Ryan

On May 12, 2016, at 7:23 AM, Thomas LeMay 
> wrote:

Hi, Ryan,

Thank you for the information.

Tom

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Wednesday, May 11, 2016 11:15 PM
To: Thomas LeMay; 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

Many moons ago in a land called Ohio, I rescued a small agent base from doing 
this ...

Aside from the obvious QOS and reliable connection issues; in that client's 
case the agents would also occasionally want to use the speakerphone function 
without a headset (PC Speaker / Mic) and without an HD/noise canceling mic this 
will usually inject audio artifacts from the speaker into the audio stream. The 
net effect is duplicated/mis understood DTMF (when using rtp-nte).

If this is unavoidable though, and your client is going to travel this path 
despite all your warnings otherwise; I would recommend the agent's PC on a 
separate SSID / Interface from the Corporate SSID / Interface and put all the 
agent's PC traffic in the EF queue (or at least trust/mark the CIPC traffic) 
and make sure there is adequate radio coverage by each agent.

If the client is looking at this as a telecommute option for employees, the 
issues are further exacerbated by the nature of having heterogeneous wireless 
connectivity (unless the business standardizes and issues wireless devices to 
employees).

Thanks,

= Ryan =


From: cisco-voip 
> 
on behalf of Thomas LeMay 
>
Sent: Wednesday, May 11, 2016 10:42 PM
To: 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

How about Jabber? Is Jabber stable enough even though it does not support 
multiple lines? My thought would be no based on the same reason for CIPC.

Tom

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Burtch
Sent: Wednesday, May 11, 2016 2:58 PM
To: Nick Barnett
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] UCCE agents on wireless IP Communicator?

This is a terrible idea. CIPC not stable enough on wireless. Introduce VPN and 
this is a disaster waiting to happen.




Sincerely,

Ryan Burtch

On Tue, May 10, 2016 at 1:25 PM, Nick Barnett 
> wrote:
Does anyone have any experiences running CIPC on wireless for UCCE agents? It 
sounds like a...um, bad idea to me.  One of my customers is moving to this 
"design."

A cursory look at the 10.0 SRND didn't show any hits for "wired" or "wireless".

thanks,
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

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

[cisco-voip] How Important is Running "Supported?"

[Anthony Holloway]

All,

Over the past 10 years, I have seen a multitude of deployments that were
not in a 100% supported configuration.  Most of the time, this simply
results in "don't ask, don't tell" and as long as you didn't need TAC
support, everything should be fine.  I don't necessarily mean UCCX server
compatibility with CUCM, but like phone models, firmware, IOS code, gateway
models, web browsers, OS, Agent shared lines or LG membership, etc.

Well, recently I just ran into a non-supported setup, where it caused the
server to hit 100% CPU utilization and cause all sorts of problems in the
application.

It was UCCX v11 and using IE9 for Finesse.

You can read more about the difference in the browser here, if you have
access:
https://communities.cisco.com/message/215058/

Otherwise the summary is basically this:
UCCX v11 introduced a new technology to support Live Data feeds from
Finesse to CUIC: Socket.IOhttp://socket.io/ .  Socket.IO
uses HTTP WebSockets  to open a
single TCP connection from Finesse to UCCX, and then passes all updates to
the data via this single connection.

IE9 lacks the feature to support WebSockets and the Socket.IO software
automatically allows older browser clients to fallback to single HTTP GET

calls for each data refresh interval.

This means that instead of having 100 Agents using 1 socket each, for a
total of 100 connections that are persistent, you'll end up 100 Agents
using hundreds of connections (quickly setup and then closed) throughout
the day, resulting in what is essentially a DoS attack on the SocketIO
service.

In theory, this would happen with any browser that doesn't support
WebSockets.

So, how important is being in compliance when it comes to what's supported
and not supported?  Do you typically bend the rules, or are you rigid and
strict?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP Communicator?

[Thomas LeMay]

Hi, Ryan,

 

Thank you for the information.

 

Tom

 

From: Ryan Huff [mailto:ryanh...@outlook.com] 
Sent: Wednesday, May 11, 2016 11:15 PM
To: Thomas LeMay; 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP
Communicator?

 

Many moons ago in a land called Ohio, I rescued a small agent base from
doing this ...

 

Aside from the obvious QOS and reliable connection issues; in that client's
case the agents would also occasionally want to use the speakerphone
function without a headset (PC Speaker / Mic) and without an HD/noise
canceling mic this will usually inject audio artifacts from the speaker into
the audio stream. The net effect is duplicated/mis understood DTMF (when
using rtp-nte).

 

If this is unavoidable though, and your client is going to travel this path
despite all your warnings otherwise; I would recommend the agent's PC on a
separate SSID / Interface from the Corporate SSID / Interface and put all
the agent's PC traffic in the EF queue (or at least trust/mark the CIPC
traffic) and make sure there is adequate radio coverage by each agent. 

 

If the client is looking at this as a telecommute option for employees, the
issues are further exacerbated by the nature of having heterogeneous
wireless connectivity (unless the business standardizes and issues wireless
devices to employees).

 

Thanks,

 

= Ryan =

 

  _  

From: cisco-voip  on behalf of Thomas
LeMay 
Sent: Wednesday, May 11, 2016 10:42 PM
To: 'Ryan Burtch'; 'Nick Barnett'
Cc: 'Cisco VoIP Group'
Subject: Re: [cisco-voip] [cisco-VoIP] UCCE agents on wireless IP
Communicator? 

 

How about Jabber? Is Jabber stable enough even though it does not support
multiple lines? My thought would be no based on the same reason for CIPC.

 

Tom

 

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of
Ryan Burtch
Sent: Wednesday, May 11, 2016 2:58 PM
To: Nick Barnett
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] UCCE agents on wireless IP Communicator?

 

This is a terrible idea. CIPC not stable enough on wireless. Introduce VPN
and this is a disaster waiting to happen.




 

 

 

Sincerely,

 

Ryan Burtch

 

On Tue, May 10, 2016 at 1:25 PM, Nick Barnett 
wrote:

Does anyone have any experiences running CIPC on wireless for UCCE agents?
It sounds like a...um, bad idea to me.  One of my customers is moving to
this "design."

 

A cursory look at the 10.0 SRND didn't show any hits for "wired" or
"wireless".

 

thanks,

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] Cisco CUCM 7 SMTP issue

[Asim Mekki Basheer]

yes its allowed from Exchange side
From: ryanh...@outlook.com
To: asim_...@hotmail.com
CC: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Cisco CUCM 7 SMTP issue
Date: Wed, 11 May 2016 09:45:18 +






Have you also made sure the IP address of CUCM is an allowed mail relay on your 
Exchange server?



Thanks,



Ryan



On May 11, 2016, at 4:01 AM, Asim Mekki Basheer  wrote:






we have Cisco CUCM 7 we configured SMTP to send email in certain Alert, the 
problem that in From RTMT tool showed that email sent to my email but idint 
receive any email



i checked firewall is opened toward exchange server port 25 , from CLI how can 
we test the port connectivity to exchange server (telnet command not available)






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