[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=249889#comment-249889 ] 

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

The problem appears to be Asterisk failing to send back the 200 OK sipfrag in the NOTIFY. Instead it's getting the following:
{noformat}
<--- Transmitting SIP request (857 bytes) to UDP:1.6.1.6:8065 --->
NOTIFY sip:phone_186347_0 at 1.6.1.6:38474;ob;alias=1.6.1.6~38474~1 SIP/2.0
Via: SIP/2.0/UDP 1.6.1.6:8066;rport;branch=z9hG4bKPj4c8e78b3-3757-467e-9a1b-7a8449795ba8
From: "Aa unit" <sip:201 at 1.6.1.6>;tag=7327871d-6ecb-4b84-9cb7-31fef1706837
To: <sip:phone_186347_0 at acme01.exampledev.com>;tag=b6b470f4-4e5c-4cd9-93bf-8fd422953978
Contact: <sip:asterisk at 1.6.1.6:8066>
Call-ID: b429f61a-94b6-4d47-8c15-719dbf745a13
CSeq: 32547 NOTIFY
Route: <sip:1.6.1.6:8065;lr;ftag=7327871d-6ecb-4b84-9cb7-31fef1706837;did=4a4.bfd>
Route: <sip:1.6.1.6:8060;lr>
Event: refer
Subscription-State: terminated;reason=noresource
Allow-Events: presence, dialog, message-summary, refer
Max-Forwards: 70
User-Agent: Acme PBX
Content-Type: message/sipfrag;version=2.0
Content-Length:    33

SIP/2.0 503 Service Unavailable
{noformat}
I am getting this too in my testing with Proceeding.

> 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: Unassigned
>         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)