[cisco-voip] Jabber/CIPC and QoS

Wed Jan 4 16:08:38 EST 2017

Ben, here's the link to the site and the session video:
https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=89103&backBtn=true

On Wed, Jan 4, 2017 at 11:44 AM, Ryan Huff <ryanhuff at outlook.com> wrote:

> Yes, TRP does have some drawbacks; video, binary floor control BUT, works
> great for voice media. It's a heavy overhead and isn't a complete solution
> but works in a pinch if you're dealing with some C Level users that "just
> want the computer phone to work".
>
> I have also been known to swap out the network card in user pcs for dual
> interface cards, then use a persistent route in the PC to force the soft
> phone's traffic to its call control server out of one interface that is on
> the voice network (leaving the other interface on the data network).
>
> A crude solution, but it worked well in a situation where the networking
> gear wouldn't have supported what we would've needed to do with QOS. Dual
> port PC network cards, even in bulk, are a heck of a lot cheaper than new
> networking gear.
>
> Yikes, giving myself flashbacks from rehashing all these memories of being
> a network admin for a nonprofit .... need some coffee ....
>
> On Jan 4, 2017, at 11:27 AM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>
> I would have loved to do MTP resources across the board... helps with
> security as well, less holes to open up. But I found a few features that
> wouldn't work, like desktop sharing, etc. If they supported all features
> with MTP, I'd would have likely been able to justify a couple of routers to
> do it.
>
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst, Network Infrastructure
> Computing and Communications Services (CCS)
> University of Guelph
>
> 519-824-4120 Ext 56354 <(519)%20824-4120>
> lelio at uoguelph.ca
> www.uoguelph.ca/ccs
> Room 037, Animal Science and Nutrition Building
> Guelph, Ontario, N1G 2W1
>
>
>
> ------------------------------
> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of Ben
> Amick <bamick at HumanArc.com>
> *Sent:* Wednesday, January 4, 2017 11:18 AM
> *To:* Evgeny Izetov; Ryan Huff
> *Cc:* Cisco VoIP Group
> *Subject:* Re: [cisco-voip] Jabber/CIPC and QoS
>
>
> Evgeny,
>
> That’s great, and I was able to find the PDF from the session but I can’t
> seem to remember how to find the site that has the recordings of the
> sessions – could you provide a link to that?
>
>
>
> Ryan,
>
> That sounds like a solid idea for when QoS is absolutely absolutely
> necessary, but I have nowhere near enough MTP resources to do that for all
> the softphones in my org.
>
>
>
> *Ben Amick*
>
> Telecom Analyst
>
>
>
> *From:* Evgeny Izetov [mailto:eizetov at gmail.com <eizetov at gmail.com>]
> *Sent:* Tuesday, January 03, 2017 10:15 PM
> *To:* Ryan Huff <ryanhuff at outlook.com>
> *Cc:* Ben Amick <bamick at HumanArc.com>; Cisco VoIP Group <
> cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] Jabber/CIPC and QoS
>
>
>
> I saw a CiscoLive! session recently that seemed to recommend the ports and
> access-lists approach. The idea is that you can now specify separate port
> ranges for audio and video in SIP Profile. The session goes quite in depth
> and is worth the watch:
>
> BRKCOL-2616 - QoS Strategies and Smart Media Techniques for Collaboration
> Deployments (2016 Berlin) - 2 Hours
>
>
>
> On Tue, Jan 3, 2017 at 9:49 PM, Ryan Huff <ryanhuff at outlook.com> wrote:
>
> I see; while this is by no means a complete solution, it may help. I'm
> assuming Cisco based soft phones (CIPC, CSF, BOT, TAB ... etc).
>
>
>
> You may try Trusted Relay Points (set in the device level configuration).
> This does rely and depend on your media resource architecture and design;
> i.e. you'll need to have media resources that support TRP available.
>
>
>
> Using TRP on the device config for a soft phone will cause CUCM to
> dynamically insert an MTP in the call flow which will allow for adherence
> to QOS trust policies and offer a predetermined network path for call flows
> in an otherwise untrusted network (presumably, the data network).
>
> -Ryan
>
>
>
>
>
> Sent from my iPhone
>
> On Jan 3, 2017, at 9:30 PM, Ben Amick <bamick at HumanArc.com> wrote:
>
> Only for softphones. Currently most of our servers live on the same LAN as
> end users, so yeah. Hardphones have their own VLAN so its not as bad. In
> the future it won’t be that way but for the time being it is.
>
>
>
> *Ben Amick*
>
> Telecom Analyst
>
>
>
> *From:* Ryan Huff [mailto:ryanhuff at outlook.com <ryanhuff at outlook.com>]
> *Sent:* Tuesday, January 03, 2017 9:18 PM
> *To:* Ben Amick <bamick at HumanArc.com>
> *Cc:* NateCCIE <nateccie at gmail.com>; Cisco VoIP Group <
> cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] Jabber/CIPC and QoS
>
>
>
> Ben,
>
>
>
> By flat network; I am to assume that there is no layer 2 partition between
> rtp/signaling and general data traffic?
>
>
> On Jan 3, 2017, at 9:15 PM, Ben Amick <bamick at HumanArc.com> wrote:
>
> Yeah, I have the luck of having MPLS right now, and I don’t see us going
> iWAN for a while for various reasons. QoS on the WAN right now even isn’t
> my issue, it’s QoS on the LAN. Right now we have a relatively flat network,
> and certain segments of our troupe **cough**developers**cough** seems to
> have made our internal traffic ugly, to the point that I may have to do an
> analysis of it, as we’re having just random periods here and there where
> calls just have horrible quality, of the type you normally see fixed by QoS
>
>
>
> *Ben Amick*
>
> Telecom Analyst
>
>
>
> *From:* Ryan Huff [mailto:ryanhuff at outlook.com <ryanhuff at outlook.com>]
> *Sent:* Tuesday, January 03, 2017 8:40 PM
> *To:* NateCCIE <nateccie at gmail.com>
> *Cc:* Ben Amick <bamick at HumanArc.com>; Cisco VoIP Group <
> cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] Jabber/CIPC and QoS
>
>
>
> It's a shame really ... MPLS is far superior IMO, for many reasons. Call
> it iWAN, DMVPN, AutoVPN .... whatever, it is still as Nate says, public
> Internet.
>
>
>
> Try getting a 30 or 60 minute SLA with escalation after 15 minutes from a
> public Comcast or Time Warner/Charter package.
>
>
> On Jan 3, 2017, at 7:53 PM, NateCCIE <nateccie at gmail.com> wrote:
>
> Or take the most approach of do nothing.
>
>
>
> My personal favorite is to use codecs where QoS matters less, like iLBC,
> OPUS, etc.
>
>
>
> So many business are getting rid of the QoS capable WAN and just doing
> VPNs, even if they have fancy names that make it sound better than public
> internet.
>
> Sent from my iPhone
>
>
> On Jan 3, 2017, at 2:25 PM, Ben Amick <bamick at HumanArc.com> wrote:
>
> So, I know this is an age old question that’s debated, but I’ve been
> wondering if anyone here has a perspective here in regards to QoS for
> softphones. Obviously, with hardphones, you usually partition a separate
> VLAN with AutoQoS/DSCP tags, but that isn’t applicable with softphones.
>
>
>
> I’ve heard of three different options in the past, neither of which seem
> to be very simple to deploy, but all seem to be Jabber-centric.
>
> 1.      Configuring windows to perform DSCP tagging, and do DSCP QoS on
> the switches they are connected to, as well as trusting the device.
> Problems: Requires users to be local admins, openings for abuse and network
> impact due to blind PC trust.
>
> 2.      Configuring your switches with an access list that recognizes the
> ports Jabber does outbound to attach DSCP tags to them. Problems: Other
> programs could theoretically use those ports
>
> 3.      Installing Medianet services on all jabber clients; Configure all
> switches for medianet tagging. Problem: (I think?) Requires newer switches
> to use, maybe needs an additional server (I vaguely remember possibly
> needing prime collab?)?
>
>
>
> Maybe I’m missing some things, but what approach have you guys taken for
> softphone/Jabber QoS? And on top of that, what options are there for CIPC
> (I know there’s the auto qos trust cisco-softphone for cisco switches, but
> I don’t believe there’s a solution other than #1 for non-cisco switches)?
>
>
>
> *Ben Amick*
>
> Telecom Analyst
>
>
>
>
> Confidentiality Note: This message is intended for use only by the
> individual or entity to which it is addressed and may contain information
> that is privileged, confidential, and exempt from disclosure under
> applicable law. If the reader of this message is not the intended recipient
> or the employee or agent responsible for delivering the message to the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether electronic or
> hard copy. Thank you
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <http://cp.mcafee.com/d/avndzgOcxMQrhoupod7b9EV79CXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCSnQTXeffZvzhOZsQsFThWZOWr8V7AhPdTC7xTkhjmKCHtBfBgY-F6lK1FJ4SCrLOb0VVdOXMWVKVIDeqR4INpKNnwqj-f0T1dnoovaAVgtHBFkJkKpH9oT4JI2rrHEaGTc-JiLbCQnAkPhOr1vF6y0QJSBiRiVCIBziWq808Qwg-e2gq5x8Qgr10Qg0fkodIK6Y1tK-rNm>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <http://cp.mcafee.com/d/2DRPoOd2hJ5xVBwQsICzAsCrKrhhpvpj73AjhOrhhpvpj7ffICQkmnTDNPPXxJ55MQsCzCZXETdAdlBoG2yrqKMSdKndASRtxIrsKrpvjvIUY_R-d7bRPhODt7HTbFIzAuh7cTuou7th5dqWqJSk-l3PWApmU6CQPqpK_8I3DATbL3HCXCOsVHkiP5CX5u1FfUY3s4RtxxYGjB1SKmBiRiVCIBzsiSM9JKKwGHsPWRaYKrhuhjd79I5-Aq83iTqlblbCqOmdbFEw0zi13UU91Em4zh1I43h00ZhwSOUryKrT3IPkd-jE>
>
>
> Confidentiality Note: This message is intended for use only by the
> individual or entity to which it is addressed and may contain information
> that is privileged, confidential, and exempt from disclosure under
> applicable law. If the reader of this message is not the intended recipient
> or the employee or agent responsible for delivering the message to the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether electronic or
> hard copy. Thank you
>
>
> Confidentiality Note: This message is intended for use only by the
> individual or entity to which it is addressed and may contain information
> that is privileged, confidential, and exempt from disclosure under
> applicable law. If the reader of this message is not the intended recipient
> or the employee or agent responsible for delivering the message to the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether electronic or
> hard copy. Thank you
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <http://cp.mcafee.com/d/avndy1J5xVBwQsCzBMsCrKrhhpvpj73AjhOrhhpvpj7ffICQkmnTDNPPXxJ55MQsCzCZXETdAdlBoG2yrqKMSdKndASRtxIrsKrud7bPBD7D-LOryrPPXWvnKnjh7cYMed7aqbz0XG8FHnjlKOeVkffGhBrwqrhdICXYyevvjvuhjsdTdAVPmEBCbdSaY3ivNU6U9GX33VkDa3JsJaBGBPdpb6_AaveFA54hfBPqrMVBAS2_id41FrJaBGBPdpb6BQQg0hF0xYs4wQb2hEwS21Ew0uEMrpsdwmX6sqwk>
>
>
>
> Confidentiality Note: This message is intended for use only by the
> individual or entity to which it is addressed and may contain information
> that is privileged, confidential, and exempt from disclosure under
> applicable law. If the reader of this message is not the intended recipient
> or the employee or agent responsible for delivering the message to the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether electronic or
> hard copy. Thank you
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170104/3f91479c/attachment.html>