This page was written by Thomas Arimont of DATUS AG, Germany
Minor editing by Matt Jordan
Private Representation of Caller, Connected and Redirecting Party IDs
Feature implemented in Asterisk 11 by Thomas Arimont, DATUS AG, Germany

Overview

Asterisk already offers a lot of techniques to set and modify party names and numbers of different kinds. There are a number of dialplan functions - CALLERID, CONNECTEDLINE, REDIRECTING - that allow you to read and write a wide range of parameters for Asterisk. However, prior to Asterisk 11 it is quite difficult to modify a party number or name which can only be seen by exactly one particular instantiated channel resp. subscriber.

One example where a modified party number or name on one channel is spread over several channels are supplementary services like call transfer or pickup. To implement these features Asterisk internally copies (has to copy) Caller and Connected IDs from one channel to another.

Another example are extension subscriptions. The monitoring entities (watchers) are notified of state changes and - if desired - of party numbers or names which represent the involved call parties. Also in this case the provided party numbers or names are (have to be) taken from the Caller or Connected ID of the corresponding Asterisk channels.

One major feature where a private representation of party names is essentially needed, i.e., where a party name shall exclusively be signalled to only one particular user, is a private user-specific name resolution for party numbers. A lookup in a private destination-dependent telephone book shall provide party names which cannot be seen by any other user at any time.

Asterisk 11 now provides a mechanism by which private party identification information can be signalled to a particular device.

This feature is supported in the following channel drivers:

• SIP (chan_sip)
• mISDN (chan_misdn)
• PRI (chan_dahdi).

Feature Description

This feature defines additional private number and name elements for Caller ID, Connected ID, and Redirecting IDs inside Asterisk channels. The private number and private name elements can be read or set by the user using the respective Asterisk dialplan functions for those elements.

When a channel initiates a call, if it receives an internal connected line update event or an internal redirecting update event, it first checks if there is a valid Connected ID or Redirecting ID private name or number element present. If this is the case it uses this private representation for protocol signalling. If there is no valid private name or number present, then the valid 'regular' non-private name or number element is used instead.

Automatic Invalidation of Private Information

Once a private name or number on a channel is set and (implicitly) made valid, it is generally used for any further protocol signalling until it is rewritten or invalidated. To simplify the invalidation of private IDs all internally generated connected/redirecting update events and also all connected/redirecting update events which are generated by channels – receiving regarding protocol information - automatically trigger the invalidation of private IDs.

This explicitly takes place when one of the following conditions occurs:

• An internal Asterisk channel masquerading is processed (blind and attended transfers, pickup, parking)
• Extra connected line update events are internally generated during a SIP specific attended transfer
• Extra connected line update events are generated during a call pickup
• Connected line update events are generated in the SIP channel due to receipt of corresponding SIP protocol elements (remote party id header, p-asserted-identity header)
• Redirecting update events are generated in the SIP channel due to receipt of corresponding SIP protocol elements (diversion header)
• Connected line update events are generated in the DAHDI/PRI or mISDN channel due to receipt of corresponding ISDN protocol elements (display IE, connected number IE)
• Redirecting update events are generated in the DAHDI/PRI or mISDN channel due to receipt of corresponding ISDN protocol elements (redirecting/redirection IE, divleginfo facility IE)

Manual Invalidation of Private Information

In some cases the invalidation of private IDs cannot be done automatically and therefore it is a job the user has to do by applying appropriate and explicit dialplan commands. This is done by setting the priv-nam-valid item to 0.

As an example of where manual invalidation is necessary, consider the case when a private connected name is set towards a particular caller, and after this a blind transfer is executed by the callee to another target where only a 'regular' non-private connected name is set. Because of the priority of the still valid private connected name id on the caller's channel the 'regular' non-private connected name will not become visible to the caller. To solve this issue the user should in general explicitly invalidate the private connected name/number when setting a 'regular' non-private connected name/number.

Recommended Mechanism for Setting Private Identity

The setting of private calling party numbers or names shall be done by using the Pre-Dial CALLEE subroutine (Dial application option 'b'). The setting of private REDIRECTING ids towards the redirected-to party shall also be done using the Pre-Dial CALLEE subroutine. Since the setting of the private CALLERID in the Pre-Dial CALLEE subroutine has to be made by using the CONNECTEDLINE setter function, the setter function for CALLERID is not used at all in this scenario.

The setting of any kind of private connected numbers or names as well as private REDIRECTING IDs towards a caller shall be done by using the system subroutines
CONNECTED_LINE_SEND_SUB resp. REDIRECTING_SEND_SUB.

If not using the private number and name representation feature at all, i.e., if using only the 'regular' CALLERID, CONNECTEDLINE and REDIRECTING related function datatypes, the current characteristics of Asterisk's manipulation of party identification is not affected by the new extended functionality.

Dialplan Manipulation

To grant access to the private name and number representation out of the asterisk dialplan, the read and write functions of the three Asterisk defined functions CALLERID, CONNECTEDLINE and REDIRECTING are extended by the following datatypes. The formats of these additional datatypes are equivalent to the corresponding regular 'non-private' already existing datatypes:

CALLERID:

• priv-all
• priv-name
• priv-name-valid
• priv-name-charset
• priv-name-pres
• priv-num
• priv-num-valid
• priv-num-plan
• priv-num-pres
• priv-subaddr
• priv-subaddr-valid
• priv-subaddr-type
• priv-subaddr-odd
• priv-tag

CONNECTEDLINE:

• priv-name
• priv-name-valid
• priv-name-pres
• priv-name-charset
• priv-num
• priv-num-valid
• priv-num-pres
• priv-num-plan
• priv-subaddr
• priv-subaddr-valid
• priv-subaddr-type
• priv-subaddr-odd
• priv-tag

REDIRECTING:

• priv-orig-name
• priv-orig-name-valid
• priv-orig-name-pres
• priv-orig-name-charset
• priv-orig-num
• priv-orig-num-valid
• priv-orig-num-pres
• priv-orig-num-plan
• priv-orig-subaddr
• priv-orig-subaddr-valid
• priv-orig-subaddr-type
• priv-orig-subaddr-odd
• priv-orig-tag
• priv-from-name
• priv-from-name-valid
• priv-from-name-pres
• priv-from-name-charset
• priv-from-num
• priv-from-num-valid
• priv-from-num-pres
• priv-from-num-plan
• priv-from-subaddr
• priv-from-subaddr-valid
• priv-from-subaddr-type
• priv-from-subaddr-odd
• priv-from-tag
• priv-to-name
• priv-to-name-valid
• priv-to-name-pres
• priv-to-name-charset
• priv-to-num
• priv-to-num-valid
• priv-to-num-pres
• priv-to-num-plan
• priv-to-subaddr
• priv-to-subaddr-valid
• priv-to-subaddr-type
• priv-to-subaddr-odd
• priv-to-tag

Example Dialplans

Setting the private calling name

Setting the private connected name