Big mixed environment? All of ours are on 1.0.4.23. Our switches, routers, and ubiquiti radios seem to handle it fine, and we use procera to even correctly tag inbound openvpn because we know the IP blocks those devices will be assigned. We had problems with a Cisco phone (of all things) until we got that one squared away.
VoIP seems like its a "bastard service" to a lot of vendors for some reason. FYI I don't know if you've looked, but GSWAVE android app seems to tag correctly once configured. I do wish those clients could be properly zero configured though. On Jun 6, 2015 11:06 PM, George Skorup <[email protected]> wrote: > > The 1.0.4.17 firmware for the GXP phones (we have mostly 2160s and some > 30s and 40s) cannot be downgraded since it contains a security fix. I > have a couple phones that are now fk'n stuck on that because of it. > We're running an internal engineering build on some phones with fixes > for their screwed up SIP message handling and corrupt outgoing messages. > Some phones we have not upgraded from 1.0.3.9 because it mostly works. > None of those firmwares allows separate SIP and RTP QOS. We're doing > testing and validation of 1.0.4.23 with our switch vendor currently, > which does do the split QoS. About half of the bug fixes listed in the > .21/.23 release notes were ours. Just have to wait and see what other > shit is broken now. > > But besides all that, I have other phones and ATAs (both Grandstream and > not) that refuse to send SIP with anything other than DSCP12, even when > it's configurable. I don't really care if SIP is sent with AF and RTP as > EF, that's perfectly acceptable. RTP should be higher priority than SIP > anyway. Standard DiffServ config supports this just fine. So as far as > the network is concerned, I have to support AF and EF, and I'm fine with > that. All I was saying is that Cambium should do this out of the box on > ePMP if you turn on VoIP priority. This is what happens on Canopy when > you turn on HP on an SM, both DSCP12 and 46 end up in the HP channel. > > On 6/7/2015 1:11 AM, Josh Reynolds wrote: > > I don't know what grandstream devices you are looking at, but 21xx series > > and the other Linux and android based phones don't have that issue. Neither > > does the asterisk based UCMs, such as the 6104. Screenshots attached. > > > > On Jun 6, 2015 8:17 PM, George Skorup <[email protected]> wrote: > >> I disagree. This is exactly what Canopy does. DSCP12/AF is sent over the > >> HP channel. Look at the default DiffServ table and see for yourself. > >> Many managed switches are set up exactly the same way, except they have > >> more queues, and Canopy only has MIR and HP. Well, there's LP CIR, but > >> lets not get into that. ePMP just has "priority" which I assume means > >> priority over everything else. > >> > >> I need a way to correct stupid manufacturer's mistakes (Grandstream > >> being the worst offender). Lots of their devices ALWAYS send SIP packets > >> as DSCP12 and this CANNOT be changed. Or the other one I mentioned, the > >> GXP phones have one DSCP setting and this changes both SIP and RTP. I'm > >> disgusted with their stupidity, but unfortunately it has to be supported > >> because those devices aren't going away. > >> > >> It's totally doable and Cambium could add it by default, saving me time > >> configuring every radio with it. Or just make DiffServ on ePMP > >> work/configure like Canopy. > >> > >> I don't care what's wrong or right. I care about shit working right now > >> and customers not being pissy. > >> > >> So the burden falls on the network as usual. It's always our fault. > >> Sometimes I just don't know how I haven't murdered people. If I drank, > >> it would probably happen. And I'm finding myself agreeing with that one > >> guy Steve every other day now. Stupidity has no limit. > >> > >> On 6/6/2015 10:31 PM, Faisal Imtiaz wrote: > >>>> Yo Cambium, you need to add DSCP 12 (Assured Forwarding) in addition to > >>>> DSCP 46 (Expedited Forwarding) to the default VoIP priority > >>>> configuration. > >>> That would be a mistake and the wrong thing to do. > >>> > >>>> We're finding more devices sending SIP packets as AF and > >>>> RTP as EF. > >>> When a device is mis-configured, why should the burden of dealing with > >>> that mis-configurtion as a default fall on another device > >>> > >>> There is plenty of flexibility to override the wrong setup of a device, > >>> if that is they way you want to correct it in your radios... > >>> (Which by all standards would be the wrong way to fix it...but more power > >>> to you). > >>> > >>> Two wrongs don't make a right.. > >>> > >>> > >>> Regards. > >>> > >>> > >>> Faisal Imtiaz > >>> Snappy Internet & Telecom > >>> 7266 SW 48 Street > >>> Miami, FL 33155 > >>> Tel: 305 663 5518 x 232 > >>> > >>> Help-desk: (305)663-5518 Option 2 or Email: [email protected] > >>> > >>> ----- Original Message ----- > >>>> From: "George Skorup" <[email protected]> > >>>> To: [email protected] > >>>> Sent: Saturday, June 6, 2015 10:27:05 PM > >>>> Subject: [AFMUG] ePMP VoIP QoS > >>>> > >>>> Yo Cambium, you need to add DSCP 12 (Assured Forwarding) in addition to > >>>> DSCP 46 (Expedited Forwarding) to the default VoIP priority > >>>> configuration. We're finding more devices sending SIP packets as AF and > >>>> RTP as EF. AF isn't prioritized and out-of-band signaling (prompts, etc) > >>>> are sent as SIP messages so sometimes these are getting dropped, not to > >>>> mention registrations, invites, etc. And more devices are stupid (mostly > >>>> Grandstream), they only let you set ONE priority value for the entire > >>>> device. These are coming default as DSCP12/AF. I've tried to get > >>>> everyone to change this to 46, but they don't remember. > >>>> > >>>> Or just apply the whole Canopy DiffServ table. We've never had to change > >>>> any of those code points. Turn HP on, it just works. > >>>> >
