Skip to content
Snippets Groups Projects
  • Richard Mudgett's avatar
    fb623889
    Add private representation of caller, connected and redirecting party ids. · fb623889
    Richard Mudgett authored
    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
    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 state changes 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 be 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
    party id elements for caller id, connected id and redirecting ids inside
    Asterisk channels.
    
    The private party id elements can be read or set by the user using
    Asterisk dialplan functions.
    
    When a technology channel is initiating a call, receives an internal
    connected-line update event, or receives an internal redirecting update
    event, it merges the corresponding public id with the private id to create
    an effective party id.  The effective party id is then used for protocol
    signaling.
    
    The channel technologies which initially support the private id
    representation with this patch 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 simplify 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 party id representation feature at all, i.e.  if
    using only the 'regular' caller-id, 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 CALLERID, CONNECTEDLINE and REDIRECTING dialplan
    functions are extended by the following data types.  The formats of these
    data types are equal to the corresponding regular 'non-private' already
    existing data types:
    
    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
    
    Reported by: Thomas Arimont
    
    Review: https://reviewboard.asterisk.org/r/2030/
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
    fb623889
    History
    Add private representation of caller, connected and redirecting party ids.
    Richard Mudgett authored
    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
    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 state changes 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 be 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
    party id elements for caller id, connected id and redirecting ids inside
    Asterisk channels.
    
    The private party id elements can be read or set by the user using
    Asterisk dialplan functions.
    
    When a technology channel is initiating a call, receives an internal
    connected-line update event, or receives an internal redirecting update
    event, it merges the corresponding public id with the private id to create
    an effective party id.  The effective party id is then used for protocol
    signaling.
    
    The channel technologies which initially support the private id
    representation with this patch 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 simplify 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 party id representation feature at all, i.e.  if
    using only the 'regular' caller-id, 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 CALLERID, CONNECTEDLINE and REDIRECTING dialplan
    functions are extended by the following data types.  The formats of these
    data types are equal to the corresponding regular 'non-private' already
    existing data types:
    
    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
    
    Reported by: Thomas Arimont
    
    Review: https://reviewboard.asterisk.org/r/2030/
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371120 65c4cc65-6c06-0410-ace0-fbb531ad65f3