[svn-commits] oej: branch oej/calleridupdate r127994 - /team/oej/calleridupdate/
SVN commits to the Digium repositories
svn-commits at lists.digium.com
Fri Jul 4 03:23:21 CDT 2008
Author: oej
Date: Fri Jul 4 03:23:20 2008
New Revision: 127994
URL: http://svn.digium.com/view/asterisk?view=rev&rev=127994
Log:
before adding code, adding a few thoughts to be discussed.
Added:
team/oej/calleridupdate/README-calleridupdate.txt (with props)
Added: team/oej/calleridupdate/README-calleridupdate.txt
URL: http://svn.digium.com/view/asterisk/team/oej/calleridupdate/README-calleridupdate.txt?view=auto&rev=127994
==============================================================================
--- team/oej/calleridupdate/README-calleridupdate.txt (added)
+++ team/oej/calleridupdate/README-calleridupdate.txt Fri Jul 4 03:23:20 2008
@@ -1,0 +1,162 @@
+Olle E. Johansson 2008-07-04
+Edvina.net, Sollentuna, Sweden
+
+
+
+Connected line ID updates in Asterisk
+-------------------------------------------------------------------
+(This document is work in progress. Please provide feedback)
+
+
+These are caused by various situations:
+
+- A SIP call transfer. The remote party changes.
+ The caller ID on the display of the callee no longer reflects the caller
+ and will need to change.
+ (The scenario is different if the callee does the transfer)
+
+- Connected line ID updates
+ We call (in e-mail terminology) an "alias", like a DID for a
+ sales group. The person that answer has a phone that sends
+ a connected line ID update.
+
+So regardless of the direction of the call, we can get
+connected line ID updates in both directions. In some
+protocols there are ways to update the phone devices.
+
+Updating caller IDs during a bridged call in Asterisk
+-----------------------------------------------------
+There are multiple situations where a caller ID for connected line or
+caller can happen in Asterisk calls.
+
+- A transfer happens in a remote SIP server (maybe Asterisk) and
+ this affects either caller or called ID
+- A transfer happens in ISDN, or someone answers a call and sends
+ connected line ID
+- A transfer happens in Asterisk and the caller is changed
+- A transfer happens in Asterisk and the callee changes
+- This could potentially be used for "topic" in Meetme's
+- Call pickup situations
+ We have an incoming call to a pickup extension and wants to
+ see the caller ID of the incoming call that rings on another
+ phone.
+(Any more?)
+
+Today, there's no internal signalling during a call that
+means "I have a new identity, please update your data".
+That means that channel drivers doesn't have any indication
+that it can forward to the phone to update the displays.
+
+Connected line ID updates in ISDN
+---------------------------------
+[Contributions to this section welcome!]
+
+Connected line ID updates in SIP
+---------------------------------
+In SIP, due to lack of standards, there's multiple
+ways.
+- A re-invite with changes of From/To header
+ This breaks compatibility with SIP/1.0
+- A remote party ID field with party=called
+ or party=caller during a re-invite,
+ UPDATE or even in ringing
+- Proprietary ways by phone manufacturers
+ (SNOM uses an INFO message)
+- There's a new RFC out that tries to set a standard
+ by using UPDATE (or re-Invites)
+ http://www.ietf.org/rfc/rfc4916.txt
+
+From the Abstract of this RFC:
+" This document provides a means for a Session Initiation Protocol
+ (SIP) User Agent (UA) that receives a dialog-forming request to
+ supply its identity to the peer UA by means of a request in the
+ reverse direction, and for that identity to be signed by an
+ Authentication Service. Because of retargeting of a dialog-forming
+ request (changing the value of the Request-URI), the UA that receives
+ it (the User Agent Server, UAS) can have a different identity from
+ that in the To header field. The same mechanism can be used to
+ indicate a change of identity during a dialog, e.g., because of some
+ action in the Public Switched Telephone Network (PSTN) behind a
+ gateway. This document normatively updates RFC 3261 (SIP)."
+
+Later on:
+" This solution involves changing the URI (not the tags) in the To and
+ From header fields of mid-dialog requests and their responses,
+ compared with the corresponding values in the dialog forming request
+ and response. "
+
+This RFC will cause issues with services that require that the From:
+user name and domain is that of the service (like Asterisk). The alternative
+way, using Remote-Party-ID will propably be used in these situations
+for a long time.
+
+The support of connected line updates in phones needs to be investigated,
+but there are at least a few implementations:
+- linksys/cisco supports Remote-Party-ID updates
+- SNOM supports INFO messages
+There needs to be a setting in sip.conf per device on how
+to send a caller ID update to the phone.
+
+Privacy concerns
+----------------
+There has to be settings involved here to control whether a
+connected line ID should be sent when someone answers a call.
+For queues of forked calls to a sales group, you might not
+want to reveal details of the person/device that takes the
+call.
+- Device settings: Never send connected line ID
+- Per-call settings (dial/queue): Filter out Connected line id
+
+Dialplan application needed
+---------------------------
+A dialplan application is also needed so taht one-way
+calls can change connected line ID.
+(Like setting a topic/name before connecting to a meetme).
+
+Current proposals
+-----------------
+There are a few patches in the bug tracker, one that has been
+worked quite a lot on by several members of the community.
+
+Bug 8824 - http://bugs.digium.com/view.php?id=8824
+has been the topic of a lot of testing and discussions,
+and a lot of good work. It's based on sending a new
+AST_CONTROL message with payload across the bridge.
+The payload contains the updated information to be
+sent out.
+The patch updates a lot of channel drivers, especially
+chan_sip where it massively changes the code for
+remote-party-id handling.
+
+It implements a new structure in channel.h that replicates the
+current caller ID structure. I think we could stay with one
+format instead of two very similar.
+This structure is added to ast_channel. For me this is
+questionnable. I would expect that the other call -the bridged
+call - is updated with this information and that we can get
+the information from there instead of storing it in the
+channel as a duplicate. If this works, we could also avoid
+sending data as a payload to the AST_CONTROL message.
+
++/* \brief Structure for all kinds of connected line ID indentifications.
++ * \note All string fields here are malloc'ed, so they need to be
++ * freed when the structure is deleted.
++ * Also, NULL and "" must be considered equivalent.
++ */
++struct ast_connectedline {
++ char *lid_dnid; /*!< Malloc'd Dialed Number Identifier */
++ char *lid_num; /*!< Malloc'd Line Number */
++ char *lid_name; /*!< Malloc'd Line Name */
++ char *lid_ani; /*!< Malloc'd ANI */
++ char *lid_rdnis; /*!< Malloc'd RDNIS */
++ int lid_pres; /*!< Line presentation/screening */
++ int lid_ani2; /*!< Line ANI 2 (Info digits) */
++ int lid_ton; /*!< Line Type of Number */
++ int lid_tns; /*!< Line Transit Network Select */
++};
+
+We can use a majority of the code in this bug report for the work
+needed. A big thank you to "gareth" for this work, and for being
+very responsive to input during the process.
+
+
Propchange: team/oej/calleridupdate/README-calleridupdate.txt
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: team/oej/calleridupdate/README-calleridupdate.txt
------------------------------------------------------------------------------
svn:keywords = "Author Date Id Revision"
Propchange: team/oej/calleridupdate/README-calleridupdate.txt
------------------------------------------------------------------------------
svn:mime-type = text/plain
More information about the svn-commits
mailing list