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

Johan Wilfer johan at wilfer.se
Mon Feb 11 10:13:56 CST 2008


Atis Lezdins wrote:
> On 2/8/08, Johan Wilfer <johan at wilfer.se> wrote:
>   
>> 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.
>>     
>
> 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?
>   
When dial() is called directly outside of queue, it works.
In the queue it only works if /n is appended to the local channel, 
otherwise it doesn't.

Why this is so and what it means I don't really understand. When I use 
the G-flag I don't need to
specify /n after the local channel.


I've done some tests and I'm very satisfied with the results. I've 
encounterd one strange side effect however:
I got this message when using the new flag:
[Feb 11 16:30:44] NOTICE[22370]: app_dial.c:1845 dial_exec_full: PEER 
context: incoming; PEER exten: ;  PEER priority: 1

The line's in question are these:
--------------------------------------------------------------
1844:                if (ast_test_flag64(&opts, OPT_PEER_H)) {
1845:                        ast_log(LOG_NOTICE, "PEER context: %s; PEER 
exten: %s;  PEER priority: %d\n",
1846:                                peer->context, peer->exten, 
peer->priority);
1847:                }
--------------------------------------------------------------

 From my patch:
--------------------------------------------------------------
@@ -262,12 +264,13 @@
     OPT_CALLEE_GOSUB =      (1 << 28),
     OPT_CALLEE_MIXMONITOR = (1 << 29),
     OPT_CALLER_MIXMONITOR = (1 << 30),
+    OPT_CALLEE_GO_ON =      (1 << 31),
 };
 
-#define DIAL_STILLGOING            (1 << 31)
-#define DIAL_NOFORWARDHTML        ((uint64_t)1 << 32) /* flags are now 
64 bits, so keep it up! */
-#define OPT_CANCEL_ELSEWHERE    ((uint64_t)1 << 33)
-#define OPT_PEER_H    ((uint64_t)1 << 34)
+#define DIAL_STILLGOING        ((uint64_t)1 << 32)
+#define DIAL_NOFORWARDHTML        ((uint64_t)1 << 33) /* flags are now 
64 bits, so keep it up! */
+#define OPT_CANCEL_ELSEWHERE    ((uint64_t)1 << 34)
+#define OPT_PEER_H               ((uint64_t)1 << 35)
 
 enum {
     OPT_ARG_ANNOUNCE = 0,
--------------------------------------------------------------

Right now my patch has to be applied manually because a whitespace 
commit since yesterday.
Can someone explain why almost every flags are defined inside an enum 
but some are #define:
DIAL_STILLGOING, DIAL_NOFORWARDHTML, OPT_CANCEL_ELSEWHERE, OPT_PEER_H

Greetings,
Johan Wilfer
>   
>>     
>>> 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 <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
>>>
>>>       
>> _______________________________________________
>> --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
>>
>>     
>
>
>   




More information about the asterisk-dev mailing list