[asterisk-bugs] [JIRA] (ASTERISK-30454) res_pjsip_refer: NOTIFY sipfrag may terminate early depending on conditions

[David Middleton (JIRA)]

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

David Middleton commented on ASTERISK-30454:
--------------------------------------------

Hi Joshua,

I wanted to provide a bit more context and detail around the problems that the 'early' ('early' as in before the transferee call has been answered) NOTIFY with sigrag 200 OK is causing.
The problem is particularly acute when interworking with MS Teams and exagerated by the way that MS handles attended transfers.
In fact, they never signal an attended transfer; they always use a blind transfer, but rely on all call legs being routed through their infrastructure and then use INVITEs with replaces to complete the call setup on any external call legs.

I've attached a couple of example call flows to help try and visulaise the problem.

In 'msteams_attended-transfer_teams-teams_ASTERISK-30454.png' we have a call from asterisk into Teams Exten A.
Teams Exten A puts call on hold and initiates an attended transfer to Teams Exten B.
Teams Exten A makes a consult call directly to Teams Exten B (and so we don't see the signalling as it's Teams to Teams, dialled using the user name in the Teams address book popup).
Once the call is established, Teams exten A hits 'Transfer'.
We receive a blind transfer with the refer-to header containing a URI parameter with the Microsoft GUID of the transferee (as well as the referred-by header containing a URI parameter of the transferor).
Asterisk sends a new INVITE to Teams Exten B but very shortly after also sends a NOTIFY with a sipgrag 200 OK back to Teams. (I've omitted the NOTIFYs with sipgrags 100, 183 and 180 for brevity.)

The problem is that MS assume (due to the sipfrag 200 OK) that the call to the transferee has been answered and start tearing down the original call leg from asterisk to the transferor as well as the consult leg from transferor to transferee.
This means that when the INVITE that was initiated by asterisk due to the REFER (and has a replaces header added by MS to replace the consult leg) get's processed, the consult leg has gone and so they reject it with the 404 Not Found (and a reason of 'Replacement call was not found').

(I appreciate that you don't see these INVITEs with replaces in this example, but we do see them if the transfer was to PSTN; MS dictate that all transferred calls go back through them and so we see the INVITE to PSTN forwarded back out to us as a new call, but with a replaces header to replace the consul call that's already set up.)

We carried out some tests, first by blocking the NOTIFY from reaching MS. With this set up, the call to the transferee was not rejected and rang the target correctly.
We then added a 500mS delay in res_rjsip_refer for any NOTIFY with a sipgrag 200 OK.  Transfers were also completed successfully.

I've added an example sip trace (20230314_pstn-teams_at_teams-500ms_delay_ok_digium_ANON_ASTERISK-30454.pcap) and debug log (20230314_debug_log_ASTERISK-30454.txt).

PSTN (+447700900000) calling DDI (+441632960000) for Teams exten A (319-astpjsip).
PJSIP/proxy-00000010 - PSTN -> asterisk
PJSIP/proxy-00000011 - asterisk -> Teams Exten A
PJSIP/proxy-00000012 - asterisk -> Teams Exten B

I've also attached a simplified flow diagram for when the delay was added (msteams_attended-transfer_teams-teams_notify_delay_ASTERISK-30454.png).

Obviously w'd rather not run our production asterisk servers with this fixed delay in res_rjsip_refer and it would be far better if the sending of the sipfrag 200 NOTIFY was driven by a more appropiate event, such as the SIP 200 OK response to the transferred call leg.

(One other interesting side effect of adding the delay, even a much smaller 20mS one, was that asterisk stopped sending the NOTIFYs with the 183 and 180 sipfrags.)

Thanks,
David

> res_pjsip_refer: NOTIFY sipfrag may terminate early depending on conditions
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-30454
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30454
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_refer
>    Affects Versions: 18.14.0
>            Reporter: David Middleton
>            Assignee: Unassigned
>         Attachments: 2023030602_ASTERISK-30454_anon.pcap, 2023030602_debug_log_ASTERISK-30454.txt, 20230314_debug_log_ASTERISK-30454.txt, 20230314_pstn-teams_at_teams-500ms_delay_ok_digium_ANON_ASTERISK-30454.pcap, msteams_attended-transfer_teams-teams_ASTERISK-30454.png, msteams_attended-transfer_teams-teams_notify_delay_ASTERISK-30454.png
>
>
> Party A calls Party B (and call is answered).
> Party B puts Party A on hold and blind transfers to Party C.
> Asterisk sends a SIP NOTIFY with a sipfrag 200 OK (after various NOTIFY with 1xx progress sipfrags) before the transferred call (to Party C) has been answered.
> The expected behaviour is for the all the NOTIFYs to be sent with sipfrags reflecting the upstream progress of the transferred call.



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