On 17/07/09 17:20, Danny Nicholas wrote: > Not that this will really help, but in my CDR, I get this find of format > Xxx incoming_number s context caller_id incoming_tech/line > target_tech/line function command time1 time2 time3. It seems that > you could look to the target_tech/line for the information you need.
Yeah I know what you mean. That is the "destination channel" which does contain something like SIP/101-9u1exdo8, even though the "Destination" contains just "s". I am working on some CRM integration code and really don't want to have to parse this stuff if I can help it. Some of our extensions will/could be on Zap/ or IAX/context/blah-hsdjgdjf-. It get's really hard to to try and deal with all the possibilities reliably. IMHO, the "Destination" field *should* contain simply the number of the destination ext. of the call; as it rightly does when digits are actually dialled by the caller. Why it doesn't when the call is generated by the dialplan IVR is just plain inconsistent. Alan > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Alan Lord > (News) > Sent: Friday, July 17, 2009 11:10 AM > To: [email protected] > Subject: Re: [asterisk-users] How do I create an IVR/Dial Group that > worksproperly? > > On 17/07/09 16:30, David Backeberg wrote: >> On Fri, Jul 17, 2009 at 4:22 AM, Alan Lord (News)<[email protected]> > wrote: >>> * Caller arrives at our main number >>> * Caller is greeted and then told they can enter an extension number, if >>> known, or wait and their call will be connected to an available rep. >>> * The IVR then dials a group of extensions (if the caller didn't enter >>> one obviously). >>> * Someone picks up the call and the connection is established and logged. >>> >>> Now, I have all of this working apart from the last piece. >>> >>> My IVR rings various extensions and I can pick up the call just fine. >>> But my problem is that the data asterisk records regarding the call is >>> wrong. >>> >>> It correctly identifies the CallerID, but it always records the >>> destination as "s". Not the extension of, for example my SIP phone (101). >> >> Somewhere earlier, you do the very first answer. At that point, you should > add a >> NoOp(${EXTEN}) >> Set(WHATIREALLYWANTEDINSTEAD=${EXTEN} >> >> and then keep popping out the >> ${WHATIREALLYWANTEDINSTEAD} >> value wherever you wanted the original extension before you started >> jumping all over the place in your dialplan. > > I don't really understand what you are saying here. Sorry :-( > > When the call first hits * (over an IAX trunk), it gets put into the IVR > [tolc_menu} at s,1 and the extension in the IAX context is the incoming > number. So there isn't an EXTEN at this stage. And I do not know > WHATIREALLYWANTEDINSTEAD because: > > a) the caller has not yet dialled an extension, or > b) I do not know which of us will answer the call. > >> As you maybe guessed by now, EXTEN is the immediate, right now >> extension, and if you make jumps, it will update as you jump around. > > Well, yes I understand that. So WTF does the extension not *jump* to 101 > or 202 (or whatever the destination is) when a real person finally > answers the call? > >> And then if you want the WHATIREALLYWANTEDINSTEAD value into your CDR, >> see the earlier post this week regarding setting arbitrary values into >> your CDR. > > It can't be this hard surely? > > We can't be the only firm in the world that doesn't do DDI and just has > one incoming number? > > As I said, if while the caller is in the IVR they dial 101 it works > properly. But some will not know our extension numbers so the IVR rings > several handsets and the first one to pick up gets the call. Why isn't > that information set as the destination EXTEN? > > I am beginning to think this is probably a bug. It has nothing to do > with Macros. I have tried without. > > Alan > >>> [tolc_menu] ; Welcome and information to callers >>> exten => s,1,Answer() >>> exten => s,n,Wait(2) >>> exten => s,n,Background(welcome-to-tolc) ; Say Hello >>> exten => s,n,Wait(1) >>> exten => s,n(tryagain),Background(enter-ext-of-person&or) ; Enter >>> extension number if known, or >>> exten => s,n,Background(pls-stay-on-line) ; Trying to connect... >>> exten => s,n,WaitExten(5) >>> exten => s,n,Macro(belllord,${ALANL}&${ALANB},303) >>> >>> exten => _10[1-5],1,Macro(call_extension,SIP/${EXTEN}) >>> >>> exten => _20[1-5],1,Macro(call_extension,IAX2/alanb/${EXTEN}) >>> >>> >>> The Vars ALANL and ALANB are: >>> ALANL=SIP/101 >>> ALANB=IAX2/alanb/202 >>> >>> >>> Here is the Macro belllord: >>> >>> [macro-belllord] >>> exten => s,1,Dial(${ARG1},20,t) >>> exten => s,n,Goto(s-${DIALSTATUS},1) >>> >>> exten => s-NOANSWER,1,Voicemail(${ar...@business,u) ; business is the >>> voicemail context, ${ARG2} is the mailbox number to dial >>> exten => s-NOANSWER,n,Hangup() >>> >>> exten => s-BUSY,1,Voicemail(${ar...@business,b) >>> exten => s-BUSY,n,Hangup() >>> >>> exten => _s-.,1,Goto(s-NOANSWER,1) >>> >>> >>> Here is the call-extension Macro: >>> >>> [macro-call_extension] >>> exten => s,1,Dial(${ARG1},20,t) ; Ring channel for up to 20s >>> exten => s,n,Goto(s-${DIALSTATUS},1) ; Go to either no answer or busy. >>> >>> exten => s-NOANSWER,1,Voicemail(${macro_ext...@garden_house,u) >>> >>> exten => s-BUSY,1,Voicemail(${macro_ext...@garden_house,b) >>> >>> exten => _s-.,1,Goto(s-NOANSWER,1) >>> >>> >>> >>> _______________________________________________ >>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>> >>> asterisk-users mailing list >>> To UNSUBSCRIBE or update options visit: >>> http://lists.digium.com/mailman/listinfo/asterisk-users >>> >> >> _______________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >> > > > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
