[asterisk-bugs] [JIRA] (ASTERISK-29839) PJSIP Failover after cancel

[Jonas Swiatek (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonas Swiatek updated ASTERISK-29839:
-------------------------------------

    Attachment: debug_log_dnssrv

Debug output from Asterisk

> PJSIP Failover after cancel
> ---------------------------
>
>                 Key: ASTERISK-29839
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29839
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 16.24.0
>         Environment: Amazon Linux 2
>            Reporter: Jonas Swiatek
>            Assignee: Unassigned
>         Attachments: bla.pcap, debug_log_dnssrv
>
>
> Asterisk configured with an AOR like so:
> [registrar]
> type=aor
> contact=somesrvrecord.example.com
> somesrvrecord.example.com returns multiple IP addresses.
> The issue I'm seeing is that Asterisk will perform a failover, even after it has cancelled an outbound call. For instance:
> 1. Asterisk sends a SIP INVITE
> 2. Asterisk sends a SIP CANCEL to cancel that invite
> 3. If asterisk receives anything but 200 cancelled followed by 487 Request Terminated, it will STILL failover by sending the same INVITE to the next IP address in the SRC Record set.
> This obviously creates a ghost call, and if that new INVITE is answered, asterisk immediately generates a BYE to end that transaction, which I suppose is fine, but it shouldn't be failing over to the next record under these conditions at all.
> This also happens if it doesn't receive the 487 Request Terminated within 10 seconds.
> Generally asterisk is pretty aggressive with it's failovers here. Almost anything but a 404, 486 or 480 will cause a failover, which could be a bug, but at least would be very nice if could be configured to only do a failover on either a 500 response or a timeout on the initial SIP INVITE.



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