[Home]

Summary:ASTERISK-17229: [patch] Get Real Channel of a Dahdi Call
Reporter:arjan kroon (arjankroon)Labels:
Date Opened:2011-01-12 06:41:58.000-0600Date Closed:2011-03-04 09:28:24.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) issue17683_18603_v1.8_v2.patch
( 1) issue17683_18603_v1.8.patch
( 2) issue18603_v1.8_v2.patch
( 3) issue18603_v1.8.patch
Description:The channel name for DAHDI channels has changed in 1.8.
This is mentioned in http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.8-current

The old format was DAHDI/XX-Y where XX was the real channel number.
It has changed to DAHDI/iZ/XXXXXXXXXX-YYY where XXXXXXXXXX is the callerid.
And Z is the number of the span in /etc/dahdi/system.conf

Our channel names look like this
DAHDI/i8/0517383600-229
DAHDI/i1/0031650545840-329
DAHDI/i4/0512515245-20f
DAHDI/i6/0517417488-1fb

But we want to know which channel number of these four channels is used.

Or is there a new VARIABLE where this real CHANNEL found.

With DAHDI SHOW CHANNELS you see the number of channels in Chan pseudo.




****** ADDITIONAL INFORMATION ******

P.S.
This is our system.conf:

span=1,1,0,ccs,hdb3,yellow
bchan=1-15,17-31
dchan=16
span=2,1,0,ccs,hdb3,yellow
bchan=32-46,48-62
dchan=47
span=3,1,0,ccs,hdb3,yellow
bchan=63-77,79-93
dchan=78
span=4,1,0,ccs,hdb3,yellow
bchan=94-108,110-124
dchan=109
span=5,1,0,ccs,hdb3,yellow
bchan=125-139,141-155
dchan=140
span=6,1,0,ccs,hdb3,yellow
bchan=156-170,172-186
dchan=171
span=7,1,0,ccs,hdb3,yellow
bchan=187-201,203-217
dchan=202
span=8,1,0,ccs,hdb3,yellow
bchan=218-232,234-248
dchan=233

We use two seperate cards. (TE4/1/3 "T4XXP (PCI))
Comments:By: David Woolley (davidw) 2011-01-12 06:50:42.000-0600

See http://forums.digium.com/viewtopic.php?f=1&t=76686 for some background.

By channel he means time slot, or some abstraction of time slot.  He seems to want to count busy time slots.

http://forums.digium.com/viewtopic.php?f=1&t=76355 also refers, but doesn't seem to add to the above.
By: arjan kroon (arjankroon) 2011-01-12 06:52:45.000-0600

This is correct.
These topics are the same.
By: David Woolley (davidw) 2011-01-12 07:04:00.000-0600

I assume he's claiming this is a regression problem.
By: arjan kroon (arjankroon) 2011-01-12 07:06:10.000-0600

I've look at the function CHANNEL

http://www.voip-info.org/wiki/view/Asterisk+func+channel

Which item in the channel function do you need to get the real channel?
By: Leif Madsen (lmadsen) 2011-01-12 08:37:46.000-0600

I wouldn't look at the voip-info site for reliable documentation. It is frequently out of date (and wrong)
By: Leif Madsen (lmadsen) 2011-01-12 08:40:31.000-0600

Can you provide the dialplan you're using to look at the channel name? Perhaps there is another option that is more appropriate.
By: arjan kroon (arjankroon) 2011-01-12 08:40:55.000-0600

Yes, I'm looking forward to Asterisk: The Definitive Guide 1.8 (final release)
By: arjan kroon (arjankroon) 2011-01-12 08:45:47.000-0600

DIALPLAN =
exten => _09091369,1,NoOp("in 09091369")
exten => _09091369,n,NoOp(chan = ${CHANNEL(stats)})
exten => _09091369,n,NoOp(1 = ${CHANNEL})
exten => _09091369,n,NoOp(2 = ${MASTER_CHANNEL})
exten => _09091369,n,NoOp(3 = ${HINT})
exten => _09091369,n,Wait(100)

CLI =
-- Executing [09091369@incoming:1] NoOp("DAHDI/i1/0031655871460-47d", ""in 09091369"") in new stack
-- Executing [09091369@incoming:2] NoOp("DAHDI/i1/0031655871460-47d", "chan = ") in new stack
-- Executing [09091369@incoming:3] NoOp("DAHDI/i1/0031655871460-47d", "1 = DAHDI/i1/0031655871460-47d") in new stack
-- Executing [09091369@incoming:4] NoOp("DAHDI/i1/0031655871460-47d", "2 = ") in new stack
-- Executing [09091369@incoming:5] NoOp("DAHDI/i1/0031655871460-47d", "3 = ") in new stack
-- Executing [09091369@incoming:6] Wait("DAHDI/i1/0031655871460-47d", "100") in new stack


This is done with my mobile phone (0031655871460)
By: arjan kroon (arjankroon) 2011-01-17 02:09:45.000-0600

Hi, does anybody have an idea how to solve the problem with the channel number?

Regards,

Arjan Kroon
By: Leif Madsen (lmadsen) 2011-01-19 10:30:40.000-0600

MASTER_CHANNEL() is a function, not a variable.

I'd think you'd have to do something like:

exten => start,1,Set(OriginalChannel=${MASTER_CHANNEL(CHANNEL)})
By: arjan kroon (arjankroon) 2011-01-20 01:39:51.000-0600

Hi,

I tried the following:
exten => s,n,NoOp(Masterchannel = ${MASTER_CHANNEL(CHANNEL)})

If I called this dialplan, I see in in the CLI the following:
 NoOp("DAHDI/i8/0655871460-5", "Masterchannel = DAHDI/i8/0655871460-5") in new stack

When I look at on which dahdi channel this call came in I see that it is Nr 248

asterisk25*CLI> dahdi show channels
 1            incoming default In Service
etc
248 0303003127 incoming default In Service


I tried to look on the internet if I can see more information on the different option you can choose in MASTER_CHANNEL, but I can't find anything on it.
By: Leif Madsen (lmadsen) 2011-01-20 08:51:32.000-0600

The only information is likely at 'core show function MASTER_CHANNEL'
By: Steve Rawlings (stever28) 2011-02-24 07:00:25.000-0600

Apologies for jumping in here but just some additional reasoning for reverting to the original format.

We've just upgraded to 1.8 from 1.4 and have come across the same issue.  We have a VB6 application that logs into the AMI and parses all events.  The code is looking for DAHDI/XX-Y where XX is the real channel (timeslot), this information is then used to populate a gui showing all 120 channels across four PRI spans, we have a medium sized call centre relying on this information for traffic monitoring.

The current (1.8) output shows DAHDI/i<span>, so this just returns the span number.  This makes our solution pretty useless as we cannot now monitor each channel (timeslot) individually.  The app has worked fine for years, but moving to the latest LTS version has been a major backward step.

Is there no way to have the channel (timeslot) information displayed in the event output instead of just the span number?

Many thanks, Steve.
By: Richard Mudgett (rmudgett) 2011-02-24 11:09:53.000-0600

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.

A fairly simple solution to these monitoring applications is to just keep track of the number of calls on a span.  Isn't the main goal of the monitoring to see how much traffic is on the spans?
By: Steve Rawlings (stever28) 2011-02-24 11:34:53.000-0600

OK, I can accept there was a need to change the channel name but now there's nowhere to find the real channel in real time.  Unfortunately, just keeping track of the number of calls on a span isn't enough information.  We have several Asterisk servers linked by PRI and also linked to a couple of legacy PBX's.  Knowing what is connected to where is quite important.

There is still useful information in channels/sig_pri.c as we still get messages like the following in the full logfile - -- Accepting overlap call from '2241' to '<unspecified>' on channel 0/31, span 1.  We really need the channel and span info and this looks to be the last place to find it, unfortunately I can't see any way to get this to the ami in our app.

If there was an event created at the point that message is sent that the ami could read or even if there was a variable available in the dialplan, I could create a userevent before the dial command and read this from the ami.

We also need the real channel number to be able to identify the channel so we can use MixMonitorMute for PCIDSS compliance in the UK.  Hope you can see were in a bit of a fix here.

Thanks, Steve.
By: Richard Mudgett (rmudgett) 2011-02-24 11:55:52.000-0600

There is a new CLI command "pri show channels" on trunk that may help.
By: Steve Rawlings (stever28) 2011-02-24 14:07:23.000-0600

I'll try and get that loaded on a non-production box and have a look. The only issue with that is I'll need to query that at the correct time, currently (pre 1.8) our app just parses all events real-time and reacts to the information in them, so it's read only with no need to send commands back to the Asterisk server to query anything. The whole app just uses the AMI and events, it couldn't be simpler, even though it's monitoring 120 channels, in fact, we recently ordered a new 4 span card for an expansion programme, taking us to 240 channels to monitor.

I know why the channel name was changed but find it odd that access to the channel (timeslot) information has just been disregarded, I can't be the only one using it surely.

Had a look at pri show channels, unfortunately it's a cli command. As stated above, our requirement is for a passive update using AMI events which can simply be read and reacted to via our VB6 application. Ideally there would at least be events similar to the old 'link' and 'unlink' events, like 'bridge' and 'unlink' in 1.8 but with the old channel (timeslot) information.  As the information is still available, at least in sig_pri, is it not possible to have additional events created, perhaps even additional CEL events?


By: Steve Rawlings (stever28) 2011-02-24 16:40:31.000-0600

Updated / edited previous post.
By: Richard Mudgett (rmudgett) 2011-03-02 11:44:36.000-0600

Attached issue18603_v1.8.patch and issue17683_18603_v1.8.patch files.
The first adds an AMI event DahdiChannel to associate the DAHDI channel with the Asterisk channel.
The second combines the first with issue17683_v1.8.patch from issue ASTERISK-16403 for a total solution.
By: Richard Mudgett (rmudgett) 2011-03-02 12:26:51.000-0600

Updated my earlier patches to xxx_v2.patch to change the case of DahdiChannel to DAHDIChannel to match other AMI events/actions.
By: Steve Rawlings (stever28) 2011-03-02 16:42:30.000-0600

Great, thanks.  I'll test ami events asap and report back.
By: Steve Rawlings (stever28) 2011-03-04 08:33:18.000-0600

We used the 17683/18603 1.8 v2 patch against rls 1.8.3 and although the patch initially failed for funcs/func_channel.c a quick edit fixed it.

The AMI event worked as hoped for and the dialplan function CHANNEL etc worked correctly.  We've completed various event and dialplan tests and all appear to work as expected.

Our app is now working again after a quick edit/re-write, thanks for the patch. Hope this fixes the issues for others.
By: arjan kroon (arjankroon) 2011-03-04 08:36:29.000-0600

Ah great, will this patchs alsoincluded in the next release of asterisk???
version 1.8.4 ??
By: Digium Subversion (svnbot) 2011-03-04 09:22:08.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:23.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