After dealing with all of the others, it's Polycom or nothing for me.
The others just aren't worth my time.
-----
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: *"Faisal Imtiaz" <[email protected]>
*To: *[email protected]
*Sent: *Sunday, June 7, 2015 4:17:52 PM
*Subject: *Re: [AFMUG] ePMP VoIP QoS
So I gather you are not the VOIP service provider ? but you sold them
the phones ?
Additional out of the box suggestion...
If you are / were the VOIP service provider, (i.e you have a revenue
stream coming from it), and or you are responsible for maintaining
them..... You could potentially consider, offering an upgrade / trade
in or even replace so that you don't have to deal with the heartburn
related to GrandStream firmware to a better phone....
e.g some of the better quality phones polycom's, snom, linksys, cisco
etc go for a song on the secondary markets..
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 4:26:22 PM
*Subject: *Re: [AFMUG] ePMP VoIP QoS
Nope, nothing personal. Discussion is great, new ideas can come
from it.
As far as the Grandstream phones, we can't tell the customer,
sorry, these won't work, you have to buy 10-20 new ones, Polycom,
Snom, whatever it may be. If I was the customer, I'd be saying the
same thing.. that's not my problem because you sold them to me.
The reseller says, nope, you have to work with Grandstream
support, and they are completely right. So we're stuck in the
middle looking like assholes to the customer.
I'll give this to Cambium 2.0, they are definitely more responsive
and paying attention.
On 6/7/2015 1:57 PM, Faisal Imtiaz wrote:
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.
> >>>>
>
>
