Skip to content

Call Identifier Logging

Overview

Call ID Logging (which has nothing to do with caller ID) is a new feature of Asterisk 11 intended to help administrators and support givers to more quickly understand problems that occur during the course of calls. Channels are now bound to call identifiers which can be shared among a number of channels, threads, and other consumers.

Usage

No configuration is needed to take advantage of this feature. Asterisk 11 will simply apply an additional bracketed tag to all log messages generated by a thread with a call ID bound or to any log messages specially written to use call identifiers. For example:

  • Asterisk receives a request for a non existent extension from SIP/gold
  • The following log message is displayed:
[Oct 18 10:26:11] NOTICE[27538][C-00000000]: chan_sip.c:25107 handle_request_invite: Call from 'gold' (10.24.22.201:5060) to extension '645613' rejected because extension not found in context 'default'.

C-00000000 is the call identifier associated with this attempted call. All call identifiers are represented as C-XXXXXXXX where XXXXXXXX is an 8 digit hexadecimal value much like what you will see with SIP and local channel names.

Aside from log messages, call identifiers are also shown in the output for the 'core show channel ' command.

Transfers

Transfers can be a little tricky to follow with the call ID logging feature. As a general rule, an attended transfer will always result in a new call ID being made because a separate call must occur between the party that initiates the transfer and whatever extension is going to receive it. Once the attended transfer is completed, the channel that was transferred will use the Call ID created when the transferrer called the recipient.

Blind transfers are slightly more variable. If a SIP peer 'peer1' calls another SIP peer 'peer2' via the dial application and peer2 blind transfers peer1 elsewhere, the call ID will persist. If on the other hand, peer1 blind transfers peer2 at this point a new call ID will be created. When peer1 transfers peer2, peer2 has a new channel created which enters the PBX for the first time, so it creates a new call ID. When peer1 is transferred, it simply resumes running PBX, so the call is still considered the same call. By setting the debug level to 3 for the channel internal API (channel_internal_api.c), all call ID settings for every channel will be logged and this may be able to help when trying to keep track of calls through multiple transfers.