[asterisk-bugs] [Asterisk 0008824]: [patch] Remote (called) Party Identification - chan_sip & chan_skinny implementation

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=8824 
====================================================================== 
Reported By:                gareth
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   8824
Category:                   Channels/NewFeature
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.0-beta9 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 59043 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             2007-01-15 18:18 CST
Last Modified:              2008-10-08 13:34 CDT
====================================================================== 
Summary:                    [patch] Remote (called) Party Identification -
chan_sip & chan_skinny implementation
Description: 
Overview:

This patch provides the ability to rewrite the called party information
on
channel types that support it.  Implementations for the SIP (see note
http://bugs.digium.com/view.php?id=1)
and Skinny (see note http://bugs.digium.com/view.php?id=2) channels have been
provided.

Current features are:

1. Make changes whilst the call is progessing though the dial plan, ie:

   exten => s,1,RemoteParty("Voicemail" <123>)
   exten => s,n,Answer()
   exten => s,n,VoiceMailMain()

2. When using call pickup it will rewrite the caller information showing
the caller that was picked up.

3. When unparking a call it will show the caller*id of the parked call.

The ability to rewrite the calling party identification on semi-attended
transfer is planned but doesn't work yet.

Implementation:

Transmission of the remote party data is done using indications with a
new
subtype of AST_CONTROL_REMOTEPARTY, format of the data is:

  "name" <number>|presentation

Any channel specific code is kept in it's _indicate() handler. Once the
channel driver has received the indication it uses the method specific to
it; in the case of SIP it sends a 180/183 response if possible and with
Skinny it uses transmit_callinfo().

Note http://bugs.digium.com/view.php?id=1: The SIP implemenation is only able to
update the remote party
before the call has been answered as there is no re-invite support yet.

Note http://bugs.digium.com/view.php?id=2: I don't have any Skinny phones so no
testing has been done on
that part. 
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0006643 [patch] Implement Called Party Identifi...
has duplicate       0008990 Transfer and Variables
related to          0011036 Crush at unknown place
related to          0012511 transfer number of caller to callee whe...
related to          0012357 [patch] add called/connected/busy name ...
====================================================================== 

---------------------------------------------------------------------- 
 (0093372) putnopvut (administrator) - 2008-10-08 13:34
 http://bugs.digium.com/view.php?id=8824#c93372 
---------------------------------------------------------------------- 
gareth: Thanks for the updated patch. Since I wasn't a watcher on this
issue, I did not see that you had uploaded a new patch back on the 21st of
last month. Since then, I have also added P-Asserted-Identity support into
chan_sip. This is in the issue8824 branch now already, but there are a few
differences between our implementations that I'd like to point out and
potentially discuss since I very well may have misinterpreted what is
"supposed" to be done.

1. in get_rpid, if you read a Privacy header with the value "id" in it,
then you set the presentation to AST_PRES_PROHIB_USER_PASSED_SCREEN. I set
the presentation to AST_PRES_PROHIB_USER_NUMBER_NOT_SCREENED instead. I
imagine this is just a matter of preference since I don't know what actual
significance the screening portion of caller ID presentation has anyways.

2. in add_rpid, if the presentation indicates that the call is private,
then you add a "Privacy: id" header and also send the P-Asserted-Identity
header. I interpreted a private presentation to mean that the
P-Asserted-Identity header we send should not have the caller information
in it. So I set the P-Asserted-Identity to the common
"anonymous at anonymous.invalid" value.

3. in get_rpid, I also check for "anonymous at anonymous.invalid" and use
that as a way of marking the presentation as private as well.

4. The way the two of us implemented the ability to send
P-Asserted-Identity is different. The way I did it was to expand the
sendrpid option to take either "yes" "no" "rpid" or "pai" as values. This
allowed me to use space in the flags so that I didn't have to create a page
3 of flags.

I'm sorry I didn't notice this patch much earlier or else such conflicts
would not exist at all. But it does open up the floor as to how to handle
privacy with P-Asserted-Identity.

To dnehring: app_directed_pickup isn't compiling because it needs to
#include "asterisk/callerid.h" in order to have the proper constants
defined. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-08 13:34 putnopvut      Note Added: 0093372                          
======================================================================