[Home]

Summary:ASTERISK-04413: Local channels do not change to their connected trunk(Zap, SIP, ...) upon receiving Answer
Reporter:Matt Florell (mflorell)Labels:
Date Opened:2005-06-14 15:56:32Date Closed:2008-01-15 15:42:48.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) localmasq.patch
Description:Up through Release 1.0.7 when you placed a call using the Local/ channel on the Manager API and the call was Answered, it changed to the trunk that the call was placed through(i.e. Zap/25-1). Now that does not happen and even after the call is answered, if it goes to an AGI script it will report itself as a Local/ channel for the life of the call.

  Here is a Manager Action to generate a call in this way:
Action: Originate
Exten: 8600011
Channel: local/917275551212@default
Context: default
Priority: 1
Timeout: 27000
Callerid: "DF345678901234567899" <0000000000>


  Here is what shows up in 'show channels' for the life of the call:
Channel  (Context    Extension    Pri )   State Appl.         Data
Zap/25-1  (default    s            1   )      Up Bridged Call  Local/917275551212@default-33a4,2
Local/917275551212@default-33a4,2  (default    917275551212 3   )      Up Dial          Zap/g2/17275551212|30|p
Local/917275551212@default-33a4,1  (default    8600011      1   )      Up MeetMe        8600011|qM
3 active channel(s)

In release 1.0.7 the call would MASQ over to Zap/25-1 and the Local channels that had been created to start the call would be dropped and Hungup.

Was this change done for a reason?

This doesn't seem like a fix, it seems like a change in the way a process runs and should not have been included in the 1.0 Stable tree.
Comments:By: Matt Florell (mflorell) 2005-06-14 16:53:10

Looking at the Debug logs it appears that the call is sent on to the exten before any of the Masqerading takes place, where in 1.0.7 the Masquerading was done first and then the call is sent on to the exten.

Also, the Local/ .... ,1 and Local/ .... ,2 channels are not deleted in Stable like they were in 1.0.7

Was this all done to speed the call along to it's destination?

Will all 3 channels(both Local/ channels and the actual trunk channel) stay in existance for the life of the call?
By: Tony Mountifield (softins) 2005-06-25 04:32:11

I agree this behaviour is anomalous - looks to me like either an inadvertently introduced bug, or a poor design decision.

Please could someone involved with introducing this change explain the rationale behind it, if any? Thanks!
By: Olle Johansson (oej) 2005-07-18 06:23:49

Can you find the patch that changed this behaviour? Is the problem still there?

/Housekeeping
By: Matt Florell (mflorell) 2005-07-18 08:10:38

Well, this happened between release 1.0.7 and CVS Stable on June 14th when I discovered it. I tried looking for it at that time for a couple days, but the path of a Local call is quite complex and goes through many processes and I kind of got lost, then I had to go on to other things.

Where can I look to find a list of patches applied to the Stable tree during that timeframe?

I will investigate this further when I return from vacation next week.
By: Olle Johansson (oej) 2005-07-18 08:52:09

The list archive for asterisk-cvs is one source. If you run windows, I would recommend installing tortoise, the graphical CVS client. For each file, you can look at the history and see changes done with dates and version number. That will help you find the proper patch in the mailing list archive on lists.digium.com.
By: Russell Bryant (russell) 2005-07-18 11:22:34

It looks like this was the change that is making this happen.  However, my concern is that this same change was made to CVS HEAD, but the issue does not exist there.

Now, the question is, is there any reason you wouldn't want to masquerade if there are any frames in the readq?
By: Russell Bryant (russell) 2005-07-18 12:32:39

New patch!  I think this is going to fix it.  I would appreciate it if you guys would test it before I put it in.
By: Matt Florell (mflorell) 2005-07-26 10:07:06

The localmasq.patch fixes 1.0.8 and 1.0.9 so that they behave like they should. And yes it seems that CVS-HEAD was fixed at some time a few weeks after this bug was posted.

Thanks for the patch drumkilla!
By: Russell Bryant (russell) 2005-07-26 10:45:50

I'm glad that I was able to help.  :)  This was the result of one of those situations where you fix one problem only to expose another.
By: Russell Bryant (russell) 2005-07-26 10:46:34

The patch is in cvs v1-0, and will be included in the next release of Asterisk (1.0.10).
By: Digium Subversion (svnbot) 2008-01-15 15:42:48.000-0600

Repository: asterisk
Revision: 6222

U   branches/v1-0/channels/chan_local.c

------------------------------------------------------------------------
r6222 | russell | 2008-01-15 15:42:48 -0600 (Tue, 15 Jan 2008) | 2 lines

fix masquerading of local channels into the new channel type (bug ASTERISK-4413)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6222