Skip to content
Snippets Groups Projects
  • Mark Michelson's avatar
    1536b0ec
    Fix race condition that could result in ARI transfer messages not being sent. · 1536b0ec
    Mark Michelson authored
    From reviewboard:
    
    "During blind transfer testing, it was noticed that tests were failing
    occasionally because the ARI blind transfer event was not being sent.
    After investigating, I detected a race condition in the blind transfer
    code. When blind transferring a single channel, the actual transfer
    operation (i.e. removing the transferee from the bridge and directing
    them to the proper dialplan location) is queued onto the transferee
    bridge channel. After queuing the transfer operation, the blind transfer
    Stasis message is published. At the time of publication, snapshots of
    the channels and bridge involved are created. The ARI subscriber to the
    blind transfer Stasis message then attempts to determine if the bridge
    or any of the involved channels are subscribed to by ARI applications.
    If so, then the blind transfer message is sent to the applications. The
    way that the ARI blind transfer message handler works is to first see
    if the transferer channel is subscribed to. If not, then iterate over
    all the channel IDs in the bridge snapshot and determine if any of
    those are subscribed to. In the test we were running, the lone
    transferee channel was subscribed to, so an ARI event should have been
    sent to our application. Occasionally, though, the bridge snapshot did
    not have any channels IDs on it at all. Why?
    
    The problem is that since the blind transfer operation is handled by a
    separate thread, it is possible that the transfer will have completed and
    the channels removed from the bridge before we publish the blind transfer
    Stasis message. Since the blind transfer has completed, the bridge on
    which the transfer occurred no longer has any channels on it, so the
    resulting bridge snapshot has no channels on it. Through investigation of
    the code, I found that attended transfers can have this issue too for the
    case where a transferee is transferred to an application."
    
    The fix employed here is to decouple the creation of snapshots for the transfer
    messages from the publication of the transfer messages. This way, snapshots
    can be created to reflect what they are at the time of the transfer operation.
    
    Review: https://reviewboard.asterisk.org/r/4135
    ........
    
    Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
    1536b0ec
    History
    Fix race condition that could result in ARI transfer messages not being sent.
    Mark Michelson authored
    From reviewboard:
    
    "During blind transfer testing, it was noticed that tests were failing
    occasionally because the ARI blind transfer event was not being sent.
    After investigating, I detected a race condition in the blind transfer
    code. When blind transferring a single channel, the actual transfer
    operation (i.e. removing the transferee from the bridge and directing
    them to the proper dialplan location) is queued onto the transferee
    bridge channel. After queuing the transfer operation, the blind transfer
    Stasis message is published. At the time of publication, snapshots of
    the channels and bridge involved are created. The ARI subscriber to the
    blind transfer Stasis message then attempts to determine if the bridge
    or any of the involved channels are subscribed to by ARI applications.
    If so, then the blind transfer message is sent to the applications. The
    way that the ARI blind transfer message handler works is to first see
    if the transferer channel is subscribed to. If not, then iterate over
    all the channel IDs in the bridge snapshot and determine if any of
    those are subscribed to. In the test we were running, the lone
    transferee channel was subscribed to, so an ARI event should have been
    sent to our application. Occasionally, though, the bridge snapshot did
    not have any channels IDs on it at all. Why?
    
    The problem is that since the blind transfer operation is handled by a
    separate thread, it is possible that the transfer will have completed and
    the channels removed from the bridge before we publish the blind transfer
    Stasis message. Since the blind transfer has completed, the bridge on
    which the transfer occurred no longer has any channels on it, so the
    resulting bridge snapshot has no channels on it. Through investigation of
    the code, I found that attended transfers can have this issue too for the
    case where a transferee is transferred to an application."
    
    The fix employed here is to decouple the creation of snapshots for the transfer
    messages from the publication of the transfer messages. This way, snapshots
    can be created to reflect what they are at the time of the transfer operation.
    
    Review: https://reviewboard.asterisk.org/r/4135
    ........
    
    Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427870 65c4cc65-6c06-0410-ace0-fbb531ad65f3