[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-13 23:29 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 ...
====================================================================== 

---------------------------------------------------------------------- 
 (0093576) gareth (reporter) - 2008-10-13 23:29
 http://bugs.digium.com/view.php?id=8824#c93576 
---------------------------------------------------------------------- 
1. PAI/RPID headers should only be used between peers in the same trust
domain so they must have passed a screen of some sort (RFC3325, Sections 1
& 5).

2. The behaviour you describe doesn't seem to match that shown in the RFC.
The intended use of PAI was to pass the actual callerid to a trusted peer
even when presentation was prohibited. The anonymous at anonymous.invalid
value is used, but in the From: header (RFC3325, Section 10).

3. You don't need to prohibit the presentation of an anonymous callerid as
it doesn't have any user identifiable information in it anymore.

4. As PAI is now supported the rpid part of sendrpid & trustrpid doesn't
make sense. I think it would be better to create new `identity' parameter
that accepts multiple comma separated values:

     identity=send,trust,rpid
     identity=yes,pai # yes is equivalent to send,trust

And if from-change from RFC4916 ever gets implemented:

     identity=trust,from

I will set aside some time later this week to produce an updated version
of the 1.6 patch. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-13 23:29 gareth         Note Added: 0093576                          
======================================================================