Summary: | ASTERISK-22063: Ringback tone is not heard by caller when the call is transferred using blonde transfer in a Local bridge | ||
Reporter: | Christine Alejandro (clalejandro) | Labels: | |
Date Opened: | 2013-07-10 03:14:01 | Date Closed: | 2017-12-18 11:51:27.000-0600 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Channels/chan_sip/Transfers Core/Bridging |
Versions: | 11.3.0 | Frequency of Occurrence | Occasional |
Related Issues: | |||
Environment: | Ubuntu | Attachments: | ( 0) config.txt ( 1) ringbackDebugLogs |
Description: | Normal scenario: Caller A calls B. B will transfer A's call to C (semi-attended transfer). B will check first if C's phone is ringing before transferring the call. Caller A hears a ringback tone when B transferred the call to C.
Scenario encountered: Caller A calls B. B will transfer A's call to C (semi-attended transfer). B will check first if C's phone is ringing before transferring the call. Caller A doesn't hear a ringback tone when B transferred the call to C. It is a hit or miss case. Sometimes caller A could hear a ringback tone. | ||
Comments: | By: Matt Jordan (mjordan) 2013-07-10 06:41:32.198-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The channel technology of the participants 2. How the various channels are bridged 3. Channel driver configuration files, as well as a sample dialplan that reproduces the problem This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks! By: Christine Alejandro (clalejandro) 2013-07-10 23:56:22.393-0500 1. The channel technology of the participants SIP 2. How the various channels are bridged bridge_simple 3. Channel driver configuration files, as well as a sample dialplan that reproduces the problem see attached file By: Rusty Newton (rnewton) 2013-07-26 17:30:26.774-0500 https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines Please remove your debug and configuration from the comments and re-attach as separate .txt files to the issue. (More Actions > Attach Files). Please attach a packet capture (SIP and RTP) for both the calls you described (the normal and abnormal calls) Thanks! By: Christine Alejandro (clalejandro) 2013-07-28 18:30:13.322-0500 See configuration file By: Christine Alejandro (clalejandro) 2013-07-28 18:32:44.030-0500 See debug file By: Matt Jordan (mjordan) 2013-07-29 09:01:07.091-0500 That log file does not contain sufficient information to diagnose whether or not there is a problem. Please see [Collecting Debug Information|https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information] for instructions on how to collect a DEBUG log. In particular, please make sure that 'sip set debug on' is also enabled. As an FYI, you aren't using "bridge_simple" to bridge the channels together. Up until Asterisk 12 (which is currently trunk), the bridging modules aren't used for anything other than ConfBridge, and bridge_simple isn't used by ConfBridge. The channels are being bridged remotely however: {noformat} -- Remotely bridging SIP/7950-00092c75 and SIP/2066-00092c76 {noformat} Remotely bridging => direct media is enabled for these endpoints, which means media is flowing directly between them and not through Asterisk. As such, I would suspect that you have a NAT problem that is preventing media from being relayed during the attended transfer - which would be a configuration issue. Without seeing a DEBUG log however it is impossible to say for certain. By: Rusty Newton (rnewton) 2013-08-14 09:59:10.757-0500 @Christine are you able to provide the additional DEBUG required as mentioned by Matt? By: Christine Alejandro (clalejandro) 2013-08-16 02:14:10.655-0500 This is the debug when there's no ringback after transferring the call. By: Christine Alejandro (clalejandro) 2013-08-16 02:15:14.869-0500 This is the debug when there is ringback after transferring the call. By: Rusty Newton (rnewton) 2013-09-04 09:55:46.672-0500 Thanks for the logs, but you forgot to turn on SIP debug so we could see the full SIP messages. bq. In particular, please make sure that 'sip set debug on' is also enabled. Please gather the debug again with SIP debug messages included. To verify it is enabled, you'll see lines like the following in the log {noformat} INVITE sip:2000@192.168.1.55 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.245:5060;branch=z9hG4bK-e4c5b28d From: "6001" <sip:6001@192.168.1.55>;tag=915b34dcbc3a6e0co0 To: <sip:2000@192.168.1.55> Call-ID: 22c7991c-6bff56cc@192.168.1.245 CSeq: 101 INVITE {noformat} They won't have a log message prefix such as DEBUG,VERBOSE, WARNING, etc. Additionally, if you can use wireshark or tcpdump to capture both the SIP and RTP traffic for the same calls you capture debug for; that would be extremely helpful. By: Christine Alejandro (clalejandro) 2013-09-12 01:57:55.417-0500 Updated the logs with SIP debug messages. Files uploaded: - transfer-no-ringback.txt - transfer-with-ringback.txt By: Rusty Newton (rnewton) 2013-10-04 19:22:35.915-0500 Thanks for those. Unfortunately, somehow your files were mangled and the formatting for the SIP messages is messed up, some don't have newlines.. its confusing to read and hard to follow. This could have happen if you copy pasted from a terminal instead of grabbing and trimming a log file generated by logger.conf. Can you attach the same logs, but provide a whole file from /var/log/asterisk/ , typically the "full" file, generated by the Asterisk logger. See https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information for details. Along with that, to make sure we can follow it appropriately, attach a packet capture, that means using tcpdump or wireshark to capture the packets on the wire. Be sure you capture SIP, RTP and "any" size packets. Without these it just won't be clear what is going on. By: Christine Alejandro (clalejandro) 2013-10-16 02:08:20.889-0500 See configuration file By: Christine Alejandro (clalejandro) 2013-10-16 02:09:29.930-0500 See debug log file. There is no ringback tone in this scenario. By: Joshua C. Colp (jcolp) 2017-12-18 11:51:27.211-0600 I'm suspending this issue as this functionality has been massively rewritten and I believe it does not suffer from a problem like this. If this still occurs in a recent version of Asterisk feel free to comment and the issue will automatically reopen. |