List Info

Thread: Re: Another dial-option, catching hangup of caller party
Re: Another dial-option, catching hangup of caller party
user name
 2008-02-08 08:22:56 

  


  

    

2008/2/8, Atis Lezdins < atisiq-labs.net">atisiq-labs.net>:

On 2/8/08, Johan Wilfer < johanwilfer.se">johanwilfer.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 < stotarototarotechnologies.com">stotarototarotechnologies.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

&gt; > it, no replies, so you made it happen and gave back in a weeks time.
> >
> > Bravo.
>; >
> > Thanks,
&gt; > Steve Totaro
>; >
> > On Feb 8, 2008 3:21 AM, Johan Wilfer < johanwilfer.se">johanwilfer.se> wrote:

&gt; > > I've implemented this feature and posted a patch on bug #0011954
&gt; > > "When the caller hangs up - transfer the called party to the specified
> > > context and extension provided by this option&quot;

> > >
> > > Please give it a try, and comment..
> > >
> > > Greetings Johan
> > >
> > >
> > > Johan Wilfer wrote:
>; > > > Johan Wilfer wrote:

&gt; > > >> 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...
&gt; > > >> When dialing someone with Dial() the call can survive the called

&gt; > > >> party hanging up - using the g-flag.
&gt; > > >> 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,

&gt; > > >> like h, s and so on.
> > > >>
&gt; > > >> I think I like the first method best.
> > > >>
&gt; > > >> 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...

&gt; > > >>
&gt; > > >> Greetings
> > > >> Johan
> > > >>
&gt; > > > Anyone?
&gt; > > > 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
&gt; > > > 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..
&gt; > > >
> > > > How do you like to see this implemented? Another option for dial?
> > > > Something else?
> > > >
> > > > /Johan

&gt; > >
> > >
> > > _______________________________________________
> > > --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--
&gt; >

>; > 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--
&gt;
> asterisk-dev mailing list

>; To UNSUBSCRIBE or update options visit:
>; &nbsp; &nbsp;http://lists.digium.com/mailman/listinfo/asterisk-dev
>


--
Atis Lezdins
VoIP Developer,

IQ Labs Inc.
 atisiq-labs.net">atisiq-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:
&nbsp;  http://lists.digium.com/mailman/listinfo/asterisk-dev





  

  
  
   
     
    

  

    Re:  Another dial-option, catching
hangup of caller party
  


  

     user name

     2008-02-08 08:51:53
  


  

    
On 2/8/08, Johan Wilfer <johanwilfer.se> wrote:
>
>
> 2008/2/8, Atis Lezdins <atisiq-labs.net>:
> > On 2/8/08, Johan Wilfer <johanwilfer.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.

I also meant the local channels that issue Dial. However i
think,
there's the difference, because call is bridged trough
queue, so queue
would first get notification when caller hanged up. If you
intend to
use it in queue, can you give us an update when you'll have
it
working?

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

Good, that's reasonable.

Regards,
Atis
>
> /Johan
>
> > Regards,
> > Atis
> >
> > >
> > > Greetings
> > > Johan
> > >
> > > 2008/2/8, Steve Totaro <stotarototarotechnologies.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
<johanwilfer.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.c
om--
> > > > >
> > > > > 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.c
om--
> > > >
> > > > 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.c
om--
> > >
> > > 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.
> > atisiq-labs.net
> > Skype: atis.lezdins
> > Cell Phone: +371 28806004
> > Work phone: +1 800 7502835
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by http://www.api-digital.c
om--
> >
> > 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.c
om--
>
> 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.
atisiq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Work phone: +1 800 7502835

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev



  


  

    
  

  
  
   
     
    






 [1-2]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )