[asterisk-bugs] [JIRA] (ASTERISK-28766) PJSIP blind transfer not completed after using Proceeding()

[Kevin Harwell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249893#comment-249893 ] 

Kevin Harwell commented on ASTERISK-28766:
------------------------------------------

oh yeah ha! that was it. I just added the one line, and didn't apply the whole patch. In the review for some reason my brain saw the added comments, but skipped over the deleted parts.

I see why your patch fixes it now. Okay makes much more sense.

> PJSIP blind transfer not completed after using Proceeding()
> -----------------------------------------------------------
>
>                 Key: ASTERISK-28766
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28766
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 16.8.0
>            Reporter: lvl
>            Assignee: lvl
>         Attachments: sip.txt
>
>
> If you perform a blind transfer (REFER), transfer the call to an extension that uses {{Proceeding()}} then remains in the dialplan and does **not** dial out, the transferer will not be notified of the transfer success.
> To clarify. A transfer to the following extensions will finish properly:
> {code}
> s,1,Proceeding()
> s,2,Dial(PJSIP/bla)
> {code}
> {code}
> s,1,Playback(bla)
> {code}
> While the following extension will fail:
> {code}
> s,1,Proceeding()
> s,2,Playback(bla)
> {code}
> Why is this? Transfer status is handled by refer_progress_framehook in https://github.com/asterisk/asterisk/blob/master/res/res_pjsip_refer.c#L218
> Apparently, if the target extension executes a {{Dial()}}, this generates a control frame of the AST_CONTROL_ANSWER type which will trigger {{refer_progress_notify}} with a status 200. This will signal to the transferer that the transfer is accepted and their phone can disconnect.
> However, if the call remains in the dialplan no such control frame is generated, even if you explicitly {{Answer()}}. In this case, the transfer status is normally detected by the passing of a AST_FRAME_VOICE. But that code only triggers if {{progress->subclass}} is null, e.g. once any control frame has been detected, a subsequent voice frame can no longer trigger transfer completion.
> This code was introduced in https://github.com/asterisk/asterisk/commit/77002bc377f19ea11e60732c486b6ef371688773 and subtly changed in https://github.com/asterisk/asterisk/commit/344cdab3a71d8f8b3517e7efe6864165142b14ca. My best guess is that the intention was to prevent duplicate progress messages from being generated when a voice frame was detected after a control frame had already triggered the appropriate notify.
> But this premise is false, as the passing of e.g. a AST_CONTROL_PROCEEDING frame (triggering a 100) should not prevent a AST_FRAME_VOICE frame from later triggering a 200.



--
This message was sent by Atlassian JIRA
(v6.2#6252)