[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