Understanding Dahdi channel names in logs


#1

Hi.
We’re running Asterisk with DAHDI to create conference calls. When tracing call events in the asterisk log, we see references to the two channels in a conference using names like:

DAHDI/i1/12345678-13
DAHDI/i1/23456789-14

Then we see an event like:

Span 1: Channel 0/2 got hangup request, cause 16

I understand that Span 1 is equivalent to the /i1 part of the channel name. But what does the Channel 0/2 refer to? Is there are way to map this to the channel names?

Apologies for what is probably a simple question — I just haven’t been able to find an answer in my searches.


#2

The “Channel 0/2” section refers to logical-span/channel-position. The logical-span is defined by spanmap’s in chan_dahdi.conf for NFAS setups. The channel-position is the offset of the channel (timeslot) within a T1/E1 span.

The simple answer is no you cannot map the “Channel 0/2” to a channel name. Mapping the channel name to which B channel it is associated with is not directly exposed because the mapping can change on initial call setup and over the lifetime of a call. You could see the current mapping by issuing the CLI “pri show channels” command. If you need to track which B channel is currently assigned to the channel you need to monitor for the AMI “DAHDIChannel” events.


#3

Thanks for the explanation - that helps a lot.

Just as a follow-up: using the above examples, if the logs show lines like

[May  9 00:59:49] VERBOSE[21916] sig_pri.c:     -- Span 1: Channel 0/1 got hangup request, cause 16
[May  9 00:59:49] WARNING[13384] app_meetme.c: Unable to write frame to channel DAHDI/i1/23456789-14

would it be reasonable to assume that DAHDI/i1/23456789-14 was the channel that initiated/caused the hang-up?


#4

[May 9 00:59:49] VERBOSE[21916] sig_pri.c: – Span 1: Channel 0/1 got hangup request, cause 16
[May 9 00:59:49] WARNING[13384] app_meetme.c: Unable to write frame to channel DAHDI/i1/23456789-14

These two messages are output by different threads. (The thread id is in the square brackets after VERBOSE/WARNING.) Generally no you cannot associate the two messages as you have nothing to positively link them. The only way you could associate them would be the relative timing of the messages and if there are any other channels hanging up in the same time frame.


#5

OK. I rather suspected that the different threads might mean something like that. So we can only infer that information from the proximity of the events in time, and the fact that no other channel errors or hangup events happen nearby. But at least that gives us something to work with. Thanks very much for helping me out with understanding this part of the logging. Cheers.