FreePBX | Register | Issues | Wiki | Portal | Support

1 way audion after AtXfer Cancel

asterisk
freepbx
Tags: #<Tag:0x00007f749d3047b0> #<Tag:0x00007f749d304670>

(Jerry Riggin) #1

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?

FreePBX 13 Distro 10.13.66-22


(Itzik) #2

I would try a PBX reboot.

Which version of Asterisk are you using?
Can you post a call log of a failed call?


(Jerry Riggin) #3

Thanks for you response.

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?


(Tom Ray) #4

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.


(Jerry Riggin) #5

Thanks, Tom.

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.


(Tom Ray) #6

No sngrep. Use the proper debug command for the channel driver via the Asterisk console. We want to see how Asterisk is dealing with it.

As for this it would be a Transfer. A transfer initiates the hold as part of the process so CEL would still track this as a transfer.


(Jerry Riggin) #7

@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.