[asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang

[Jonathan Rose]

> On May 8, 2014, 3:22 p.m., Joshua Colp wrote:
> > /branches/12/res/res_pjsip_refer.c, lines 185-193
> > <https://reviewboard.asterisk.org/r/3485/diff/4/?file=58332#file58332line185>
> >
> >     I need time to grok your other changes and the possible repercussions but I'll comment on this right now. Would this get called twice since the framehook is invoked when detached?
> 
> Jonathan Rose wrote:
>     Yep, it's hitting it twice.  Guess I need to make sure it doesn't push a second notify.

I'm not sure if this is the proper and elegant way to do this, but I just added a check for if the event value is AST_FRAMEHOOK_EVENT_DETACHED and if it is, I'm returning early right now.  It fixes the behavior, but it might be cleaner if I just put the whole thing in as a check for if the event type is ATTACHED seeing as this is to handle hangups prior to actually attaching the frame hook and all.


- Jonathan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3485/#review11861
-----------------------------------------------------------


On May 8, 2014, 12:40 p.m., Jonathan Rose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3485/
> -----------------------------------------------------------
> 
> (Updated May 8, 2014, 12:40 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and Mark Michelson.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> If a PJSIP endpoint attempts to blind transfer to a parking extension, there is an override to the normal transfer logic that can make things act a little weird. We noticed that this would leave various phones hanging on transfer screens without progressing. When the transfer was considered successful, PJSIP deferred the actual action of sending the 200 notify and the actual trigger for that happening never occurs when the transfer is to a parking extension.
> 
> In order to handle this, the bridge function that handles blind transfers now returns a different value if a call was parked and if the channel driver needs to react differently in this case, it can.  In the case of PJSIP, we respond to transfers to park by immediately sending the notify with 200 OK sip frag instead of deferring the action.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/res_pjsip_refer.c 413303 
>   /branches/12/res/parking/parking_bridge_features.c 413303 
>   /branches/12/res/parking/parking_applications.c 413303 
>   /branches/12/main/parking.c 413303 
>   /branches/12/main/bridge.c 413303 
>   /branches/12/include/asterisk/parking.h 413303 
>   /branches/12/channels/sig_analog.c 413303 
>   /branches/12/channels/chan_sip.c 413303 
>   /branches/12/channels/chan_mgcp.c 413303 
>   /branches/12/channels/chan_dahdi.c 413303 
> 
> Diff: https://reviewboard.asterisk.org/r/3485/diff/
> 
> 
> Testing
> -------
> 
> Before patch:
> * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until it either manually hangs up or 60 seconds pass and Asterisk terminates the session.
> 
> After the patch:
> * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer screen and goes back to idle mode.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140508/c03a5af3/attachment-0001.html>