[asterisk-bugs] [JIRA] (ASTERISK-23746) Asterisk responds with 603 Declined in blonde transfer scenario

[Leif Madsen (JIRA)]

Leif Madsen created ASTERISK-23746:
--------------------------------------

             Summary: Asterisk responds with 603 Declined in blonde transfer scenario
                 Key: ASTERISK-23746
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23746
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_sip/Interoperability
    Affects Versions: 1.8.18.0
            Reporter: Leif Madsen


In our internal testing with a "jitsi" (in quotes because it is built for us by the jitsi guys) client, we identified an issue with Communicator (aka custom jitsi) which causes channels to be left in a hung state in Asterisk.

The trace has been attached to this issue.

There are 4 Call-IDs involved here. Let me note what is going on here. For a clearer picture, use wireshark to open the capture, then expand the INVITE message(s), select the Call-ID field, right click, then use the "Colorize With Filter" option to change the colours of the 4 channels to make it easier to follow.

You won't see the incoming call in the capture, but the initial INVITE is a call to extension 6133 from Asterisk because of an incoming DID call. You can see the DID in the messages as 7144005263. Just realize that a left hand channel exists that you don't see. This will be noted as the "DID channel".
At the top of the capture is right "right hand" part of the call from the DID. This INVITE goes to 6133 and the call is answered.

6133 then attempts to perform a transfer. You can see the reINVITE to Asterisk placing the DID on hold. Then an INVITE is sent from 6133 to Asterisk, requesting extension 9772.

A call from Asterisk to two end points happens: USAS-x9772 and USAS-p9772-2.

The call to p9772 is rejected with a 486 Busy Here and the dialog then ends.

The call to x9772 (communicator) continues as normal. A 180 ringing is returned and is then passed back to the call initiated by 6133.
At this point, during ringing (blonde transfer) the 6133 then sends a REFER, referring the DID channel to be connected to the dialog being established from 6133.

At this point the REFER is 202 Accepted, and the initial call is torn down via BYE. All of this is normal.

However!

Asterisk then sends a 603 Declined against the INVITE that was placed by 6133 (the channel we're referring the DID channel to). At this point that dialog is then CANCEL'd and torn down. The call to 9772 is also town down at this point and a CANCEL is sent from x9772 and is ACK'd by Asterisk.

_(We believe the 603 Declined is a bug in Asterisk at this point, perhaps triggered because of the 486 Busy Here. Some additional testing to see if this is the scenario that causes the 603 to happen.)_

Now this is the interesting part. The connection from Asterisk to x9772 is torn down as well, leaving the DID channel in limbo. Asterisk then attempts to place two INVITEs to x9772 again (the second one is a retransmission due to 10ms of no response, perhaps communicator just ignores it the first time, but responds the second time?).

The INVITE is sent with the same from/to tags and same Call-ID of the INVITE that was initially sent to x9772 and responded to via 180 Ringing. Communicator then responds to the INVITE with a 100 Trying. At this point no further communications are had, and the call is left in permanent limbo in Asterisk due to a lack of Timer C to tear down the call.

We believe Communicator should not be responding with a 100 Trying here. Rather, it should respond with something else that declines the call as we're essentially performing a replay attack to the device since the Call-ID we're using should no longer be valid (due to call tear down).



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