[svn-commits] oej: branch oej/calleridupdate r128416 - /team/oej/calleridupdate/

[SVN commits to the Digium repositories]

Author: oej
Date: Sun Jul  6 04:56:57 2008
New Revision: 128416

URL: http://svn.digium.com/view/asterisk?view=rev&rev=128416
Log:
Adding some thoughts from Matt.

Modified:
    team/oej/calleridupdate/README-calleridupdate.txt

Modified: team/oej/calleridupdate/README-calleridupdate.txt
URL: http://svn.digium.com/view/asterisk/team/oej/calleridupdate/README-calleridupdate.txt?view=diff&rev=128416&r1=128415&r2=128416
==============================================================================
--- team/oej/calleridupdate/README-calleridupdate.txt (original)
+++ team/oej/calleridupdate/README-calleridupdate.txt Sun Jul  6 04:56:57 2008
@@ -172,6 +172,74 @@
 privacy issues.
 
 ----
-Thanks to Gareth, Ramon Peek, Raj Jain and others who has given
+Thanks to Gareth, Ramon Peek, Raj Jain, Matt Florell and others who has given
 feedback on this document
 
+--------------------------------------------------------------------------------
+------------------------- Appendix: Additional Caller ID issues ----------------
+--------------------------------------------------------------------------------
+
+Outside of the scope of this, there are several Caller ID issues we need
+to handle, like
+- SIP uri handling
+- UTF 8 caller ID names (IAX2 & SIP)
+- Advanced handling (see below)
+
+I personally think these are a bit outside of the scope of this particular work,
+but we still need to have them in mind. Having one generic structure
+for caller IDs would make life easier. We should propably convert a lot
+of the calls that handle many parts of the structure to just pass around
+structure pointers, to allow for future expansion and changes.
+
+The question is: Should we have a linked list of caller ID structures
+and define an enum type indicating current role? 
+
+At the same time, we could add a field for call ID that you could set in dial, queue or originate.
+A field that would follow the call.
+
+- caller
+- callee (connected line)
+- extra	 (for third party apps)
+
+----- Response from Matt on asterisk-dev, for completeness of this document
+
+Hello,
+
+I've dealt a lot with CallerID-related issues with all sorts of
+carriers, clients and applications all over the world on many
+different types of systems. Here is a quick example of what I think
+Asterisk should do with callerID information in trunk.
+
+Each channel would have the following callerID containers:
+- inbound_caller_id_num
+- inbound_caller_id_name
+- inbound_ani
+- outbound_caller_id_num
+- outbound_caller_id_name
+- outbound_ani
+- xfer_caller_id_num
+- xfer_caller_id_name
+- xfer_ani
+- caller_id_active
+- call_label
+
+The callerIDs are separated by name, number and ANI as well as the
+end-point that the specific IDs came from.
+
+caller_id_active is the definition of the callerID name and number
+that would be used when an action like a Redirect takes place
+(inbound, outbound, xfer).
+
+call_label would be a definable label within Asterisk for a call that
+would follow a channel just like callerID currently does. This is
+present because channel variables do not always traverse all channel
+types and channel bridging and this field would allow more complete
+and much easier tracking of a channel by 3rd party applications.
+
+With all of these containers of data, just about any kind of CallerID
+could be served no matter the technology or application.
+
+
+I hope this helps,
+
+MATT---