[Home]

Summary:ASTERISK-26414: app_externalivr: ExternalIVR attended transfer - no audio
Reporter:Chris Maciejewski (chris-mac)Labels:
Date Opened:2016-09-28 09:05:14Date Closed:
Priority:MajorRegression?No
Status:Open/NewComponents:Applications/app_externalivr
Versions:11.23.1 13.11.2 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Debian 7 64bitAttachments:( 0) app_externalivr_attendedtransfer.patch
( 1) app_externalivr_attendedtransfer.patch
( 2) app_externalivr_attendedtransfer.patch
( 3) app_externalivr.c
( 4) app_externalivr.c
( 5) asterisk.log
( 6) call.log
( 7) call.pcap
Description:Hi,

When attended transfer to ExternalIVR is completed *after* ExternalIVR app starts no audio is sent to SIP client.

To reproduce the bug:

1. Download example config which can be found here:

https://github.com/level7systems/asterisk-cfg/tree/ExternalIVR-xfer

2. Register SIP client for ext 201 and ext 202.

3. Perform call scenario as below:

a) 201 calls 202
b) 202 performs attended transfer to ext 125 (ExternalIVR). 202 waits 10 seconds before completing the transfer
c) when transfer is completed there is no audio sent to 201

Note: if the same scenario is performed, however in step b) 202 waits only 3 seconds before completing the transfer audio is sent to 201 correctly. So it seems the issue doesn't occur if attended transfer is completed *before* ExternalIVR app starts and happens only if transfer completes when ExternalIVR app already started.

Note 2: the same problem affects ver. 11.22.0 as well.

Regards,
Chris
Comments:By: Asterisk Team (asteriskteam) 2016-09-28 09:05:16.313-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Joshua C. Colp (jcolp) 2016-10-04 12:21:27.252-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. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. The specific steps or actions you took that caused you to encounter the problem.
2. The behavior you expected and the location of documentation that led you to that expectation.
3. The behavior you actually encountered.

To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

[2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Chris Maciejewski (chris-mac) 2016-10-05 11:53:47.437-0500

Hi Joshua, thank you for replying to my issue report. Please find below additional information requested:

1. The specific steps or actions you took that caused you to encounter the problem.
Detailed steps to reproduce the problem (along with a complete set of configuration files) were provided in initial bug report - see above.

2. The behavior you expected and the location of documentation that led you to that expectation.
The behavior I would expect is audio (RTP streams) are being sent by Asterisk when attended transfer is performed to ExternalIVR application. There is no documentation stating that, however it seems to be a common sense statement which doesn't even need to be documented?

3. The behavior you actually encountered.
The actual behavior encountered is no audio (RTP stream) is being sent to SIP Client after attended transfer performed as per initial bug report above.

Attached in asterisk.log is debug log (with SIP trace enabled) of a call as per initial bug report.

Regards,
Chris
By: Joshua C. Colp (jcolp) 2016-10-10 08:42:50.476-0500

As this is an extended support module it is up to the community to look into it and investigate. This may take some time but any updates will be posted here.
By: balamurugan (balam) 2017-01-18 16:31:08.403-0600

I can analyse and see if we can fix this issue . can you provide the pcap captured with sip and rtp and share the pcap
Also if could provide the client ip and server ip i have to look for in the pcap that will better .
By: Chris Maciejewski (chris-mac) 2017-01-19 03:48:30.225-0600

Hi Balamurugan and thanks for getting in touch. I will provide PCAP traces and ip addresses of clients/server by end of day tomorrow (Friday 20th Jan. 2017). To clarify - we are looking for a patch that will fix this issue backported to Asterisk v. 11.5.1 which is the one we use on our platform.
Regards,
Chris
By: Chris Maciejewski (chris-mac) 2017-01-20 17:19:08.922-0600

Call trace in PCAP and Asterisk .log format
By: Chris Maciejewski (chris-mac) 2017-01-20 17:21:55.807-0600

Hi Bala, attached in call.pcap and call.log traces of example call, parties involved:

- 78.47.214.44 Asterisk
- 78.47.214.45 SIP client - ext 201
- 78.47.214.46 SIP client - ext 202

if you email me at chris [at] wima [dot] co [dot] uk I can provide you login details to working test environment I used to capture PCAP trace attached, so you can explore the issue further yourself.
By: balamurugan (balam) 2017-01-24 22:42:40.059-0600

Hi Chris ,

  i have tried to recreate this with my test setup having Asterisk 11.5.1 and seems to be working and unable to reproduce .

Is this happening for all the caller of to some specific caller ?

thanks,
bala
By: balamurugan (balam) 2017-01-24 23:08:44.782-0600

FYI ,

From the asterisk log you provided

I do see before Tranfer initiated there is a call from below anyidea who is this and why a call from 192.168.7.31

<--- SIP read from UDP:192.168.7.31:15060 --->
INVITE sip:125@172.16.16.91 SIP/2.0
Via: SIP/2.0/UDP 192.168.7.31:15060;rport;branch=z9hG4bKlrbmvtet
Max-Forwards: 70
To: <sip:125@172.16.16.91>
From: "202" <sip:202@172.16.16.91>;tag=kawpp
Call-ID: alspjympmhyetvt@debian-one
CSeq: 746 INVITE
Contact: <sip:202@192.168.7.31:15060>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Subject: Call transfer - 201 <sip:201@172.16.16.91>
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 307

Followed by  there is Transfer with REFER from Called user  to Replace with above call . Need to understand what exactly the Called user is doing
.

Also you shared log from asterisk 13.11.2
Can you share the working log with 11.5.1 as you mentioned when there is delay of only 3 sec ??

thanks,
bala

By: balamurugan (balam) 2017-01-30 21:07:39.383-0600

I have found the root cause for this issue . Looks like the channel ( Inbound Leg / exten 201) activate _generator is not set and hence the media is not flowing to the Inbound Channel / exten 201 . The external_ivr application is invoked with a channel associated for ext/125 and its activate_generator is set , but after attended transfer when the masquerade channel is finished it doesn't have the activate_generator set and this has to come from the application.

I have attached a patch and tested in my lab and it works fine .

Joshua Colp - Please verify and let me know if the patch looks ok .

thanks,
bala
By: Chris Maciejewski (chris-mac) 2017-02-01 00:49:38.753-0600

Hi Bala, I can confirm your patch has resolved the issue in my environment. The audio is no longer lost after performing call scenario as per my initial ticket description.
Best regards,
Chris