|Summary:||ASTERISK-06808: [patch][post 1.4] EndDial Manager Event|
|Reporter:||Moises Silva (moy)||Labels:|
|Date Opened:||2006-04-18 19:05:58||Date Closed:||2006-10-30 17:16:36.000-0600|
|Environment:||Attachments:||( 0) asterisk-svn-21231-EndDial_event.patch|
( 1) dial-end-event-rev-46117.patch
|Description:||small but usefull manager event that complements the already existant Dial event. This one is launched at the end of Dial() and has de DIALSTATUS value.|
|Comments:||By: Clod Patry (junky) 2006-04-23 14:01:39|
i wonder if it's really needed since, we already have an Hangup event.
Cause-txt: Normal Clearing
Cause-txt: Normal Clearing
By: Moises Silva (moy) 2006-04-23 21:06:07
For simple applications, hangup is enough, but we have a completly event driven router. Hangup is not usefull if you want to do other things with the call according to DIALSTATUS. I think that comparing Hangup with this event, is like comparing Link with the already existant Dial event. Dont you think?
By: Clod Patry (junky) 2006-04-23 21:13:09
Cause: 16 sounds like a dial answered in my mind.
I think i remember a patch, which has the bridged channel in the Hangup Event.
By: Serge Vecher (serge-v) 2006-05-08 11:55:31
moy: is the cause field in Hangup sufficient for you purposes? If not, can it be extended instead of adding new event?
By: Moises Silva (moy) 2006-05-08 20:41:26
I have tought in the possibility of using or adding something to the hangup event. But the fact is that the hangup event is
for "HANGUP EVENTS" not for Dialing attempt ended events, so let me try to explain better my point.
When SIP extension "22" dials to extension "33". The call goes to the unique context we have configured in Asterisk, [main],
the only thing we have there is:
exten => _X.,Answer()
exten => _X.,MAGI()
From MAGI() we control everything using events (including DTMF detection and other features). So we match the 33 dialed against
our pattern table. We find is a extension call, so we send the command Dial(SIP/33), but when extension 33 is not connected to
the network, Asterisk does not even generate the SIP/33 channel, so we cannot use the hangup event of SIP/33 right?
And we cannot wait for Hangup event of the caller extension (SIP/22), since we may want to do other things before hanging up
(like telling the caller that the extension is not available and providing dial tone again).
I really hope this makes sense. :)
thanks for your attention and im open to more suggestions.
By: Jared Smith (jsmith) 2006-05-16 10:43:54
The code looks straighforward to me, and I can see where it would be handy to have this Manager event.
By: Olle Johansson (oej) 2006-05-17 02:13:21
We try to avoid having events named like this: Event: nameStart Event: nameEND
Instead, we want ONE event name with different parameters signalling the state information. Would that be possible here without breaking the support of the existing dial event?
By: Olle Johansson (oej) 2006-05-17 02:14:14
junky: End of dial does not always mean end of a call (hangup). You can have several dial attempts in one call, so this event makes sense.
By: Olle Johansson (oej) 2006-05-17 02:22:17
From the coding guidelines: "Manager events that signal a status are required to have one
event name, with a status header that shows the status.
The old style, with one event named "ThisEventOn" and another named
"ThisEventOff", is no longer approved."
By: Moises Silva (moy) 2006-05-17 15:55:44
I will update the patch ASAP
By: Moises Silva (moy) 2006-05-17 20:23:48
I have sent an email to the asterisk-dev mailing list, some issues come to my mind, so please report feedback there to decide how to implement this.
By: Moises Silva (moy) 2006-05-19 15:40:12
I have not received response from asterisk-dev. Im posting here a resume of my doubts about how to proceed:
Please note, when I say DialStarting event, I mean, Dial event with Starting Flag. Same to DialEnding.
When the parameter passed to Dial() is composed of several dial
strings, Asterisk sends one DialStarting event for each created
channel. If one of the dial strings is unable to create a channel, no
DialStarting event is sent, ( ie SIP/14 is not a valid SIP peer ).
However, for DialEnding events is usefull to know the status
"CHANUNAVAIL". So here im having problems to decide where to go.
It would seem silly to generate a DialStarting event when we
already know that the channel has not been generated. In the other
hand seems weird to me to generate an DialEnding event with no prior
DialStarting event. Besides, I think that the Dial event should
reflect the Dialing attempt, it doesnt matter that the channel has not
I can see 3 main options:
1. Move DialStarting to a position in the code where we still dont know the result of the Dial attempt (just BEFORE ast_call() function).
2. Keep DialStarting where is right now, and immediatly after sending
the DialStarting send a DialEnding with CHANUNAVAIL DialStatus when apply.
3. Forget completly about DialStarting and send DialEnding, even
though, that no DialStarting event was ever sent.
Any toughts and recommendations are more than welcomed.
By: Steve Murphy (murf) 2006-10-17 18:56:44
There's not been very much activity here, and I'm rooting about for bugs to close.
I've read thru the history, and I'll throw in my two cents here, I guess: I'm all for not crowding the manager events channel with events that most likely won't be useful. So, I say, the Dial-End is sufficient; Perhaps if you thought it as a sort of "Dial-Result" event instead, maybe that would provide a better way of thinking about it, but Dial-End is OK, if no Dial-Start is issued, at least to me.
How do we proceed?
By: Moises Silva (moy) 2006-10-17 19:43:23
Im fine too receiving dialend evend when no dialstart is generated. I was just wondering that may confuse other people, but is fine for me?
Do you need anything else?
By: Steve Murphy (murf) 2006-10-17 21:05:09
OK. Will commit the patch. I've added some missing events to astman while I was at it.
By: Steve Murphy (murf) 2006-10-17 21:12:32
Wait a minute! Your patch still has the EndDial event instead of a Dial event with a compeletion status or whatever. You said on 05-17 you were going to update the patch; but the patch attached is dated before that... got that last update?
By: Moises Silva (moy) 2006-10-18 10:33:12
murf: Im very sorry, i missed that, I remember now that i was updating the patch when realized of the issues I requested comments for, and never get comments, so the update remained in "stand by", I will post the new patch tomorrow in the afternoon.
Thanks for your help to get this into Asterisk.
By: Serge Vecher (serge-v) 2006-10-24 08:38:21
moy: where is the updated patch?
By: Moises Silva (moy) 2006-10-24 10:04:42
sorry it took me so long get back to this, I have uploaded the patch. I have used the header "SubEvent" to tell if is starting or ending.
The output is like this:
and at the end:
Thanks a lot for your time.
By: Steve Murphy (murf) 2006-10-30 17:13:13.000-0600
Via commit 46541, I have merged this patch into the trunk. Let me know
if all is well.
By: Steve Murphy (murf) 2006-10-30 17:16:35.000-0600
With patched merged to svn, time to close the issue.