We are running Freepbx 14 with Asterisk 13. Our extensions are pjsip.
When we do an attended transfer, if the transfer is completed while the final destination is still ringing, there is no audio.
Example:
User 1 calls User 2; User 2 does an attended transfer to User 3. If User 2 completes the transfer while it is still ringing User 3 then User 1 and User 3 have no audio at all. If User 3 puts the call on hold and picks it back up, audio comes back both directions.
An attended transfer where User 2 waits for User 3 to answer, works fine; both User 1 and User 3 have audio both directions. A blind transfer also works fine.
How are you implementing the attended transfer? (SIP native, Dahdi analogue hook flash, or features.conf?)
For SIP, what devices are you using?
For SIP, please provide traces showing the SDP exchanges.
It’s Polycom phones using the feature code provided by freepbx, so I believe features.conf.
I am pretty new to PJSIP so I’m not really sure how to get you the traces for those SDP exchanges.
https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
I’d also get core show channel output and the equivalent for PJSIP, so it sounds like the channel may be in an incorrect state. (I wouldn’t expect any hold to be signalled to the device, when using features, so the SDP may not show anything interesting.)
Also make sure you have Asterisk 13.24.1 as earlier minor versions will have known bugs.
Ok.
I will work on getting those. I am also on Asterisk 13.22, so I will try to update that to the new version first.
Forgive my ignorance… I have the txt file of the Asterisk debug, but I am not sure how to attach it here. The forum will only let me attach pictures.
If it is small enough, paste it inline, using </> to mark it as preformatted. Otherwise you will have to use a file hosting service.
Apparently a character limit for inline text.
So here’s the text file:
Blockquote
Link has been removed in favor of newer logs uploaded
Those logs show a native SIP transfer, not a feature code one.
At one stage, one of the devices requests a hold (a=sendonly). There is just to much log, most of it not relevant, to see whether or not it needs to and actually does remove that hold.
There is also a CANCEL which may be earlier than I expected.
If you could simplify the traces to just INVITE, CANCEL and REFER and their responses, and just the request/response line and the From, To, Contact and ReferTo headers, plus any a=sendonly, a=sendrecv, and a=recvonly lines, it may make it easier to see what is happening.
My apologies.
Here is another log using the feature code. I believe I have it trimmed down to relevant info.
https://drive.google.com/open?id=145KcN9lpN-8YUomzZUs0iqxJ7HtuqkbB