[asterisk-dev] Caller/connected line ID updates * I NEED YOUR INPUT!!!
Matt Florell
astmattf at gmail.com
Fri Jul 4 15:25:01 CDT 2008
On 7/4/08, Johansson Olle E <oej at edvina.net> wrote:
>
> 4 jul 2008 kl. 12.01 skrev Matt Florell:
>
> > 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.
>
> You don't have origin of caller ID there. Would that be the channel
> name,
> like SIP/olle-123814848 ?
Yes, standard SIP callerID would fall within the *name, the number is
mostly for interaction with PBX and PSTN numbering where alphabetic
characters are not used to dial by.
> >
> >
> > 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).
>
> Please explain a bit more about the third one, xfer, which is new to me.
> Is this for not overwriting the original caller ID?
>
> How would this apply to a bridged call? Would each channel have up
> to three caller ID structures, some of them copies of each other?
xfer* would be for three-party calls where you would have ring-back or
other potential uses for a third callerID. It is not that common of a
need, but I have had call center and business PBX applications where
something like this would have greatly simplified what I was trying to
do had it been built in to Asterisk.
> >
> >
> > 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.
>
> Hmm. I think this is outside of this topic, but see what you mean.
> This is
> needed, especially since we're moving towards a bit more distributed
> architecture (see Russell's work).
Yes, I've been trying to sneak this one in ever since I wrote a
whitepaper on it back in 2003 :)
Something like this would allow third party applications to much
easily track calls in the system.
> >
> >
> > With all of these containers of data, just about any kind of CallerID
> > could be served no matter the technology or application.
>
>
> Do you have any more practical examples outside of those that I
> have in my document?
I have a lot of little AGI scripts and creative dialplan hacking that
I have had to use to make up for the limited call tracking and
callerID features in Asterisk. Many of these involve Local/ channels
and meetme where by design there are clearly a lot of issues with
CallerID.
Here's one example, a customer calls in to a sales agent, the sales
agent conferences in a verification agent, and then they have to call
a third party recording service with the callerID of the sales agent,
but the call still needs to be able to be transferred with the
original customer callerid depending on how the call is transferred.
Very confusing, but a real example. I ended up having to write AGI
scripts to deal with this one, and it is somewhat restrictive in what
it can do because of the limitations in Asterisk and the data that the
AGIs get.
One other odd example I can think of is on an NI2 PRI, doing 2BCT and
other more advanceed PRI features where Asterisk should be able to
track calls by different call IDs after they have physically left the
circuit connected to the Asterisk PBX, but the carrier is still
sending signals over the D channel and Asterisk has no idea what to do
with these signals. This is more related to the example in the link
you posted, but it is related in general to Asterisk and call ID
tracking.
I should probably explain that most of my work involves interfacing
VOIP and the PSTN in various ways for companies mostly in call center
and large corporate PBX applications. Some of these applications have
some strange requirements, and I can usually make something work
within the existing Asterisk framework using dialplan magic and AGI
scripts, but having more robust callerID and call tracking options
would make advanced applications like this much easier.
I hope that all helps and I hope I'm not too far off topic.
Thanks,
MATT---
> Thank you for your feedback, very much appreciated!
>
> /Olle
>
> >
> >
> >
> > I hope this helps,
> >
> > MATT---
> >
> >
> > On 7/4/08, Johansson Olle E <oej at edvina.net> wrote:
> >> Friends,
> >>
> >> We need to implement a way to update caller and callee identies
> >> during
> >> a bridged call
> >> or a one-way call in Asterisk. Several people in the Asterisk
> >> community has been working
> >> on this for a long time and we need to make a few design decisions
> >> and
> >> move forward.
> >>
> >> To update a caller ID, we need a new AST_CONTROL message with or
> >> without payload.
> >> The channel driver needs to be able to send and or receive this
> >> message and do what
> >> they can do with it.
> >>
> >> We also need to have a way to configure whether this should be done,
> >> per device
> >> and per call. Do we want to send the phone number and name of someone
> >> in a
> >> call center that answers a call? If a secretary answer's the boss
> >> phone by call pickup,
> >> do we send the secretary's caller ID?
> >>
> >> 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
> >>
> >> I know that Connected line IDs are supported in EuroISDN. Any
> >> information about these
> >> functions that I can add in the document is appreciated.
> >>
> >> Please take time to review this document, provide additional input
> >> and
> >> we can
> >> summarize around next week (after the fourth of July weekend in the
> >> States).
> >>
> >> This will be integrated into svn trunk, since it's a massive change
> >> to
> >> many
> >> modules as well as the core of Asterisk. It won't be part of 1.6.0,
> >> but I'm sure we can provide a
> >> backport for that branch too. Let's not focus on that in this
> >> discussion.
> >>
> >> For those of you in the States: Have a nice Fourth of July weekend!
> >> For the rest of you: Have a nice summer weekend!
> >>
> >> /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
> >>
> >
> > _______________________________________________
> > --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
>
>
> ---
>
> * Olle E. Johansson - oej at webway.se
> * http://www.webway.se, Phone +46 8 594 788 10
>
>
>
>
>
>
> _______________________________________________
> --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
>
More information about the asterisk-dev
mailing list