[asterisk-dev] Caller/connected line ID updates * I NEED YOUR INPUT!!!

[Russell Bryant]

Johansson Olle E wrote:
> I've tried to compile my thoughts and input from various documents as  
> well as
> a review of "gareth"'s work in the bug tracker.
> http://svn.digium.com/view/asterisk/team/oej/calleridupdate/README-calleridupdate.txt?view=co

 From the document ...

> Updating caller IDs during a call in Asterisk
> -----------------------------------------------------
> There are multiple situations where a caller ID for connected line or 
> caller can happen in Asterisk calls.

I would add shared line appearances here, as well.  For example, on 
incoming calls on a shared line, Asterisk has no clue what the connected 
party information is going to be until one of the phones actually 
answers.  The situation is similar for a list of different call 
scenarios with that code.

> 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.

I would agree with this approach.  This is surely the most logical way 
to do it.

I wouldn't say "across the bridge", though.  There are situations where

> 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.
> 
> +/* \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 */
> +};

Actually, I don't think either structure is appropriate.  If this data 
was _only_ staying in one instance of Asterisk, then I would agree that 
using the existing ast_callerid struct would be the best choice.

However, ast_frames are sent directly over the network via IAX2.  Having 
a payload of pointers becomes useless at that point.  You can't even 
have the pointers be relative offsets instead of addresses.  The control 
frame payload must be the exactly the same regardless of the system (and 
  how big a pointer is on that system).

I'm afraid that we will need to define a new struct for this.  We could 
basically copy ast_callerid (which is the same as ast_connectedline), 
except define all members as uint32_t.  For the fields that are actually 
strings, the value would represent an offset for where to find the data 
for that field.

Simplified demonstration ...

const char *name = "my name";
const char *num = "1234";

struct cid {
    uint32_t name;
    uint32_t num
    uint32_t pres;
} *cid;

cid = malloc(sizeof(*cid) + strlen(name) + strlen(num) + 2);

cid->pres = AST_PRES_NUMBER_NOT_AVAILABLE;

cid->name = sizeof(*cid);

cid->num = sizeof(*cid) + strlen(name) + 1;

> 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.

And thanks for pulling all of this documentation together.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.