[asterisk-dev] Another dial-option, catching hangup of caller party

[Johan Wilfer]

2008/2/8, Atis Lezdins <atis at iq-labs.net>:
>
> On 2/8/08, Johan Wilfer <johan at wilfer.se> wrote:
> > Thanks! :-)
> >
> > I would encourage those who understand Asterisk better to look at the
> patch
> > if I have overseen something. It works for me but app_dial is very
> complex.
>
> I wonder will this work with queues. I suspect that queue will try to
> terminate created channel, or at least update some log.


I haven't tried this. However it was my intent to use this in a local
channel that is called by a queue,
to get rid of my two-people-conferences I use right now to get the same
behaviour.
My guess is that it would work just fine, because I use the G-flag in this
way right now.
And I implemented it the same way, but with only one channel instead of two.


Btw, how does CDRs look for this?


You got two cdr-records. The first is just like a normal Dial(). The second
for the time the called
part is "on it's own" until the call ends. I think this is very reasonable.

/Johan

Regards,
> Atis
>
> >
> > Greetings
> > Johan
> >
> > 2008/2/8, Steve Totaro <stotaro at totarotechnologies.com>:
> > > Johan,
> > >
> > > I just wanted to say good job.
> > >
> > > You are one of the reasons why Asterisk and open source software is so
> > > powerful.
> > >
> > > You wanted Asterisk to do something that it did not.  You posted about
> > > it, no replies, so you made it happen and gave back in a weeks time.
> > >
> > > Bravo.
> > >
> > > Thanks,
> > > Steve Totaro
> > >
> > > On Feb 8, 2008 3:21 AM, Johan Wilfer <johan at wilfer.se> wrote:
> > > > I've implemented this feature and posted a patch on bug #0011954
> > > > "When the caller hangs up - transfer the called party to the
> specified
> > > > context and extension provided by this option"
> > > >
> > > > Please give it a try, and comment..
> > > >
> > > > Greetings Johan
> > > >
> > > >
> > > > Johan Wilfer wrote:
> > > > > Johan Wilfer wrote:
> > > > >> I don't know what to call this feature, but after playing around
> with
> > > > >> res_features and application maps I come to think about this...
> > > > >> When dialing someone with Dial() the call can survive the called
> > > > >> party hanging up - using the g-flag.
> > > > >> Sometimes it's useful to do the opposite, but I'm not sure how or
> > > > >> where to implement this.
> > > > >>
> > > > >> I can think of having a X()-option similar to G() that transfer
> the
> > > > >> called party to this extension after the caller hangs up.
> > > > >> One other method is to have a special extension taking care of
> this,
> > > > >> like h, s and so on.
> > > > >>
> > > > >> I think I like the first method best.
> > > > >>
> > > > >> I could use this together with application maps and the bridge
> app to
> > > > >> eliminate my meetme rooms for this purpose. However I must be
> > > > >> able to intercept either one hanging up to give feedback to the
> > other.
> > > > >>
> > > > >> Ideas? If you could give me some pointers where to look for
> > > > >> implementing this I would be happy,
> > > > >> as I don't know my way in the source nearly as good as you guys
> do...
> > > > >>
> > > > >> Greetings
> > > > >> Johan
> > > > >>
> > > > > Anyone?
> > > > > Basically I don't want to hang up on the called party, just
> because
> > > > > the caller slammed the phone. I would like to be able to continue
> > > > > dialplan execution of the called party.
> > > > >
> > > > > You can do this right now by breaking the bridged call and put
> them in
> > > > > a conference. You can also use flags to the Dial application to do
> the
> > > > > opposite - let the calling party (he who executed Dial) continue
> if
> > > > > the called party hangs up. I would like to do it the other way
> > around..
> > > > >
> > > > > How do you like to see this implemented? Another option for dial?
> > > > > Something else?
> > > > >
> > > > > /Johan
> > > >
> > > >
> > > > _______________________________________________
> > > > --Bandwidth and Colocation Provided by http://www.api-digital.com--
> > > >
> > > > 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--
> > >
> > > 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--
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
>
> --
> Atis Lezdins
> VoIP Developer,
> IQ Labs Inc.
> atis at iq-labs.net
> Skype: atis.lezdins
> Cell Phone: +371 28806004
> Work phone: +1 800 7502835
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080208/1bf98128/attachment.htm