[asterisk-dev] [Code Review] Private representation of caller, connected and redirecting party ids

Guenther Kelleter reviewboard at asterisk.org
Wed Jul 11 09:26:06 CDT 2012


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2030/
-----------------------------------------------------------

(Updated July 11, 2012, 9:26 a.m.)


Review request for Asterisk Developers, Matt Jordan and Thomas Arimont.


Summary
-------

(Info for Matt Jordan: I wanted to post this on Thomas Arimont's account because he implemented this, but I cannot login with the login data you sent him, so I'm posting it on my account.)

This patch adds the feature "Private representation of caller, connected and redirecting party ids", as previously discussed with us (DATUS) and Digium.

1. Feature motivation
Until now it is quite difficult to modify a party number or name which can only be seen by exactly one particular instantiated technology 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 caller and connected ids from one channel to another.
Another example are extension subscriptions. The monitoring entities (watchers) are notified   of statechanges and - if desired - of party numbers or names which represent the involving call parties. 
One major feature where a private representation of party names is essentially needed, i.e. where a party name shall exclusively signaled 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.

2. Feature Description
This feature comes along with the implementation of 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 asterisk dialplan functions.

When a technology channel is initiating a call, receives an internal connectedline update event or receives 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 signaling .

-->The channel technologies which initially do support the private id representation are SIP (chan_sip), mISDN (chan_misdn) and PRI (chan_dahdi).<--

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

--> If not using the private number and name representation feature at all, i.e. if using only the 'regular' callerid, connected and redirecting related functions, the current characteristic of asterisk  is not affected by the new extended functionality. <--

3. User interface Description
To grant access to the private name and number representation from the asterisk dialplan, the read and write functions of the variables CALLERID, CONNECTEDLINE and REDIRECTING are extended by the following datatypes. The formats of these datatypes are equal to the corresponding regular 'non-private' already existing datatypes:

CALLERID:
privnum privnum-valid privnum-pres privnum-plan
privname privname-valid privname-pres privname-charset

CONNECTEDLINE:
privnum privnum-valid privnum-pres privnum-plan
privname privname-valid privname-pres privname-charset

REDIRECTING:
orig-privnum orig-privnum-valid orig-privnum-pres orig-privnum-plan
orig-privname orig-privname-valid orig-privname-pres orig-privname-charset
from-privnum from-privnum-valid from-privnum-pres from-privnum-plan 
from-privname from-privname-valid from-privname-pres from-privname-charset
to-privnum to-privnum-valid to-privnum-pres to-privnum-plan
to-privname to-privname-valid to-privname-pres to-privname-charset


Diffs
-----

  /trunk/channels/chan_misdn.c 369918 
  /trunk/channels/chan_sip.c 369918 
  /trunk/channels/sig_pri.c 369918 
  /trunk/funcs/func_callerid.c 369918 
  /trunk/include/asterisk/channel.h 369918 
  /trunk/main/channel.c 369918 
  /trunk/main/features.c 369918 

Diff: https://reviewboard.asterisk.org/r/2030/diff


Testing
-------


Thanks,

Guenther

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120711/8a7d5faf/attachment.htm>


More information about the asterisk-dev mailing list