[Home]

Summary:ASTERISK-27980: Caller ID cannot be changed on Attended Transfer before dialing out
Reporter:Alexei Gradinari (alexei gradinari)Labels:pjsip
Date Opened:2018-07-20 15:08:03Date Closed:2020-04-22 09:08:17
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_dial Applications/app_followme Applications/app_queue
Versions:13.22.0 15.5.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Attachments:( 0) ASTERISK-27980.tar.xz
Description: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.
Comments:By: Asterisk Team (asteriskteam) 2018-07-20 15:08:04.120-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: Richard Mudgett (rmudgett) 2018-07-20 15:34:47.724-0500

The analysis just seems wrong about the connected line updates.  Please provide debug logs with the protocol specific messages and the dialplan execution to demonstrate the situation.  Please include the following:

* Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver.
* Configuration information for the relevant channel driver, e.g. pjsip.conf.
* A wireshark compatible packet capture, captured at the same time as the Asterisk log output.

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



By: Alexei Gradinari (alexei gradinari) 2018-07-24 14:23:34.333-0500

conf/* - asterisk test configuration:
3 PJSIP endpoints: alice, bob and charlie.
3 extension: 501->alice, 502->bob and 503->charlie,
CALLERID set to 'Reception Desk <555>' before calling charlie.

log/full - the log of next scenario
Alice calls Bob (502).
Alice does an attended transfer (*2 503) to Charlie.


By: Richard Mudgett (rmudgett) 2018-07-24 17:05:05.411-0500

I think extending the Dial, Queue, and FollowMe 'I' option to block connected line updates in both directions would be a better approach.  The 'I' option currently blocks connected line updates from the called parties to the caller.  It is a simple matter to also have it block updates in the other direction for each of the applications.

You are trying to lie to Charlie about who is calling at least until the transfer is complete.  You could use a connected line interception routine \[1] set on Charlie's channel to keep the party id as you want it without making any code changes.

\[1] https://wiki.asterisk.org/wiki/display/AST/Party+ID+Interception+Macros+and+Routines

By: Alexei Gradinari (alexei gradinari) 2018-07-24 17:56:28.861-0500

With the same configuration, if Alice does blind transfer, Charlie will see modified ID.
Do you think that it's normal that depending on the type of transfer the asterisk behavior is different in this case?
I think it's a bug.
I try to fix this bug.
Using connected interception routine is a workaround.

By: Benjamin Keith Ford (bford) 2018-09-04 14:19:19.206-0500

Suspending this issue as there were patches up on Gerrit, but they could not be accepted and were therefore abandoned.

By: Friendly Automation (friendly-automation) 2018-10-25 07:46:54.899-0500

Change 10286 merged by Joshua Colp:
app_dial/queue/followme: 'I' options to block initial updates in both directions

[https://gerrit.asterisk.org/10286|https://gerrit.asterisk.org/10286]

By: Friendly Automation (friendly-automation) 2018-10-25 07:47:11.037-0500

Change 10533 merged by Joshua Colp:
app_dial/queue/followme: 'I' options to block initial updates in both directions

[https://gerrit.asterisk.org/10533|https://gerrit.asterisk.org/10533]

By: Friendly Automation (friendly-automation) 2018-10-25 07:47:33.265-0500

Change 10534 merged by Joshua Colp:
app_dial/queue/followme: 'I' options to block initial updates in both directions

[https://gerrit.asterisk.org/10534|https://gerrit.asterisk.org/10534]

By: Filip Frank (frenk77) 2020-04-21 13:51:21.454-0500

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@transfer:20] Set("Local/XXX238335@transfer-00000069;2", "CALLERID(num)=00420XXX737556") in new stack
-- Executing [XXX238335@transfer:21] DumpChan("Local/XXX238335@transfer-00000069;2", "") in new stack
Dumping Info For Channel: Local/XXX238335@transfer-00000069;2:
Name= Local/XXX238335@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

By: Richard Mudgett (rmudgett) 2020-04-21 14:34:35.605-0500

[~frenk77] You might want to investigate connected line interception handlers.
See the following links:
https://blogs.asterisk.org/2017/03/29/dialplan-handler-routines-allow-customization/
https://wiki.asterisk.org/wiki/display/AST/Party+ID+Interception+Macros+and+Routines
https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information

By: Filip Frank (frenk77) 2020-04-22 04:38:05.457-0500

I read it but i am still confused how to completly stop any change. I tried add "I" option to every Dial i my dialplan - no help. I just want keep what i set in dialplan as CALLERID(number) in tranfer context. How to achieve this?

By: Alexei Gradinari (alexei gradinari) 2020-04-22 09:07:47.139-0500

[~frenk77],
If you use PJSIP you can try to set send_connected_line=no on destination endpoint  to avoid connected line updates

By: Asterisk Team (asteriskteam) 2020-04-22 09:07:47.672-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.