[asterisk-bugs] [JIRA] (ASTERISK-21145) asterisk 10 softhangup

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-21145:
------------------------------------

    Description: 
Noticed a change in ast_softhangup after moving to asterisk 10. Asterisk doesn't continue to the next priority after a soft hangup which doesn't make much sense.

See asterisk-dev: http://lists.digium.com/pipermail/asterisk-dev/2013-February/058709.html

[Edit by Rusty Newton - adding the E-mail below (links could get broken in the future)]

{quote}
> >> I noticed a change in ast_softhangup after moving to asterisk 10.
> >> Now
> >> asterisk doesn't continue to the next priority after a soft hangup
> >> which doesn't make much sense. Is this an feature or bug?
> > 
> > Either svn revisions
> > -r190423 Changes channels to ref counted objects
> > -r225244 Add support for OBJ_MULTIPLE
> > 
> > Causes the issue.  The app does not continue in the dialplan if no
> > channels are found to hangup or there was a memory allocation
> > error.
> > 
> > Its a bug.
> 
> That's what I thought. What about ast_channel_clear_softhangup? Why
> does it need to go through the readq?
>  The only thing ast_softhangup queues is a null frame and I thought
>  they're supposed to be ignored.

There is a comment in ast_channel_clear_softhangup() that says why.
There is another comment in __ast_read() where the AST_CONTROL_END_OF_Q
control frame is put in the read queue that gives even more information.

Basically, when ast_read() sees a hangup, there may be pending frames
in the read queue so it puts a control frame in the read queue to know
when all pending frames have been read and to block any more frames
from being put on the read queue.  ast_read() will then return a NULL
to indicate a hangup.
{quote}


  was:
Noticed a change in ast_softhangup after moving to asterisk 10. Asterisk doesn't continue to the next priority after a soft hangup which doesn't make much sense.

See asterisk-dev: http://lists.digium.com/pipermail/asterisk-dev/2013-February/058709.html

    
> asterisk 10 softhangup
> ----------------------
>
>                 Key: ASTERISK-21145
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21145
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: PBX/General
>    Affects Versions: 1.8.20.1, 10.12.1, 11.2.1
>         Environment: Linux manage 3.0.6-gentoo #1 SMP Wed Nov 16 02:09:24 Local time zone must be set--see zic  x86_64 Intel Core i7 9xx (Nehalem Class Core i7) GenuineIntel GNU/Linux
>            Reporter: Paul Albrecht
>
> Noticed a change in ast_softhangup after moving to asterisk 10. Asterisk doesn't continue to the next priority after a soft hangup which doesn't make much sense.
> See asterisk-dev: http://lists.digium.com/pipermail/asterisk-dev/2013-February/058709.html
> [Edit by Rusty Newton - adding the E-mail below (links could get broken in the future)]
> {quote}
> > >> I noticed a change in ast_softhangup after moving to asterisk 10.
> > >> Now
> > >> asterisk doesn't continue to the next priority after a soft hangup
> > >> which doesn't make much sense. Is this an feature or bug?
> > > 
> > > Either svn revisions
> > > -r190423 Changes channels to ref counted objects
> > > -r225244 Add support for OBJ_MULTIPLE
> > > 
> > > Causes the issue.  The app does not continue in the dialplan if no
> > > channels are found to hangup or there was a memory allocation
> > > error.
> > > 
> > > Its a bug.
> > 
> > That's what I thought. What about ast_channel_clear_softhangup? Why
> > does it need to go through the readq?
> >  The only thing ast_softhangup queues is a null frame and I thought
> >  they're supposed to be ignored.
> There is a comment in ast_channel_clear_softhangup() that says why.
> There is another comment in __ast_read() where the AST_CONTROL_END_OF_Q
> control frame is put in the read queue that gives even more information.
> Basically, when ast_read() sees a hangup, there may be pending frames
> in the read queue so it puts a control frame in the read queue to know
> when all pending frames have been read and to block any more frames
> from being put on the read queue.  ast_read() will then return a NULL
> to indicate a hangup.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira