[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) noreply at issues.asterisk.org
Fri Mar 21 17:43:18 CDT 2014


    [ 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:41 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.

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.



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


> 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
>
>
> 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)



More information about the asterisk-bugs mailing list