Get CDR to display individual channels from DAHDI

I have a PRI circuit with 23 channels. In older versions of Asterisk, I remember seeing CDR displaying my trunk as DAHDI/23-1, DAHDI/22-1, etc…

With the current version of FreePBX Distro, 5.211, the CDR report shows as DAHDI/i1/XXXXXXXXXXX. How can I get it to show with the individual channel #?

My goal is to determine the maximum channels used / concurrent calls and if I need to order more phone lines.

Thank you.

SELECT channel, calldate, duration FROM cdr WHERE channel LIKE '%DAHDI%'

or better calls from the last 7 days with call id stripped:

SELECT SUBSTRING(channel,1,CHAR_LENGTH(channel) - 9), calldate, duration from cdr WHERE channel LIKE '%DAHDI%' AND calldate >= ( CURDATE() - INTERVAL 7 DAY);

The output of the data is exactly the same as in the CDR report. All my entries under dstchannel shows as “DADHI/i1” as the starting text. I know in previous versions, it displays with the individual channel (DAHDI/1-1, DAHDI/2-1,… all the way to DAHDI/23-1). Assuming I have 23 phone lines. How can I change FreePBX to display the channels the way I need it to be?

Hope I am explaining my issue correctly. Thanks!

OK, I found when it got changed. So how can I get the “bchan” to show on the CDR?

2011-03-04 15:22 +0000 [r309445] Richard Mudgett [email protected]

* UPGRADE.txt, channels/sig_pri.c, channels/sig_pri.h,
  channels/chan_dahdi.c, funcs/func_channel.c: 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 #17683) Reported by: mrwho Tested by: rmudgett
  (closes issue #18603) Reported by: arjankroon Patches:
  issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
  Tested by: stever28, rmudgett

I didn’t mention anything about the column dstchannel

Send me the unmodified channel I’d in a pm

Sent. Thanks!

Ok so at midnight from my phone the brain, not super effective…

Here is what you are getting which is actually covered above in your posted change log.

[CHANNELDRIVER]/i[SPAN]/[ANI]

So the output you sent me (representative):

DAHDI/i1/4805551212

The explanation of why it is this way is above also.

You have a PRI. You are thinking of it as analog channels which have a 1 to 1 mapping on channels. A call comes in on channel 1 it should be DAHDI/1

This isn’t the case with PRI.

PRI is like sip.

On sip you have a controller port 5060, on PRI you have a Data channel 24.
Both of these handle everything about the call except audio. All call setup and tear down happens here.

On sip you have RTP ports 10,000-20,000. Your calls audio happens here. This is only needed if the call requires an audio path. A big complaint is one way audio or no audio when users first setup because they didn’t configure their firewall or NAT correctly. The call is up but they can’t hear each other. This is because the actual call happens on 5060 which they usually poke a hole for but they didn’t poke the audio holes.

On PRI you have B channels. These channels are dumb. They don’t do anything but pass audio. A call on a PRI that doesn’t require audio doesn’t need a B channel. A PRI can hold up a call without audio releasing the B channel then assign it when audio is needed.

So the point of it all is this:
Don’t concern your self with how often a call is using B Channel foo. Take the entire span as a whole.

12:00 span 1, 5 calls
12:05 span 1, 2 calls
12:10 span 1, 8 calls
12:15 span 1, 4 calls



12 PM hour peak 10, average 8.

If my PRI allows 10 calls I may want to bump if I average 8 and am maxing out.
If it peaked at 8 and averaged 4 maybe 10 is ok.

You have to figure out how to analyze the data…