[asterisk-bugs] [JIRA] (ASTERISK-23497) chan_sip attended transfer, when completed always uses a simple bridge and often the completed transfer does not have audio

[Rusty Newton (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216758#comment-216758 ] 

Rusty Newton edited comment on ASTERISK-23497 at 3/21/14 5:45 PM:
------------------------------------------------------------------

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.



was (Author: rnewton):
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.

Attaching full, messages and pcaps from two attended transfers.

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

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.


> chan_sip attended transfer, when completed always uses a simple bridge and often the completed transfer does not have audio
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23497
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23497
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_simple, Channels/chan_sip/Transfers
>    Affects Versions: SVN, 12.1.1
>            Reporter: Etienne Lessard
>            Assignee: Rusty Newton
>            Severity: Minor
>         Attachments: call1_full.txt, call1_messages.txt, call1_tcpdump, call2_full.txt, call2_messages.txt, call2_tcpdump, failed-native-bridge-attended-xfer.txt, sip.txt
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)