In 1.4.43 I would see things from "core show channels" like DAHDI/18/xxxxx for line 18 in Asterisk 11 its DAHDI/i4/xxxx How do I get the line number back? Jerry
> In 1.4.43 I would see things from "core show channels" like > DAHDI/18/xxxxx > for line 18 > > in Asterisk 11 its > DAHDI/i4/xxxx > > How do I get the line number back?This was a change in v1.8 and is documented in the v1.8 UPGRADE.txt file: * The PRI channels in chan_dahdi can no longer change the channel name if a different B channel is selected during call negotiation. To prevent using the channel name to infer what B channel a call is using and to avoid name collisions, the channel name format is changed. The new channel naming for PRI channels is: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number> * 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. Richard
> This was a change in v1.8 and is documented in the v1.8 UPGRADE.txt file: > > * The PRI channels in chan_dahdi can no longer change the channel name if a > different B channel is selected during call negotiation. To prevent using > the channel name to infer what B channel a call is using and to avoid name > collisions, the channel name format is changed. > The new channel naming for PRI channels is: > DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number> > > * 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. >ok - can I use a different method of doing my check to see if a line is available by using the AMI call ExtensionState or ChanIsAvail? Doing Action: ExtensionState Parameters: DAHDI/1 says Error Message: Extension not specified and Action: Command Command: ChanIsAvail Parameters: DAHDI/1 says Error No such command "ChanIsAvail" I'm clearly missing something? Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121220/b841bfee/attachment.htm>
IMO the local channel call should be the lowest overhead option available. From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Jerry Geis Sent: Thursday, December 20, 2012 11:42 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] asterisk 11 and DAHDI/i4 You should just cache the AMI DAHDIChannel event information in your program. If you really must you could use the CLI command "pri show channels". However, it is not intended to be repeatedly run for performance reasons. It blocks processing of ISDN messages while it is running. I am not continually logged in to the AMI to catch those events... Can I make a call to a local channel, run some context+ extension, there call ChanIsAvail for the channel I am interested in - but they how do I get that info back to my C program? Also is that a big overhead? jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121220/2bd03fc1/attachment.htm>
> You should just cache the AMI DAHDIChannel event information in your > program. > > If you really must you could use the CLI command "pri show channels". > However, it is not intended to be repeatedly run for performance > reasons. It blocks processing of ISDN messages while it is running. > I am not continually logged in to the AMI to catch those events... > > Can I make a call to a local channel, run some context+ extension, > there call ChanIsAvail for the channel I am interested in - > but they how do I get that info back to my C program? > > Also is that a big overhead?Whether the overhead is going to affect performance to be a problem depends on how often you execute the command. You can also use the AMI DAHDIShowChannels action. If the channel has a B channel it will be listed with which B channel it currently is attached. Richard
> ------------------------------------------------------------------------ > IMO the local channel call should be the lowest overhead option available.What about: Action: Command Command: dahdi show channels I can just look to see if "Extension" has anything for the Chan I am interested in? is that a big overhead and block anything? Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121220/fe553e16/attachment.htm>
On 12/20/2012 01:00 PM, Jerry Geis wrote:>> ------------------------------------------------------------------------ >> IMO the local channel call should be the lowest overhead option available. > What about: > > Action: Command > Command: dahdi show channels > > I can just look to see if "Extension" has anything for the Chan I am > interested in? > > is that a big overhead and block anything? > > Jerry >Looks like the "dahdi show channels" does not work for me because if I make a call originating from a polycom phone going out a line (DAHDI/1) it is not reflected there. So I cannot tell the line is in use. It only shows a call as active if its an incoming call. Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121220/b03f8871/attachment.htm>
I have a little dialplan context now...
[check-chanisavail]
exten => s,1,ChanIsAvail(${agi_channel})
exten => s,n,System(/bin/echo ${AVAILCHAN} > /tmp/${agi_file})
exten => s,n,Hangup()
and a call file:
Channel: Local/s at check-chanisavail/n
Context: check-chanisavail
Extension: s
Priority: 1
SetVar: agi_file=jerry
SetVar: agi_channel=DAHDI/1
To tell me if a channel is busy or not.
When no channels are busy I execute the dialplan above and
it correctly gave me DAHDI/1-1 in my file. As expected.
When I call in from the outside into my asterisk box,
then I execute my dialplan above and I query (DAHDI/1) I get
AVAILCHAN = "" which is what I expect.
However, if I use a polycom phone to dial out, and then I execute
my dialplan above and I query (DAHDI/1) it says its still available.
Should it not say AVAILCHAN = "" as I am using that line it is not
available.
Thanks,
Jerry