We have an issue with 1 way audio where, after agent cancels attended transfer and re-connects with customer, agent can hear customer but customer can’t hear agent. These are feature code transfers and cancles DTMF codes send by AMI down agent channel. Using feature codes from here.
The original call has 2-way audio, agent and transfer target have 2 way audion, but if agent cancels and get’s customer back we get 1-way audio. I can’t wrap my brain around how this happens. Doesn’t seem like a NAT issue. Maybe something configured wrong somewhere? Anyone have a clue?
Asterisk 13.19.1 SIP - PJSIP disabled. Reboot was the 1st thing I tried (like a good little IT guy).
I was hoping (but not really expecting) someone would say, “Oh, we had the same thing and changed foo=bar to foo=blah in something.conf and the problem went away.” We can all dream, right?
I have captured a calls and studied results, but there are a lot of logs and results. As far as posting a log, a have a gazillion. I think the problem might best be found in CEL records for linkedid of the inbound uniqueid of the transferred call, but I haven’t found the issue. It is a large log, but I would be happy to post it if you will look it over. Do you think that is the best log to find source of the issue?
Why? There is nothing, so far, that has been presented that would require the PBX to be rebooted. So why issue a reboot when it’s not really needed?
Is the PBX remote to all the agents and the phones? When a call is Transferred (be it the standard transfer or the in-call feature codes) the first thing that happens is the other party is immediately put on hold. That’s very important to understand because when a HOLD is initialized this sends a new INVITE to the system with updated SDP/media details. It tells the call that either 1) Send incoming audio from the other party to a blackhole (0.0.0.0) or 2) It changes the media stream to be “Send Only” meaning it won’t receive incoming media from the other side. Now when you take a call off HOLD, the process is repeated but this time the INVITE changes the SDP/media back to be a two way communication.
So it is sounding like something is happening when the agent is taking the customer off hold and the SDP/media isn’t being handled right. What we need here is an actual SIP trace of a call being put on hold and taken off hold that this happens to.
Just do the following:
asterisk -r
sip set debug on (if using CHAN_SIP)
pjsip set logger on (if using Chan_PJSIP)
Make call, put on hold, take off hold, have 1 way audio issues, hang up call. Copy and paste the ENTIRE debug from the initial INVITE to the last message and post it so it can be looked at.
I will have to wait for tonight when I have the system to myself to get a SIP log without sifting through a ton of unrelated data. “sngrep” won’t get me the whole call without some magic I am not aware of.
I do have a complete AMI event log of a call, but oddly I don’t have any “[Event] => Hold” though I do see ‘Hold’ with “CLI> manager show events” and manager.conf is read/write=all, and I have no ‘HOLD’ eventtype in cel.
@BlazeStudios Thanks, Tom. After rearranging all my AMI transfer code, this issue seems to have resolved itself. I sincerely appreciate your info and willingness to help.