Summary:ASTERISK-08190: [patch] OriginateSuccess and OriginateError incomplete
Reporter:dmb (dmb)Labels:
Date Opened:2006-11-27 05:48:52.000-0600Date Closed:2006-12-07 10:12:28.000-0600
Versions:Frequency of
Environment:Attachments:( 0) asterisk-1.4beta3-bug8423.patch
( 1) asterisk-1.4beta3-bug8423-final.patch
( 2) originate-channel-name-1.4.0-beta3.patch
In manager.c in 1.4 beta3 an event (OriginateSuccess and OriginateError) notify the channel created in a originate action giving the actionid and the channel. I have seen that the channel recibed is incomplete (for example SIP/1004). I think that this is incomplete. The correct channel must be the channel name (for example SIP/1004-09b6f388).

Is that correction included in the next beta or in the release candidate?

Thank you.

Comments:By: Steve Murphy (murf) 2006-11-29 13:18:53.000-0600

I checked the code for these results, and the channel name is split into 2 pieces and then rejoined to get what you see in the result message. I do not see any other parts being deleted.

Please, tell me what command you issue, and in what context, so I can be sure I'm doing the same thing as you are, and I will see what can be done.

By: Moises Silva (moy) 2006-12-02 15:33:20.000-0600

Murf: im attaching a file that fixed the issue for me. Actually is more a workaround, since the OriginateError and OriginateSuccess keep returning the channel name as requested, not as created. Im going to see if something else can be done ( by the way, why 2 different events? I think OriginateSuccess and OriginateError should be merged into 1 event with different SubEvent: header). The patch give support to Newchannel event to send ActionID when some Originate created the channel.

Disclaimer OK.


By: Moises Silva (moy) 2006-12-02 15:57:14.000-0600

Murf: I think this last patch fix the issue. The thing is that is split in 2 pieces, in->tech and in->data, but that not includes the generated identifier by each channel technology. With this patch I think it should do it, unless the channel cannot be created.

dmb: can you test the patch please?

the one that is supposed to fix the issue is: originate-channel-name-1.4.0-beta3.patch

By: Steve Murphy (murf) 2006-12-04 11:30:05.000-0600

Sorry, but the attached patch is associated with an older version of 1.4; that code has changed quite a bit! For instance, Newchannel events are now generated in the channel_alloc call, and nowhere else.

I'll try to study what you were doing, and see if I can blend what you did into the svn latest version.

By: Moises Silva (moy) 2006-12-04 11:40:15.000-0600

Murf: Im sorry, please ignore the first patch, the good one is the second, I realized that fixing the issue itself was easier, the first patch I uploaded is more a new feature that can help to fix the issue, but is not necessary.

Again, the patch is: originate-channel-name-1.4.0-beta3.patch

Thanks Murf

By: Steve Murphy (murf) 2006-12-04 13:30:32.000-0600

OK, this patch looks much better. I see what you are doing; I made only one small fomatting change. Are you sure it works for you? Anyone else tested this?

By: Moises Silva (moy) 2006-12-04 14:45:44.000-0600

NO, I just made sure it compiles and makes sense. Actually I was expecting the reporter to test it. But I can test it tonight and report results tomorrow.

By: Moises Silva (moy) 2006-12-05 09:32:21.000-0600

murf: confirmed, the patch works as expected.

Before the patch, when a valid channel is originated, the OriginateSuccess event DOES NOT show the name of the created channel, but the same channel name as requested. ie

If the Originate action specify this channel to create:

The OriginateSuccess event will show as the originated channel exactly the same string:

Wich is not very usefull since this is not the name by wich the channel is known in the PBX. So, after the patch, the same Originate action returns something like this as originated channel


That is, the channel name assigned by the technology driver.

In case that some invalid channel name is attempted to be originated, the event originateFailure will return the name as specified.

Any comments?

By: dmb (dmb) 2006-12-05 10:27:10.000-0600

I test the patch and the correction solve the problem.

Thank you!!!

By: Moises Silva (moy) 2006-12-05 11:30:48.000-0600

dmb: your welcome

By: Steve Murphy (murf) 2006-12-05 12:46:02.000-0600

moy (blush) I should learn to associate mailing list names with bug tracker names!

At any rate, OK, there is just one last little thing-- you mentioned that the Originate Sucess/Fail events should be merged into an Originate event with subevent; is this a good time to do this? It would line up better with written directives as to event typing. I tend to think that the current situation is a bug... what do you think?

By: Moises Silva (moy) 2006-12-05 13:42:04.000-0600

Yes, I think this is a good moment to change this ugly behaviour of sending 2 different event names with the same fields. I vote for using OriginateResponse as event name and  use the header Response: Failure | Success.

I mentioned the SubEvent header, but I dont think makes sense here ( as it does in "Dial" event ).

So, finally I think something like this should be enough:

Event: OriginateResponse
Response: Failure | Success

this change should be mentioned in UPGRADE.txt?

Just let me know how to proceed, i will have some time tonight and can make this quick change.

By: Steve Murphy (murf) 2006-12-05 15:47:05.000-0600

Mostly yes!

I think this is excellent:

Event: OriginateResponse
Response: Failure | Success

and yes, there should be note in UPGRADE, a small one in CHANGES.

By: Moises Silva (moy) 2006-12-05 23:20:31.000-0600

Uploaded new file with the requested changes

By: Steve Murphy (murf) 2006-12-06 15:52:25.000-0600

Are you sure you don't want to order your args to the manager_event call in this fashion:
"CallerIDName: %s\r\n",
in->idtext, res ? "Failure" : "Success", chan ? chan->name : requested_channel, in->context, in->exten, reason, ...

in->idtext should fill in the "%s", shouldn't it?

By: Moises Silva (moy) 2006-12-06 23:16:08.000-0600

duh! you are completly right, I MUST remember to test even those small changes. I have uploaded a new patch, and I have tested it already.

Anything else?

By: Steve Murphy (murf) 2006-12-07 10:04:30.000-0600

These changes applied via (1.4) 48349, and (trunk) 48350.

By: Steve Murphy (murf) 2006-12-07 10:12:27.000-0600

So, it looks like time to close this!