[asterisk-bugs] [JIRA] (ASTERISK-27857) Attended Transfer: Attended transfer has failed if using AMI terminal to send.
Cao Minh Hiep (JIRA)
noreply at issues.asterisk.org
Mon Sep 2 21:21:47 CDT 2019
[ https://issues.asterisk.org/jira/browse/ASTERISK-27857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247886#comment-247886 ]
Cao Minh Hiep edited comment on ASTERISK-27857 at 9/2/19 9:21 PM:
------------------------------------------------------------------
Hello, We've investigated this problem again recently.
About investigation, the result is we summarized it in attended_transfer.jpg as an attachment.
In the attended_transfer.jpg, We realize that between two digits we need at least 45 milliseconds for pending. We saw between "0" and "4" of an exten number(204),we have 45 milliseconds. this time, the process of exten matching and autoservice_run will be called so we need time for it.
As we know it, autoservice_run will run under a child process which created before.
it will read __ast_read() to get data from each frame to clean up or reorganize data.
With 2 cores CPU or more, the process of exten matching and autoservice_run will take time less than 45 ms, so it's fine to get next digit "4".
But with 1 core CPU, the process of exten matching and autoservice_run will take a time more than 45 ms, this time the digit "4" will be ready to read, so it will be clean up by autoservice_run.
To solve this problem, we try to take time to send each digit more than that as below:
main/manager.c:
action_atxfer():
for (digit = exten; *digit; ++digit) {
+ usleep(150000);
struct ast_frame f = { AST_FRAME_DTMF, .subclass.integer = *digit };
ast_queue_frame(chan, &f);
}
Could you please take a look at these and give us comment to solve the problem?.
was (Author: hiepcm):
Hello, We've investigated this problem again recently.
About investigation, the result is we summarized it in attended_transfer.jpg as an attachment.
In the attended_transfer.jpg, We realize that between two digits we need at least 45 milliseconds for pending. We saw between "0" and "4" of an exten number(204),
we have 45 milliseconds. this time, the process of exten matching and autoservice_run
will be called so we need time for it.
As we know it, autoservice_run will run under a child process which created before.
it will read __ast_read() to get data from each frame to clean up or reorganize data.
With 2 cores CPU or more, the process of exten matching and autoservice_run will take time less than 45 ms, so it's fine to get next digit "4".
With 1 core CPU, the process of exten matching and autoservice_run will take a time more than 45 ms, this time the digit "4" will be ready to read, so it will be clean up by autoservice_run.
To solve this problem, we try to take time to send each digit more than that as below:
main/manager.c:
action_atxfer():
for (digit = exten; *digit; ++digit) {
+ usleep(150000);
struct ast_frame f = { AST_FRAME_DTMF, .subclass.integer = *digit };
ast_queue_frame(chan, &f);
}
Could you please take a look at these and give us comment to solve the problem?.
> Attended Transfer: Attended transfer has failed if using AMI terminal to send.
> ------------------------------------------------------------------------------
>
> Key: ASTERISK-27857
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-27857
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/Bridging
> Affects Versions: 13.21.0
> Environment: Asterisk v13.21.0, AMI Terminal, Telephone.
> Reporter: Cao Minh Hiep
> Assignee: Unassigned
> Severity: Minor
> Attachments: attended transfer failed with AMI_13.21.0.txt, attended transfer failed with AMI.txt, attended transfer failed_with_full-log_13.21.0.txt, attended_transfer.jpg, CLI&AMI-LOGS_ver13.21.0.txt
>
>
> We have made an attended transfer with the following scenario:
> 1.Two phones(A and B) in one work-group.
> 2. Make a call to one of them(phone A) from an outside phone.
> 3. On AMI interface(used Tera Term terminal) to make an attended transfer from phone A to other(phone B).
> We could not make an attended transfer from A phone to B phone.
> It outputs a beep sound also.
> When we tried to investigate the causing of this problem.
> We found the difference logs between bug log and a normal log as below:
> =>*2 201 (*2: attended transfer, 201: Extention)
> We do that by the following AMI command:
> {noformat}
> Action: Atxfer
> ActionID: 1
> Channel: SIP/100002-0000008b
> Exten: 201
> {noformat}
> We found the logs of "Channel Local/20 at a_context_01-0000006e"
> instead of "Channel Local/201 at a_context_01-0000006e".
> We also found there are different process ID in progress of "*2 201"
> It's same process ID(30450) with "*2 20" and It turns to 3584 ID with 1.
> Note: In the normal attended transfer log we found the same process ID for "*2201".
> {noformat}
> DTMF[30450][C-0000002d]: channel.c:3972 __ast_read: DTMF end '*' received on SIP/100002-0000008b, duration 0 ms
> DTMF[30450][C-0000002d]: channel.c:3999 __ast_read: DTMF begin emulation of '*' with duration 100 queued on SIP/100002-0000008b
> DTMF[30450][C-0000002d]: channel.c:4092 __ast_read: DTMF end emulation of '*' queued on SIP/100002-0000008b
> DTMF[30450][C-0000002d]: channel.c:3972 __ast_read: DTMF end '2' received on SIP/100002-0000008b, duration 0 ms
> DTMF[30450][C-0000002d]: channel.c:3999 __ast_read: DTMF begin emulation of '2' with duration 100 queued on SIP/100002-0000008b
> DTMF[30450][C-0000002d]: channel.c:4092 __ast_read: DTMF end emulation of '2' queued on SIP/100002-0000008b
> -- <SIP/100002-0000008b> Playing 'pbx-transfer.gsm' (language 'ja')
> DTMF[30450][C-0000002d]: channel.c:3972 __ast_read: DTMF end '2' received on SIP/100002-0000008b, duration 0 ms
> DTMF[30450][C-0000002d]: channel.c:4031 __ast_read: DTMF end accepted without begin '2' on SIP/100002-0000008b
> DTMF[30450][C-0000002d]: channel.c:4042 __ast_read: DTMF end passthrough '2' on SIP/100002-0000008b
> DTMF[30450][C-0000002d]: channel.c:3972 __ast_read: DTMF end '0' received on SIP/100002-0000008b, duration 0 ms
> [May 16 11:57:37] DTMF[30450][C-0000002d]: channel.c:4031 __ast_read: DTMF end accepted without begin '0' on SIP/100002-0000008b
> DTMF[30450][C-0000002d]: channel.c:4042 __ast_read: DTMF end passthrough '0' on SIP/100002-0000008b
> DTMF[3584][C-0000002d]: channel.c:3972 __ast_read: DTMF end '1' received on SIP/100002-0000008b, duration 0 ms
> DTMF[3584][C-0000002d]: channel.c:4031 __ast_read: DTMF end accepted without begin '1' on SIP/100002-0000008b
> DTMF[3584][C-0000002d]: channel.c:4042 __ast_read: DTMF end passthrough '1' on SIP/100002-0000008b
> {noformat}
> Please have a look at attached test logs file.
> And could you please show us the causing of the problem and fixed patch for it?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list