[Home]

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:01Date Closed:2017-12-18 11:51:27.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers Core/Bridging
Versions:11.3.0 Frequency of
Occurrence		Occasional
Related
Issues:
Environment:UbuntuAttachments:( 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.