[Home]

Summary:ASTERISK-16403: [patch] I could not find an easy way to access DAHDI channel and span number from the dialplan.
Reporter:Fabio Torchetti (mrwho)Labels:
Date Opened:2010-07-22 05:52:10Date Closed:2011-03-04 09:28:23.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_dahdi-both.patch
( 1) chan_dahdi-channel.patch
( 2) chan_dahdi-privars.patch
( 3) issue17683_v1.8.patch
Description:  I could not find an easy way to access from the dialplan the span and the PRI channel being used by an Asterisk channel. As a quick solution I patched chan_dahdi so that it will populate - if applicable - two variables:

 PRI_CHANNEL: the PRI channel number
 PRI_SPAN: the PRI span number

 These variables can then be used in the dialplan. The patch it's pretty simple, even if I don't know how much it could be needed by others.
Comments:By: Leif Madsen (lmadsen) 2010-07-26 09:53:53

Would it make more sense to add this functionality to the CHANNEL() function? We don't really like to add channel variables for this kind of functionality anymore.
By: Fabio Torchetti (mrwho) 2010-07-27 03:00:34

I see the point, the attached patch will add two variables that can be read using the CHANNEL() function.

Now it's possible to access the span and PRI channel information using:

 CHANNEL(pri_span)

and

 CHANNEL(pri_channel)

Sorry for the previous patch, I guess I should have asked how it would have been the proper way of handling this.
By: Fabio Torchetti (mrwho) 2010-07-27 05:14:53

Well, it seems that in some cases the "CHANNEL" implementation is not enough. As an example, if we need to access the information about SPAN and PRI channel externally and we set two variables in the dialplan like so:

<pre>
exten => _X!,n, Set(PRI_CHANNEL=${CHANNEL(pri_channel})
exten => _X!,n, Set(PRI_SPAN=${CHANNEL(pri_span})
</pre>

 it all works out well for the main leg of the call. The other leg will have the variables populated only after the "Dial" has completed and jumped to the relevant part of the dialplan.

 Setting the variables for the channel from the chan_dahdi code allows for external programs interfacing to asterisk to access that information from the moment the channel is set-up.

 Since this may be a very exotic setting - isn't after all ISDN an exotic phone system - I made a patch including both solutions, to activate the creation of the channel variables being set automatically you will need to uncomment in chan_dahdi.c the following line:

<pre>
/* #define PRI_VARS 1 */
</pre>

 I believe that like this we can satisfy a wider range of needs. On the other hand: my beliefs are often wrong. :)


By: Leif Madsen (lmadsen) 2010-07-27 08:32:31

Hmmm, I see your point :)

OK so at this point we're at a crossroads and need to make an informed decision. The way to resolve this is to post something to the asterisk-dev list and get some of the other developers to weigh in on the decision making. This way we don't waste any more of your time with implementations that we can't accept :)

So go ahead and ask on asterisk-dev about this issue, and then we can let the other community developers help us decide what is best.

Thanks for all your work so far!
By: Leif Madsen (lmadsen) 2011-01-05 15:20:06.000-0600

Any chance you were able to ask the Asterisk-dev list about this? If so, can you post an archive of the discussion? If not, can you ask again? Thanks!
By: Leif Madsen (lmadsen) 2011-01-21 08:45:10.000-0600

http://lists.digium.com/pipermail/asterisk-dev/2011-January/047545.html
By: Richard Mudgett (rmudgett) 2011-03-01 17:11:14.000-0600

Attached issue17683_v1.8.patch file.  I started with the chan_dahdi-channel.patch and changed:
CHANNEL(pri_channel) --> CHANNEL(dahdi_channel)
CHANNEL(pri_span) --> CHANNEL(dahdi_span)
because the value is applicable to chan_dahdi as a whole instead of just PRI channels.

I added CHANNEL(dahdi_type) so the dialplan can determine what kind of DAHDI channel it is so CHANNEL(no_media_path) can be used without generating a warning in mixed DAHDI channel type environments.
By: Digium Subversion (svnbot) 2011-03-04 09:22:07.000-0600

Repository: asterisk
Revision: 309445

U   branches/1.8/UPGRADE.txt
U   branches/1.8/channels/chan_dahdi.c
U   branches/1.8/channels/sig_pri.c
U   branches/1.8/channels/sig_pri.h
U   branches/1.8/funcs/func_channel.c

------------------------------------------------------------------------
r309445 | rmudgett | 2011-03-04 09:22:06 -0600 (Fri, 04 Mar 2011) | 46 lines

Get real channel of a DAHDI call.

Starting with Asterisk v1.8, the DAHDI channel name format was changed for
ISDN calls to: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>

There were several reasons that the channel name had to change.

1) Call completion requires a device state for ISDN phones.  The generic
device state uses the channel name.

2) Calls do not necessarily have B channels.  Calls placed on hold by an
ISDN phone do not have B channels.

3) The B channel a call initially requests may not be the B channel the
call ultimately uses.  Changes to the internal implementation of the
Asterisk master channel list caused deadlock problems for chan_dahdi if it
needed to change the channel name.  Chan_dahdi no longer changes the
channel name.

4) DTMF attended transfers now work with ISDN phones because the channel
name is "dialable" like the chan_sip channel names.

For various reasons, some people need to know which B channel a DAHDI call
is using.

* Added CHANNEL(dahdi_span), CHANNEL(dahdi_channel), and
CHANNEL(dahdi_type) so the dialplan can determine the B channel currently
in use by the channel.  Use CHANNEL(no_media_path) to determine if the
channel even has a B channel.

* Added AMI event DAHDIChannel to associate a DAHDI channel with an
Asterisk channel so AMI applications can passively determine the B channel
currently in use.  Calls with "no-media" as the DAHDIChannel do not have
an associated B channel.  No-media calls are either on hold or
call-waiting.

(closes issue ASTERISK-16403)
Reported by: mrwho
Tested by: rmudgett

(closes issue ASTERISK-17229)
Reported by: arjankroon
Patches:
     issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
Tested by: stever28, rmudgett

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=309445
By: Digium Subversion (svnbot) 2011-03-04 09:28:22.000-0600

Repository: asterisk
Revision: 309446

_U  trunk/
U   trunk/UPGRADE-1.8.txt
U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_pri.c
U   trunk/channels/sig_pri.h
U   trunk/funcs/func_channel.c

------------------------------------------------------------------------
r309446 | rmudgett | 2011-03-04 09:28:21 -0600 (Fri, 04 Mar 2011) | 53 lines

Merged revisions 309445 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r309445 | rmudgett | 2011-03-04 09:22:04 -0600 (Fri, 04 Mar 2011) | 46 lines
 
 Get real channel of a DAHDI call.
 
 Starting with Asterisk v1.8, the DAHDI channel name format was changed for
 ISDN calls to: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
 
 There were several reasons that the channel name had to change.
 
 1) Call completion requires a device state for ISDN phones.  The generic
 device state uses the channel name.
 
 2) Calls do not necessarily have B channels.  Calls placed on hold by an
 ISDN phone do not have B channels.
 
 3) The B channel a call initially requests may not be the B channel the
 call ultimately uses.  Changes to the internal implementation of the
 Asterisk master channel list caused deadlock problems for chan_dahdi if it
 needed to change the channel name.  Chan_dahdi no longer changes the
 channel name.
 
 4) DTMF attended transfers now work with ISDN phones because the channel
 name is "dialable" like the chan_sip channel names.
 
 For various reasons, some people need to know which B channel a DAHDI call
 is using.
 
 * Added CHANNEL(dahdi_span), CHANNEL(dahdi_channel), and
 CHANNEL(dahdi_type) so the dialplan can determine the B channel currently
 in use by the channel.  Use CHANNEL(no_media_path) to determine if the
 channel even has a B channel.
 
 * Added AMI event DAHDIChannel to associate a DAHDI channel with an
 Asterisk channel so AMI applications can passively determine the B channel
 currently in use.  Calls with "no-media" as the DAHDIChannel do not have
 an associated B channel.  No-media calls are either on hold or
 call-waiting.
 
 (closes issue ASTERISK-16403)
 Reported by: mrwho
 Tested by: rmudgett
 
 (closes issue ASTERISK-17229)
 Reported by: arjankroon
 Patches:
       issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
 Tested by: stever28, rmudgett
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=309446