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

[Johansson Olle E]

8 jul 2008 kl. 15.48 skrev 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.
>
I'll add that.

>> 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
...and he lost his train of thought. I will rephrase.
>
>
>> 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.
The structure is not used as a payload, I think  you misunderstand.
But we need to use your proposed format for the payload.

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

/O