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]]
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]<mailto:[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]<mailto:[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]]
Sent: Tuesday, January 03, 2017 9:18 PM
To: Ben Amick <[email protected]<mailto:[email protected]>>
Cc: NateCCIE <[email protected]<mailto:[email protected]>>; Cisco VoIP Group
<[email protected]<mailto:[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]<mailto:[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]]
Sent: Tuesday, January 03, 2017 8:40 PM
To: NateCCIE <[email protected]<mailto:[email protected]>>
Cc: Ben Amick <[email protected]<mailto:[email protected]>>; Cisco VoIP
Group <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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
