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

[Gareth Palmer]

On Wed, 2008-07-09 at 10:50 +0200, Johansson Olle E wrote:
> 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.

There is an example of this in the patch, when you call multiple
channels using Dial() it will send an indication as to who answered.

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

The payload implementation in the patch is currently 0 or more tuples
of:

  <element id (1 byte)><element length (1 byte)><element data (element
length bytes)>

The implementation was somewhat inspired by the way IAX2 adds IE data to
it's packets.

> >
> >
> > 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
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> AstriCon 2008 - September 22 - 25 Phoenix, Arizona
> Register Now: http://www.astricon.net
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev