[Home]

Summary:ASTERISK-28739: Dropping redundant connected line update
Reporter:David Cunningham (dcunningham)Labels:
Date Opened:2020-02-12 23:47:17.000-0600Date Closed:2020-03-03 04:09:39.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/General
Versions:13.29.2 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Debian 9 64 bitAttachments:
Description:We are seeing a "Dropping redundant connected line update" message in the Asterisk log which appears to be incorrect.

The channel with the update is created by a Dial out from Asterisk to a SIP telephone:

[Feb 13 14:05:01] DEBUG[2899] manager.c: Examining AMI event:
Event: Newexten
Privilege: call,all
Timestamp: 1581563101.208429
Channel: SIP/AAA.AAA.52.245:5060-000002f0
ChannelState: 0
ChannelStateDesc: Down
CallerIDNum: 897
CallerIDName: John
ConnectedLineNum: 897
ConnectedLineName: John
Language: en
AccountCode:
Context: from-external
Exten: 171373917
Priority: 1
Uniqueid: 1581563101.2732
Linkedid: 1581563101.2729
Extension: 171373917
Application: AppDial
AppData: (Outgoing Line)

This results in an INVITE:

[Feb 13 14:05:01] VERBOSE[23326][C-0000019a] chan_sip.c: Reliably Transmitting (NAT) to AAA.AAA.52.245:5060:
INVITE sip:171373917@AAA.AAA.52.245:5060 SIP/2.0
Via: SIP/2.0/UDP AAA.AAA.52.245:5070;branch=z9hG4bK76f896c2;rport
Max-Forwards: 70
From: "John" <sip:897@AAA.AAA.52.245:5070>;tag=as0795e872
To: <sip:171373917@AAA.AAA.52.245:5060>
Contact: <sip:897@AAA.AAA.52.245:5070>
Call-ID: 2baf801c5631714d53c92b27735249a6@AAA.AAA.52.245:5070

Later we try to update the callerid to 0123456789 via the AMI however Asterisk rejects it:

[Feb 13 14:05:07] DEBUG[23424] manager.c: Running action 'Login'
[Feb 13 14:05:07] DEBUG[23424] manager.c: Running action 'Setvar'
[Feb 13 14:05:07] DEBUG[23424] channel.c: SIP/AAA.AAA.52.245:5060-000002f0: Dropping redundant connected line update "0123456789" <0123456789>.
[Feb 13 14:05:07] DEBUG[23424] manager.c: Running action 'Logoff'

Reading the Asterisk code, I believe it should only be considered redundant if the callerid is unchanged, but here it really is different.
Please let us know what else is needed to debug this issue. Thank you.
Comments:By: Asterisk Team (asteriskteam) 2020-02-12 23:47:18.699-0600

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].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Joshua C. Colp (jcolp) 2020-02-13 06:44:17.550-0600

What exactly are you executing and changing? Caller ID and Connected Line are two separate things. There is some interaction at times, but they are still separate.
By: David Cunningham (dcunningham) 2020-02-13 17:03:32.859-0600

Hi Joshua, we're using AMI action Setvar to set variable CONNECTEDLINE(number) to the new callerid. The intended result is to send an update to the connected telephone with a new callerid to display. This worked in testing, but now we've experienced the problem described in some cases - we are not sure why. Thank you.
By: George Joseph (gjoseph) 2020-02-17 11:15:17.249-0600

It's still a little unclear what the scenario and your objective are.

Setting CONNECTEDLINE on an outgoing channel is going to go back into the Asterisk core to the incoming channel.  Is that what you wanted?

See this wiki page fore mote info on CALLERID and CONNECTEDLINE.
https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information



By: David Cunningham (dcunningham) 2020-02-17 16:19:15.139-0600

As I understand it CALLERID is about what callerid we receive. What we want to do is update the callerid for a party on an already active call. This bit sounds like our intended usage:
"You can use it to send new connected line information to the remote party on the channel when a call is transferred."

For example:
1. A calls B
2. B does an attended REFER transfer to C
3. B completes the transfer, dropping out of the call
4. C is updated to say that the callerid is now A

Thank you.

By: George Joseph (gjoseph) 2020-02-18 08:46:47.388-0600

In this scenario, C is the called party so it's CALLERID that's applied to them.  CONNECTEDLINE would go back to A to tell them that the call was transferred from B to C.


By: David Cunningham (dcunningham) 2020-02-19 16:59:19.759-0600

Surely if we set variable CONNECTEDLINE(number) on C's channel then it sends C the new callerid? If we wanted to update A then we would set it on A's channel?

By: George Joseph (gjoseph) 2020-02-20 08:15:37.413-0600

Sorry David.  I was working two callerid/connected line issues at the same time and got confused.   Let me re-test this again.

By: George Joseph (gjoseph) 2020-02-20 13:42:07.471-0600

I'm having a hard time reproducing this.  When you're updating CONNECTEDLINE, what state is the channel to C in?  Has C already answered?

Can you put together a simple dialplan and configuration I can test with?

Also, it looks like you're using chan_sip, can you do a test using chan_pjsip?



By: David Cunningham (dcunningham) 2020-02-20 21:19:04.156-0600

Yes, the channel is answered.

We're using chan_sip in production and unfortunately can't change that.

I will see if I can come up with a simple scenario to reproduce the problem, thanks.
By: George Joseph (gjoseph) 2020-02-21 08:52:01.738-0600

Yeah I realize it wouldn't be easy to switch channel drivers in production but if you can do a simple test with chan_pjsip it would help determine if the issue is related to the channel driver or the core channel or manager facilities themselves.

Thanks.

By: David Cunningham (dcunningham) 2020-03-02 19:47:45.582-0600

We have found that when sendrpid=pai Asterisk sends an updated INVITE with P-Asserted-Identity at the time of the transfer with the new callerid anyway, which is probably why our Setvar of CONNECTEDLINE(number) to that number is dropped as redundant.

You can close this issue, thank you.