[Home]

Summary:ASTERISK-23008: Local channels loose CALLERID name when DAHDI channel connects
Reporter:Michael Cargile (mcargile)Labels:
Date Opened:2013-12-16 13:36:42.000-0600Date Closed:2014-01-20 16:09:03.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_dahdi Channels/chan_local
Versions:1.8.24.0 Frequency of
Occurrence
Related
Issues:
Environment:Server is running Asterisk 1.8.24, DAHDI 2.8.0, and Libpri 1.4.14Attachments:
Description:Local channels do not seem to be keeping the caller id name for Dahdi channels. After the call connects the caller id name ends up blank. This works fine for SIP and IAX channels.

Here is the dialplan I am using:
{noformat}
exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,n,Noop(${CALLERID(name)})
exten => _91NXXNXXXXXX,n,Dial(${TRUNKX}/${EXTEN:1},,To)
exten => _91NXXNXXXXXX,n,Hangup()

exten => 8302,1,Answer()
exten => 8302,n,Noop(${CALLERID(name)})
exten => 8302,n,Playback(conf)
exten => 8302,n,Hangup()
{noformat}

Here is a call placed with the Local Channel:

{noformat}
vicibox*CLI> ! perl /usr/src/astguiclient/trunk/extras/test_call.pl 918999995777 8302 test 8633939330
INSERT INTO vicidial_manager values( '', '', '2013-12-16 14:12:44', 'NEW', 'N', '192.168.198.106', '', 'Originate', 'TESTCIDBLASTCALL0124', 'Channel: Local/918999995777', 'Context; default', 'Exten: 8302', 'Priority: 1', 'Callerid: "test" <8633939330>', '', '', '', '', '' );
[Dec 16 14:12:44]   == Manager 'sendcron' logged on from 127.0.0.1
[Dec 16 14:12:44]     -- Executing [918999995777@default:1] AGI("Local/918999995777@default-00000001;2", "agi://127.0.0.1:4577/call_log") in new stack
[Dec 16 14:12:44]     -- <Local/918999995777@default-00000001;2>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Dec 16 14:12:44]     -- Executing [918999995777@default:2] NoOp("Local/918999995777@default-00000001;2", "test") in new stack
[Dec 16 14:12:44]     -- Executing [918999995777@default:3] Dial("Local/918999995777@default-00000001;2", "DAHDI/r1/18999995777,,To") in new stack
[Dec 16 14:12:44]     -- Requested transfer capability: 0x00 - SPEECH
[Dec 16 14:12:44]     -- Called DAHDI/r1/18999995777
[Dec 16 14:12:44]     -- DAHDI/i1/18999995777-6 is proceeding passing it to Local/918999995777@default-00000001;2
[Dec 16 14:12:44]     -- DAHDI/i1/18999995777-6 answered Local/918999995777@default-00000001;2
[Dec 16 14:12:44]        > Channel Local/918999995777@default-00000001;1 was answered.
[Dec 16 14:12:44]     -- Executing [8302@default:1] Answer("Local/918999995777@default-00000001;1", "") in new stack
[Dec 16 14:12:44]     -- Executing [8302@default:2] NoOp("Local/918999995777@default-00000001;1", "") in new stack
[Dec 16 14:12:44]     -- Executing [8302@default:3] Playback("Local/918999995777@default-00000001;1", "conf") in new stack
[Dec 16 14:12:44]     -- <Local/918999995777@default-00000001;1> Playing 'conf.gsm' (language 'en')
[Dec 16 14:12:44]     -- Executing [h@default:1] AGI("Local/918999995777@default-00000001;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----0-----0") in new stack
[Dec 16 14:12:44]     -- <Local/918999995777@default-00000001;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----0-----0 completed, returning 0
[Dec 16 14:12:44]   == Spawn extension (default, 918999995777, 3) exited non-zero on 'Local/918999995777@default-00000001;2'
[Dec 16 14:12:45]   == Manager 'sendcron' logged off from 127.0.0.1
{noformat}

Here is a call placed with the DAHDI channel directly:

{noformat}
vicibox*CLI> ! perl /usr/src/astguiclient/trunk/extras/test_dahdi_call.pl 18999995777 8302 test 8633939330
INSERT INTO vicidial_manager values( '', '', '2013-12-16 14:12:32', 'NEW', 'N', '192.168.198.106', '', 'Originate', 'TESTCIDBLASTCALL0124', 'Channel: DAHDI/r1/18999995777', 'Context; default', 'Exten: 8302', 'Priority: 1', 'Callerid: "test" <8633939330>', '', '', '', '', '' );
[Dec 16 14:12:32]   == Manager 'sendcron' logged on from 127.0.0.1
[Dec 16 14:12:32]     -- Requested transfer capability: 0x00 - SPEECH
[Dec 16 14:12:32]        > Channel DAHDI/i1/18999995777-5 was answered.
[Dec 16 14:12:32]     -- Executing [8302@default:1] Answer("DAHDI/i1/18999995777-5", "") in new stack
[Dec 16 14:12:32]     -- Executing [8302@default:2] NoOp("DAHDI/i1/18999995777-5", "test") in new stack
[Dec 16 14:12:32]     -- Executing [8302@default:3] Playback("DAHDI/i1/18999995777-5", "conf") in new stack
[Dec 16 14:12:32]     -- <DAHDI/i1/18999995777-5> Playing 'conf.gsm' (language 'en')
[Dec 16 14:12:33]   == Manager 'sendcron' logged off from 127.0.0.1
{noformat}

As I said this works for SIP and IAX channels in Asterisk 1.8 just fine. The last time I tested this with Dahdi though was when using Asterisk 1.4.44 and it worked then.
Comments:By: Richard Mudgett (rmudgett) 2013-12-16 15:25:16.730-0600

Look into the 'I' Dial option.  I suspect that the connected line update is updating the information.  Also see
https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information
By: Michael Cargile (mcargile) 2013-12-16 16:20:09.758-0600

While that seems to have fixed it, (need to do further testing) I am confused as to why adding a Local channel into the mix would cause this behavior.
By: Rusty Newton (rnewton) 2013-12-17 15:14:44.304-0600

Talked with Richard Mudgett about this. He'll comment on the expected behavior here when he gets a chance. It is a little confusing, so I don't want to relay it second-hand and get it twisted.
By: Richard Mudgett (rmudgett) 2014-01-16 22:02:31.131-0600

For normal operations where Party A calls Party B this is what the relationship between CALLERID/CONNECTEDLINE information looks like:
{noformat}
           Channel A                       Channel B
           Incoming channel --- bridge --- Outgoing channel
Party A ___ CALLERID() -------------------> CONNECTEDLINE() ___ Party B
           CONNECTEDLINE() <-------------- CALLERID()
{noformat}

The CALLERID() information is the party identification of the remote party.  For Channel A that is Party A.  For Channel B that is Party B.

The CONNECTEDLINE() information is the party identification of the party connected across the bridge.  For Channel A that is Party B.  For Channel B that is Party A.

Local channels behave in a similar way because there is an implicit two party bridge between the channels.  For normal call setups, Local;1 is an outgoing channel and Local;2 is an incoming channel.

{noformat}
Local;1              Local;2
Outgoing channel --- Incoming channel
CONNECTEDLINE() ---> CALLERID()
CALLERID() <-------- CONNECTEDLINE()
{noformat}

A normal call where Party A calls Party B with a local channel in the chain.

{noformat}
           Channel A                       Local;1              Local;2                         Channel B
           Incoming channel --- bridge --- Outgoing channel --- Incoming channel --- bridge --- Outgoing channel
Party A ___ CALLERID() -------------------> CONNECTEDLINE() ---> CALLERID() -------------------> CONNECTEDLINE() ___ Party B
           CONNECTEDLINE() <-------------- CALLERID() <-------- CONNECTEDLINE() <-------------- CALLERID()
{noformat}

Originated calls make the incoming and outgoing labels a bit confusing because both channels start off as outgoing.  Once the originated channel answers it becomes an "incoming" channel to run dialplan.  A better way is to just distinguish which channel is running dialplan.  For consistency, I'll continue using the incoming and outgoing labels.

An example of originating a normal channel (Channel A) to a dialplan exten.
1) Channel A dials Party A
2) Party A answers
3) The CONNECTEDLINE update from Channel A triggered by the answer is discarded because it has nowhere to go.
4) Channel A becomes an incoming channel to run dialplan to dial Party B.

{noformat}
           Channel A                       Channel B
           Incoming channel --- bridge --- Outgoing channel
Party A ___ CALLERID() -------------------> CONNECTEDLINE() ___ Party B
           CONNECTEDLINE() <-------------- CALLERID()
{noformat}

An example of originating a local channel (which will always be a Local;1) to a dialplan exten.
1) Local;1 makes Local;2 run dialplan to call Party A
2) Party A answers
3) The CONNECTEDLINE update from Channel A triggered by the answer propagates to Local;1 if not blocked by the Dial 'I' option on Local;2.
4) Local;1 becomes an incoming channel to run dialplan to dial Party B.

{noformat}
           Channel A                       Local;2              Local;1                         Channel B
           Outgoing channel --- bridge --- Incoming channel --- Incoming channel --- bridge --- Outgoing channel
Party A ___ CALLERID() -------------------> CONNECTEDLINE() ---> CALLERID() -------------------> CONNECTEDLINE() ___ Party B
           CONNECTEDLINE() <-------------- CALLERID() <-------- CONNECTEDLINE() <-------------- CALLERID()
{noformat}

If Party A supplies connected line information when it answers then there would not be any difference between originating to Party A directly or through a local channel.  The CALLERID values of Channel A and Local;1 would be updated to the connected line information supplied by Party A.  However, since your ISDN connection for Party A is not supplying *any* connected line information when it answers, the DAHDI channel (Channel A) is erroneously passing on an empty connected line update and wiping out the Local;1 CALLERID values.  The Dial 'I' option blocks the empty connected line update.  Also if you must always have the original CALLERID information you supplied with the originate then you still need to use the Dial 'I' option.

By: Rusty Newton (rnewton) 2014-01-20 11:01:08.558-0600

Closing this out as Not A Bug. By Richard's explanation, the behavior reported is expected.

If you have further questions on this behavior feel free to start a conversations on the [asterisk-users mailing list|http://www.asterisk.org/community/discuss], or bring up the issue in the [#asterisk-bugs IRC channel|http://www.asterisk.org/community/discuss] if you find something else that you feel may be a bug.

Richard will be adding this documentation to the https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information page.
By: Rusty Newton (rnewton) 2014-01-20 11:17:32.338-0600

Oops, actually, there is a bug "the DAHDI channel (Channel A) is erroneously passing on an empty connected line update and wiping out the Local;1 CALLERID values"

Richard has a potential patch and will be posting further updates.
By: Michael Cargile (mcargile) 2014-01-20 16:31:52.902-0600

I am confused about what happened with this ticket. It looks like you cloned it, but now I cannot find the clone nor do I see an update on this ticket with the potential patch.
By: Richard Mudgett (rmudgett) 2014-01-20 16:43:26.495-0600

The cloned issue is used internally by Digium for issue prioritization.

I have committed the patch.  Look at the Subversion tab.  The Subversion tab can be found at the top of the Activity section of the issue.  On the Subversion tab you will see the commits associated with this issue for each branch.  You can get the patch from Subversion.
By: Michael Cargile (mcargile) 2014-01-20 16:48:53.845-0600

Ahh okay. Just seemed a bit confusing. Thank you.