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 126.96.36.199
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 188.8.131.52.
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".