Clueful Jive Communications Contact?

Fri Nov 21 02:51:20 UTC 2014

Sounds about on par with my experience so far.

We have a client who uses jive and we manage their network and when this
client opens tickets with jive, they get copy+pasted the exact same email
every time telling the client to make sure sip alg is disabled, check
firewall, etc. We have repeatedly told them that theres no filtering of
outbound traffic and we've stated many times that all their recommendations
are already in affect.

We also ran into a similar adtran situation to yours, when the customer
contacted Jive to open the first support ticket, Jive automatically started
CC-ing the IT company who is a Jive reseller and doesn't have any staff
familiar with cisco ios and insisted that they put in a adtran. The
reseller came out and dismantled the network and

I advised Jive we are applying QoS to standard VOIP ports in our base
config but I told them if there is anything outside the normal sip and rtp
ports to give it me to me to be added and they still haven't.

At one point our client got real upset and Jive started "monitoring" the
WAN link which is dedicated for their voice traffic only and then started
telling the customer to call the ISP. The irony here is that I'm almost
 postivie that their perceived "loss" is just that when the link is fully
utilized we obviously don't prioritize ICMP and also I have a hunch that
they are using more ports than the typical ones in which case that traffic
will suffer also because they will not tell me what traffic to prioritize.
This support rep now refuses to proceed until the customer calls the ISP so
we switched their voice traffic to another WAN link completely just to
demonstrate at which point the support rep said they saw loss still at
which point I explained that if we had the info necessary to QoS everything
properly their traffic should be unaffected even when there is congestion.

Which is more likely at fault:
   A) Having the exact same set of problems with 2 different diverse ISP's
   B) Their "monitoring" traffic being drop as expected, when link is
congested and router is applying QoS exactly as it should and dropping the
non prioritized traffic. Of course when some traffic is prioritized that
automatically means non prioritized traffic is penalized. This is exactly
how we want it.

Needless to say, the client is frustrated because support is stuck at "call
isp" and insist they see "voice loss".

Hopefully your experience is not quite as bad but I have to say that of all
the different voice service providers we've worked with we've never spent
as much time

The contact who reached out to me was Michael Martinez (
mmartinez at getjive.com), he is a member of this list and appears to be a
network engineer managing their core network.

Hope this helps or if you are still evaluating Jive maybe this experience
will help give you an idea of what to expect

chris

On Thu, Nov 20, 2014 at 9:07 PM, Sean Sinay <smsinay at gmail.com> wrote:

> Would also appreciate the clueful contact as I have the same experience
> with going through the normal support escalation. Primarily interested in
> the networking folk who are intimately familiar with the Adtran CPE they
> ship to customers. The 'Engineers' shipped two devices with no gateways
> configured..
>
> On Sat, Nov 8, 2014 at 11:24 AM, chris <tknchris at gmail.com> wrote:
>
>> Thanks to all replies off-list. Contact has been made with all the right
>> people in the right places. It really is amazing to see how active the
>> nanog community is and all the great players involved.
>>
>> Chris
>>
>> On Fri, Nov 7, 2014 at 6:24 PM, chris <tknchris at gmail.com> wrote:
>>
>> > Sorry for the noise but If anyone from Jive Communications is on the
>> list
>> > or if anyone has any clueful technical contacts please contact me
>> offlist.
>> >
>> > I have a very frustrated mutual customer we provide network services to
>> > who utilizes Jive for their voice and we can see that there is
>> intermittent
>> > reachability problems and all attempts  to go through normal support
>> with
>> > the information we have provided are going nowhere.
>> >
>> > Thanks
>> > chris
>> >
>>
>
>