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 <[email protected]> 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 <[email protected]> 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> > [email protected] > www.uoguelph.ca/ccs > Room 037, Animal Science and Nutrition Building > Guelph, Ontario, N1G 2W1 > > > > ------------------------------ > *From:* cisco-voip <[email protected]> on behalf of Ben > Amick <[email protected]> > *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:[email protected] <[email protected]>] > *Sent:* Tuesday, January 03, 2017 10:15 PM > *To:* Ryan Huff <[email protected]> > *Cc:* Ben Amick <[email protected]>; Cisco VoIP Group < > [email protected]> > *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 <[email protected]> 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 <[email protected]> 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:[email protected] <[email protected]>] > *Sent:* Tuesday, January 03, 2017 9:18 PM > *To:* Ben Amick <[email protected]> > *Cc:* NateCCIE <[email protected]>; Cisco VoIP Group < > [email protected]> > *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 <[email protected]> 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:[email protected] <[email protected]>] > *Sent:* Tuesday, January 03, 2017 8:40 PM > *To:* NateCCIE <[email protected]> > *Cc:* Ben Amick <[email protected]>; Cisco VoIP Group < > [email protected]> > *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 <[email protected]> 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 <[email protected]> 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 > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > <http://cp.mcafee.com/d/avndzgOcxMQrhoupod7b9EV79CXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCSnQTXeffZvzhOZsQsFThWZOWr8V7AhPdTC7xTkhjmKCHtBfBgY-F6lK1FJ4SCrLOb0VVdOXMWVKVIDeqR4INpKNnwqj-f0T1dnoovaAVgtHBFkJkKpH9oT4JI2rrHEaGTc-JiLbCQnAkPhOr1vF6y0QJSBiRiVCIBziWq808Qwg-e2gq5x8Qgr10Qg0fkodIK6Y1tK-rNm> > > _______________________________________________ > cisco-voip mailing list > [email protected] > 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 > [email protected] > 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 > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
