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

[Kaloyan Kovachev]

There is a long waiting review at https://reviewboard.asterisk.org/r/1676/
which also adds connected and redirecting party ids to sig_ss7 and either
this patch should cover sig_ss7 too or the one at 1676 should be updated
(once again) to include the private representation too.

https://reviewboard.asterisk.org/r/2025 (and probably others) also touches
functionality which is added/extended in 1676 and it is quite difficult to
follow all the changes for such a big change (patch).

Please review and commit 1676 or it may end up outdated even before it is
reviewed, as it is a pain to keep it fresh and to follow all the changes at
different parts of the functionality which just have not existed before.

On Wed, 11 Jul 2012 14:26:06 -0000, "Guenther Kelleter"
<reviewboard at asterisk.org> wrote:
> -----------------------------------------------------------
> 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