I thought Forrest was a PIC or  Atmel  shop.

From: Ken Hohhof 
Sent: Sunday, June 07, 2015 1:24 PM
To: [email protected] 
Subject: Re: [AFMUG] ePMP VoIP QoS

I’ve got to agree with George on this one.  I realize Cambium apparently has 2 
separate design teams (3 if they still have the one in Ashburton), and likely 
the ePMP firmware team is somewhere else in the world.  But why do they always 
have to re-invent the wheel, then have customers tell them they already had a 
product that wasn’t broke so unless the new way is leaps and bounds better, 
please make it the same.  And even if the firmware is written elsewhere, isn’t 
that what Product Managers and Design Specs are for?

This is one of the problems I see a lot when software is designed by 20 year 
olds in India, Asia or Eastern Europe (and even Redmond and Silicon Valley) who 
have read a lot of RFCs and other standards but don’t have much real world 
experience.  Also I think that’s how you get a GUI that makes over 100 separate 
resource requests, you get young coders who have learned that way and are 
clueless about efficient coding methods for embedded firmware.  Maybe they need 
to hire some greybeards from the arcade game business, people who knew how to 
run PacMan on a 6507.  Or some of the people laid off by Disney and made to 
train their H1B visa replacements.  Or people like Forrest, doesn’t his stuff 
run on something like a Z80?

As far as telling a customer you aren’t going to use a non standards based 
solution to fix the crappy device they bought, good luck with that.  Customers 
don’t care about standards, except the one that says “the customer is always 
right”.

Seen at Jimmy John’s:  “The Customer Is Usually Right”


From: Faisal Imtiaz 
Sent: Sunday, June 07, 2015 1:57 PM
To: [email protected] 
Subject: Re: [AFMUG] ePMP VoIP QoS

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]> 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



      Midwest Internet Exchange
      http://www.midwest-ix.com




--------------------------------------------------------------------------

      From: "Josh Luthman" <[email protected]>
      To: [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
      Direct: 937-552-2343
      1100 Wayne St
      Suite 1337
      Troy, OH 45373

      On Sun, Jun 7, 2015 at 11:11 AM, Faisal Imtiaz <[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

        Help-desk: (305)663-5518 Option 2 or Email: [email protected]

        ----- Original Message -----
        > From: "George Skorup" <[email protected]>
        > To: [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]> 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.
        > >>>>
        >
        >






Reply via email to