[asterisk-bugs] [JIRA] (ASTERISK-23008) Asterisk 1.8.24 local channels loose caller id name when dahdi channel connects
Richard Mudgett (JIRA)
noreply at issues.asterisk.org
Thu Jan 16 22:03:03 CST 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-23008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Mudgett updated ASTERISK-23008:
---------------------------------------
Status: Waiting for Feedback (was: Waiting for Feedback)
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.
> Asterisk 1.8.24 local channels loose caller id name when dahdi channel connects
> -------------------------------------------------------------------------------
>
> Key: ASTERISK-23008
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-23008
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_dahdi, Channels/chan_local
> Affects Versions: 1.8.24.0
> Environment: Server is running Asterisk 1.8.24, DAHDI 2.8.0, and Libpri 1.4.14
> Reporter: Michael Cargile
> Assignee: Richard Mudgett
>
> 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 at default:1] AGI("Local/918999995777 at default-00000001;2", "agi://127.0.0.1:4577/call_log") in new stack
> [Dec 16 14:12:44] -- <Local/918999995777 at default-00000001;2>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
> [Dec 16 14:12:44] -- Executing [918999995777 at default:2] NoOp("Local/918999995777 at default-00000001;2", "test") in new stack
> [Dec 16 14:12:44] -- Executing [918999995777 at default:3] Dial("Local/918999995777 at 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 at default-00000001;2
> [Dec 16 14:12:44] -- DAHDI/i1/18999995777-6 answered Local/918999995777 at default-00000001;2
> [Dec 16 14:12:44] > Channel Local/918999995777 at default-00000001;1 was answered.
> [Dec 16 14:12:44] -- Executing [8302 at default:1] Answer("Local/918999995777 at default-00000001;1", "") in new stack
> [Dec 16 14:12:44] -- Executing [8302 at default:2] NoOp("Local/918999995777 at default-00000001;1", "") in new stack
> [Dec 16 14:12:44] -- Executing [8302 at default:3] Playback("Local/918999995777 at default-00000001;1", "conf") in new stack
> [Dec 16 14:12:44] -- <Local/918999995777 at default-00000001;1> Playing 'conf.gsm' (language 'en')
> [Dec 16 14:12:44] -- Executing [h at default:1] AGI("Local/918999995777 at 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 at 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 at 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 at default:1] Answer("DAHDI/i1/18999995777-5", "") in new stack
> [Dec 16 14:12:32] -- Executing [8302 at default:2] NoOp("DAHDI/i1/18999995777-5", "test") in new stack
> [Dec 16 14:12:32] -- Executing [8302 at 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list