So I am running (admittedly legacy) Incredible PBX 13.0.192.19 in production. Same-old, same-old setup for at least 3 years now. I have one user who reports when she first picks up most internal/external callers there is poor audio just initially. Nothing terrible, but annoying to her. The MOS figures look good, I’ve replaced her phone, I’ve replaced her cabling, I’ve patched her into a different PoE switch port, I’ve verified no UDP traffic congestion around her call times, etc. All to no avail.
I know I should grab some SIP trace logging, and I intend to do that this week. Looking at some CDR reports from her recent past calls I see something odd. Each incoming call that she takes shows the Answer event along with a coinciding No Answer event. Don’t recall seeing this happen before. I’ve verified that her desk phone is the only one SIP-registered as x835, and I’ve verified that her desk phone only has a single instance of the x835 SIP account configured on it. And I’ve verified she doesn’t have any Follow Me or Forwarding defined.
The deskphones as this site are all Yealink T29G. If you mean try unplugging that and logging into her SIP account using a softphone for testing, I’d be up for that.
Also, this is more of a quirky annoyance than anything Earth shattering. When I have downtime between other things I tend to look at issues such as this. All Yealink extensions are built the same with templated config files pulled down, except for the name and extension/username. All of them are the same model and have identical firmware revisions. And since the Asterisk is pushing the calls those extensions are are defined in similar fashion. Maybe if there was an odd ring group defined or something, but there’s only one ring group to ring all phones at this site. And that ring group number wasn’t being hit.
Would love to see what’s going on. So when I get time I will trace things to review that alongside the Asterisk logs when we make some test calls.
Figured it out. Based on the traces and looking at the Asterisk log. Originally I created these site extensions via a CSV bulk import. There was a typo where the 835 User column value was also defined in x842 as well. Fixing that stopped the dupe calls from appearing. Looking in the iPBX web admin UI I didn’t see this typo, since it wasn’t listed anywhere I could see under that 842 extension. I only could see it when exporting the extension list back to a CSV file and inspecting it.
Snippet from the Asterisk log below where it was obvious there was something else being hit besides x835 when I internally dialed 835.
[2021-08-24 10:57:56] VERBOSE[1655][C-00003420] pbx.c: Executing [dstring@macro-dial-one:2] Set("SIP/515-00007245", "DEVICES=842&835") in new stack
Just a brief post-mortem. Apparently the user now reports that initial call connects don’t have the brief audio drops. Whereas previously that was the case. So fixing the extension setup faux pas seems to have resolved the issue.
