Please don't take this personal, just take it as constructive
criticism....
>>Trying to get the guys to remember to add a bunch of rules in a
radio probably won't happen.
I think you may have a QC / installation process issue (aka
provisioning), which you are trying to compensate for.
>>Maybe I'm a nazi when it comes to the network, but.. don't touch the
network and I won't have to kill you.
Instead of taking this stance, I suggest you look into how to make
changes without someone screwing up something else by mistake.
(hint.. changing stuff via scripts is one way to do this).
>>>It took them a YEAR to fix the stuff we showed them was broken in
their software! But no, we're the asshole to the customer which forces
us to hack shit to make it work, and then it's still not up to the
customer's expectations.
Why are you/your customers insisting on using GrandStream phone ?
Just another suggestion:-
We would much rather run a 'standard' based network, and not customize
these types of settings on the Radios.. If we ran into this type of a
situation, we would offer a managed router service (free or nominal
charge), and or use a mikrotik router as a dmarc on the customer prem,
and do all the funny business customization on that.
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]
------------------------------------------------------------------------
*From: *"George Skorup" <[email protected]>
*To: *[email protected]
*Sent: *Sunday, June 7, 2015 2:24:36 PM
*Subject: *Re: [AFMUG] ePMP VoIP QoS
Right. As I said, I've never had to change any of the DiffServ
code points on any Canopy radio. Trying to get the guys to
remember to add a bunch of rules in a radio probably won't happen.
It's easier for me to tell them to just turn on HP. Maybe I'm a
nazi when it comes to the network, but.. don't touch the network
and I won't have to kill you.
Anyway.. the new Grandstream firmware, how awesome is this.. the
SIP QoS default is DSCP 26, which is LP on Canopy. Knowing that, I
DO NOT want the guys touching the DiffServ code points in the
radios. It's easier to configure the phones with SIP DSCP 12 and
RTP DSCP 46. To accommodate the stupid/broken devices, I already
have other rules on the network that prioritizes SIP as 12 and RTP
as 46. I like standards. OK, my standards.
On 6/7/2015 12:59 PM, Josh Luthman wrote:
Works on Canopy, though.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Sun, Jun 7, 2015 at 1:56 PM, Mike Hammett <[email protected]
<mailto:[email protected]>> wrote:
Having only half listened to the thread, it sounds like
broken Grandstream VoIP is broke on ePMP.
-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange
http://www.midwest-ix.com
<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
------------------------------------------------------------------------
*From: *"Josh Luthman" <[email protected]
<mailto:[email protected]>>
*To: *[email protected] <mailto:[email protected]>
*Sent: *Sunday, June 7, 2015 12:54:29 PM
*Subject: *Re: [AFMUG] ePMP VoIP QoS
For this use case (QoS on VoIP):
Cambium Canopy works
Cambium ePMP does not work
Seems that simple to me.
Josh Luthman
Office: 937-552-2340 <tel:937-552-2340>
Direct: 937-552-2343 <tel:937-552-2343>
1100 Wayne St
Suite 1337
Troy, OH 45373
On Sun, Jun 7, 2015 at 11:11 AM, Faisal Imtiaz
<[email protected]
<mailto:[email protected]>> wrote:
BTW, the latest firmware for GXP 2160 is 1.0.4.23 (did
a google search), and the admin manual shows two
settings for L3 QOS (one for SIP and one for RTP)
EPMP QOS allows you to modify the default settings to
over-ride to your taste.
If I understand your 'complaint' you are dealing with
f**ed up GrandStream Phones, and you want Cambium to
Change the Default handling of VOIP QoS to match your
needs ?
Now that does not make any logical sense...
The default setup for QoS Voip on EPMP is perfectly
fine for all of the other devices which follow the
industry standard of VOIP/Video packet marking.
Unless there is something that I am totally missing, I
think you are taking out your frustrations with
GrandStream on Cambium !
:)
Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232 <tel:305%20663%205518%20x%20232>
Help-desk: (305)663-5518 <tel:%28305%29663-5518>
Option 2 or Email: [email protected]
----- Original Message -----
> From: "George Skorup" <[email protected]
<mailto:[email protected]>>
> To: [email protected] <mailto:[email protected]>
> Sent: Sunday, June 7, 2015 3:06:27 AM
> Subject: Re: [AFMUG] ePMP VoIP QoS
>
> 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] <mailto:[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
<tel:305%20663%205518%20x%20232>
> >>>
> >>> Help-desk: (305)663-5518 <tel:%28305%29663-5518>
Option 2 or Email: [email protected]
> >>>
> >>> ----- Original Message -----
> >>>> From: "George Skorup" <[email protected]
<mailto:[email protected]>>
> >>>> To: [email protected] <mailto:[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.
> >>>>
>
>
