[asterisk-bugs] [JIRA] (ASTERISK-27980) Caller ID cannot be changed on Attended Transfer before dialing out
Filip Frank (JIRA)
noreply at issues.asterisk.org
Tue Apr 21 14:00:26 CDT 2020
[ https://issues.asterisk.org/jira/browse/ASTERISK-27980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250490#comment-250490 ]
Filip Frank edited comment on ASTERISK-27980 at 4/21/20 1:59 PM:
-----------------------------------------------------------------
Same problem for me, "I" option helps little bit(sometime CID is replaced, sometimes no). Without it, its always replaced by COLP update. It depends lot on timing, if COLP update is processed before Set CALLERID(number) or not. Its because dialplan running simultaneously with COLP update.
Example(part of dialplan in transfer context):
-- Executing [XXX238335 at transfer:20] Set("Local/XXX238335 at transfer-00000069;2", "CALLERID(num)=00420XXX737556") in new stack
-- Executing [XXX238335 at transfer:21] DumpChan("Local/XXX238335 at transfer-00000069;2", "") in new stack
Dumping Info For Channel: Local/XXX238335 at transfer-00000069;2:
Name= Local/XXX238335 at transfer-00000069;2
...
CallerIDNum= 28000420XXX737556
And then INVITE have From: 28000420XXX737556 instead of required 00420XXX737556. (XXX in number - just to anonymize)
Workaround:
Adding Wait(1) before Set(CALLERID(number)) helps as wokaround. COLP update is then always processed before dialplan CID set.
There is gerrit patch, but it was abandoned. My knowlage of asterisk code isnt good for fix it. :( So please reopen.
I have problem in 13.x, 16.x
was (Author: frenk77):
Same problem for me, "I" option helps little bit(sometime CID is replaced, sometimes no). Without it, its always replaced by COLP update. It depends lot on timing, if COLP update is processed before Set CALLERID(number) or not. Its because dialplan running simultaneously with COLP update.
Example(part of dialplan in transfer context):
-- Executing [XXX238335 at transfer:20] Set("Local/XXX238335 at transfer-00000069;2", "CALLERID(num)=00420XXX737556") in new stack
-- Executing [XXX238335 at transfer:21] DumpChan("Local/XXX238335 at transfer-00000069;2", "") in new stack
Dumping Info For Channel: Local/XXX238335 at transfer-00000069;2:
Name= Local/XXX238335 at transfer-00000069;2
...
CallerIDNum= 28000420XXX737556
And then INVITE have From: 28000420XXX737556 instead of required 00420XXX737556.
Workaround:
Adding Wait(1) before Set(CALLERID(number)) helps as wokaround. COLP update is then always processed before dialplan CID set.
There is gerrit patch, but it was abandoned. My knowlage of asterisk code isnt good for fix it. :( So please reopen.
I have problem in 13.x, 16.x
> Caller ID cannot be changed on Attended Transfer before dialing out
> -------------------------------------------------------------------
>
> Key: ASTERISK-27980
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-27980
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Applications/app_dial, Applications/app_followme, Applications/app_queue
> Affects Versions: 13.22.0, 15.5.0
> Reporter: Alexei Gradinari
> Assignee: Unassigned
> Labels: pjsip
> Target Release: 13.24.0, 16.1.0, 17.0.0
>
> Attachments: ASTERISK-27980.tar.xz
>
>
> Alice calls Bob.
> Alice does an attended transfer to Charlie.
> The Caller ID is modified to some ID using either CALLERID function or Dial options 'o([x])' on outgoing context before Dial Charlie's endpoint.
> But the From: header contains "Alice" on INVITE to Charlie, and not what is set before.
> The app Dial initially correctly sets CONNECTED LINE on outgoing channels as CALLERID of the originating channel.
> But then the app Dial reads pending CONNECTED LINE update on the originating channel and sets CONNECTED LINE on outgoing channels with this data.
> The processed pending CONNECTED LINE update already sets CALLERID on originating channel, so all pending CONNECTED LINE updates have to be ignored and removed before initialize outgoing calls.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list