[Home]

Summary:ASTERISK-17833: Hold music lost after attended transfer
Reporter:Byron Clark (byronclark)Labels:
Date Opened:2011-05-10 15:40:25Date Closed:2017-07-01 09:57:45
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
duplicatesASTERISK-22270 Attended transfer to a Queue stops music on hold on caller
Environment:Attachments:( 0) issue_0019267_siptrace_broken.txt
( 1) issue_0019267_siptrace_working.txt
Description:Testing with three endpoints I see this behavior:
A calls B
B begins an attended transfer
 - A hears hold music
B dials C
C answers
C places the call on hold
 - B hears hold music
B completes the attended transfer
 - A hears silence

As soon as C resumes the call, audio flows in both directions. C can even place the call on hold again and A will hear hold music.

If B completes the attended transfer before C places the call on hold, then audio works at all times.

Please let me know what debug information would be useful to track this down.
Comments:By: Byron Clark (byronclark) 2011-05-11 10:46:36

I tested this same call setup with 1.6.2.17.3 and saw this behavior:
A calls B
B begins an attended transfer
 - A hears hold music
B dials C
C answers
C places the call on hold
 - B hears hold music
B completes the attended transfer
 - A hears hold music

The only difference is that A continues to hear hold music after the transfer completes.

By: Leif Madsen (lmadsen) 2011-05-11 14:07:20

Could we get a SIP trace of this from the Asterisk console as well? It'd be ideal to see what happens on the working version and the non-working version to see if we're not signalling the MOH to come back on correctly. Thanks!

By: Byron Clark (byronclark) 2011-05-12 13:52:43

The two attached traces (mildly sanitized) show the call flow described.

issue_0019267_siptrace_working.txt is a capture from 1.6.2.17.3 where the hold music does appear correctly.

issue_0019267_siptrace_broken.txt is a capture from 1.8.4 where the hold music does not appear correctly.

In both files the following actors are present:
A:
- Caller Name: "Lost"
- SIP Username: 012fe548c973465d0c006300620001
- Dialable Extension: 5000

B:
- Caller Name: "Byron Clark"
- SIP Username: 0128d5efc9c276be27ba006300620001
- Dialable Extension: 1234

C:
- Caller Name: "Desk Test"
- SIP Username: 0127e3256489f81c6533006300620001
- Dialable Extension: 1001

By: Daniel Beutler (danielb) 2014-10-15 11:45:44.485-0500

I am also experiencing this issue. I would be very grateful for anyone who could provide a work-around in the mean time.

By: Rusty Newton (rnewton) 2017-07-01 09:57:45.963-0500

Closing this out as it hasn't seen any progress in more than two years and is filed against unsupported versions.

If this issue is reproducible against recent, supported versions, please file a new issue. Thanks.