Server Version: 15.0.17.68
Distribution: 12.7.8-2107-3.sng7
Asterisk Version: 16.20.0
The users at the location are all using Yealink phones, Mostly T42s’s with a couple of T46s’s mixed in.
This issue began after the users removed the Edgemarc Router from the network at the location.
So the issue begins, the caller calls into the system, and the call has no issues.
The Extension sends the call to the Parking Lot, and once it’s picked up, the caller can no longer receive the extension’s audio.
Interestingly, the call can then be put on hold and taken off, and the call will return to normal.
I’m asking for some help on how to try to get audio back into previously parked calls.
I am also having trouble with audio during park but in my case there is an echo on each users end just repeating back to them. Calls not involving park are having no issues. Happening across multiple of my locations and they all have either a mikrotik router or ubiquiti edge router. No issues prior to upgrading to Freepbx 15.
There is no mechanism by which parking could create an active echo. The only thing I can think of is that the parked party has an echo canceller, and the other party has a strong echo, In that case going to parking would remove the echo by the canceller might still try to subtract out the expected echo. What is the echo delay?
This could be an issue caused by Direct Media. If you are using PJSIP across the board and have Direct Media turned on at both Trunk and Extension level, it’s possible the passing of DM from Extension to PBX (to park) and then PBX back to Extension (to un-park) is resulting in your audio drop…then when you place the call on hold and off again (passing DM to PBX and back to Ext again), the matter corrects itself.
IF my theory is correct, this would indicate a possible bug in the Parking module that is failing to pass the DM back to the Extension properly after retrieving the parked call. The best way to test this is to confirm that Direct Media is set to No on both Extensions and Trunks and see if the problem persists.
[EDIT] NOTE: If you are not using PJSIP, this theory likely doesn’t apply to you because directmedia in PJSIP is typically on by default but its [obsoleted] counterpart canreinvite in Chan_SIP is typically disabled by default. In any case, directmedia/canreinvite will typically cause problems in most NAT environments…I.E. anything that involves a leg of the call traversing the public internet will likely break the direct media path. Since you’re probably using an internet based Trunk provider and a PBX behind some sort of router or firewall (or a cloud host), direct media is likely to break down. It will either cause audio loss in some or all cases or the path will just route RTP through the PBX anyway but add time to the call negotiation process as everyone tries to figure out the best way to pass the audio.
Ah, yes…I sometimes forget about that obsoleted option in the Chan_SIP stack, mostly because its disabled by default; versus PJSIP which usually defaults to directmedia=yes. I’ve updated my note accordingly.