Gradwell is good at taking your money, but terrible at helping you, even if it's THEIR fault. 

The exchange below took place from February 2016 until March 2016 concerning a lack of audio on some inbound SIP calls (Gradwell was the SIP provider).

It is the 3rd in a line of support issues since the trunk was turned up November 2015.


Me -> Gradwell

Various Gradwell staff -> Me

(contact me if you want names, email addresses to chase Zendesk requests)


2016-02-22 14:45 : Possible RTP issue...

"call recording implies that there was no remote audio"

  • RTP isn't firewalled
  • INVITE was received
  • This issue seems to occur around once every 2 days or 30 calls (this is indicatve, not exact), there is no precise pattern to time or calling party

2016-02-24 13:00 : I chase after no response for 2 days

2016-02-25 10:43 : I chase directly with JosieH, ThomV-E and LukeP

It's now been almost 3 working days without ANY response

2016-02-25 13:08 : DanielK responds:

"we have seen a rise in support requests" ... "assigned this request to one of our senior techs"

From 2016-02-25 13:59 -> Feb 26 12:26 - <insert first line problem solving> with NoelW around NAT and Firewalling, sources of the calls without RTP etc.  Again parts of emails are ignored and I need to chase.  Eventually I force a call with Gradwell and the result is that we agree to get 3 examples of this in a .PCAP before Gradwell will action further.

2016-02-29 13:12 : I send NoelW the first of the .PCAP files showing SIP and RTP where there is no RTP

2016-02-29 afternoon : NoelW asks for various confirmations to locate the call in the .PCAP and the source of the .PCAP

2016-02-29 16:12 : I confirm the .PCAP is from a Layer2 device just before the PBX and I send what I see as the RTP ports from the INVITE, with the "other side" address as

2016-03-01 11:07 : NoelW agrees the lack of RTP and escalates to the upstream provider. He asks me to confirm the traffic hit my "WAN". Effectively asking me *again* if it is blocked via firewall or NAT!!!

Assorted converstation around a telepest

2016-03-02 10:02 : NoelW asserts no problem found at Gradwell or upstream provider. "99% of the time one-way audio is a local issue"

2016-03-02 10:21 : I point out that the .PCAP is from our border.  The next step should be for the remote end to confirm the traffic WAS sent in order to escalte a routing issue if there is one.

2016-03-02 12:16 : Another failure reported with .PCAP supplied and a traceroute and ping to

2016-03-03 09:32 : NoelW reports no problems found and mentions that Gradwell does not handle the media/audio/RTP (this was deducable from the INVITEs) Because NO RTP was obvserved NoelW is back at pointing to our router/firewall This is the 3rd time we've been here!!! Upstream provider can not / will not (whatever) provide a packet capture as evidence that RTP is being sent (capacity issues are cited).  Changing to IAX is suggested as the audio will then route though Gradwell.

The advice to change to a different route and trunk protocol, is good, but I'm loath to allow them to make paradigmatic changes given the history of having to chase issues.

I'm annoyed and ask for a call since clearly Gradwell are just not "getting" this, more emails and chasing

2016-03-04 11:03 : I dial Gradwell on 012 2580 0888 and they agree to get someone to call me @ 13:00 UTC.

This never happens and I chase again.

Gradwell asks that they make some test calls and I sent up an Echo() to respond to their calls so that they can observe any lack of RTP from their end.

2016-03-09 09:36 : I can see there have been no test calls logged and chase again!

2016-03-09 10:30 : JasonS responds to placate and will promises someone will contact me again.

2016-03-09 11:16 : RussellH responds to ask that the Echo() also answer a mobile number.

I confirm this is done and there is some discussion around other handsets etc.

2016-03-11 18:04 : RussellH indicates he's run out of time, would like to run more tests, asks for the historic failure rate (already in the ticket) and promises to revert on "Monday".

BACK TO: Bad Service

Gradwell's support seems to have an instruction to either (a) indicate that the fault is not their end (even when there is CLEAR evidence to say it is) and they will make this assertion based on deduction in the face of hard evidence to the contrary OR (b) simply avoid replying (sometimes for over a month) in the hope you'll just forget about their short commings.

If you're a prospective Gradwell client, look elsewhere.  Their product is good, but unfortunately if you have *ANY* issues you can expect to have to BEG them to do their job. 

If you are already a Gradwell client, give up and port the numbers at the first sign of trouble or keep bothering them via social medial until they respond.

OR CHASE CHASE CHASE CHASE it not right that you have to fight, but with the right know how, tools and evidence you can push the issue to resolution.