Summary:ASTERISK-23497: chan_sip SIP protocol attended transfer, with directmedia=yes results in a simple bridge, typically with no audio
Reporter:Etienne Lessard (hexanol)Labels:
Date Opened:2014-03-18 08:03:15Date Closed:2014-05-11 10:40:42
Status:Closed/CompleteComponents:Bridges/bridge_simple Channels/chan_sip/Transfers
Versions:SVN 12.1.1 Frequency of
Environment:Attachments:( 0) call1_full.txt
( 1) call1_messages.txt
( 2) call1_tcpdump
( 3) call2_full.txt
( 4) call2_messages.txt
( 5) call2_tcpdump
( 6) failed-native-bridge-attended-xfer.txt
( 7) sip.txt
Description:Given I have 3 SIP phones that are registered with asterisk via chan_sip
Given directmedia is activated in sip.conf
When A calls B and B answers
Then A and B are bridged using a native bridge
When B puts A on hold, then calls C and C answers
Then B and C are bridged using a native bridge
When B finalize the transfer
Then A and C are bridged using a "simple bridge", i.e. they are not bridged using a native bridge, which is what is expected

More generally, direct media is always working fine in a "direct call" scenario, i.e. if A calls B or B calls C or A calls C, direct media is working fine. But after an attended transfer, direct media doesn't seem to work.
Comments:By: Etienne Lessard (hexanol) 2014-03-18 08:04:52.887-0500

I've attached a CLI output of a failing scenario.

By: Rusty Newton (rnewton) 2014-03-20 18:13:38.714-0500

Yeah there is a problem here. I'm investigating it and will post some traces.

By: Rusty Newton (rnewton) 2014-03-21 17:39:25.806-0500

I'll say this was confusing to track down, as for me.. the issue was intermittent. At first I thought I had an issue with a specific phone, then after not being able to reproduce it for a while, I thought it was an issues with the way the attended transfer was performed, after trying it in a few different ways I found that any way I performed a SIP protocol attended transfer it would fail, it just happened to be intermittent. Usually I can reproduce it within about five calls.

h2. Attachments

Attaching full, messages and pcaps from two attended transfers, plus sip.conf

h2. Calls

*Call1* is an example of an attended transfer that completes, but *doesn't have audio* in either direction.

*Call2* is an example of an attended transfer that complete, and *has working audio*.

Call 2 was performed right after Call 1.

h2. How the calls were made

The calls were performed as follows:

1. A calls B, B answers
2. B presses transfer button, (which places A on hold and prompts for dial)
3. B dials C by pressing dial softkey, C answers
4. B presses transfer button again without making any selection, it completes, A and C are connected

In both scenarios, the final bridge for A and C is a simple bridge and not native.  Sometimes, we see no audio in either direction. Typically happens within about five calls, but sometimes takes a few more.

By: Rusty Newton (rnewton) 2014-03-21 17:51:57.734-0500

As might be obvious from my traces, I was taking captures from the Asterisk server coming off a switch, so I wouldn't have been able to record any media that actually does flow directly between the endpoints. If a developer can't reproduce then I can get something set up if needed.

By: Joshua C. Colp (jcolp) 2014-05-10 20:08:04.649-0500

Issues were uncovered by Bamboo.

By: Eli Hunter (elihunter) 2014-08-17 22:19:08.579-0500

I think I'm still seeing this same issue with 12.4.0.  I have two phones with directmedia=yes and in approximately 1/5 of the transfers watching rtp debug messages the RTP source address is wrong resulting in no audio.   If I transfer the call back and forth between extensions repeatedly it will randomly set the wrong RTP source address.  If any further logs are needed I can get them.