sailfin
  1. sailfin
  2. SAILFIN-1911

NOTIFY with "Subscription-State: terminated" terminates session when not appropriate

    Details

    • Issuezilla Id:
      1,911

      Description

      See for details:
      http://www.nabble.com/Possible-bug-in-blind-transfers-ts24645377.html

      "After sending the 200 OK to the NOTIFY, Sailfin is not allowed to send a BYE to
      terminate the dialog created by the initial INVITE because the session has
      already been invalidated. I don't think the session should transition to the
      TERMINATED state after receiving the NOTIFY with the Subscription-State:
      terminated, if there are still usages of the dialog in use (the invite usage)."

        Activity

        Hide
        haukex added a comment -

        Note that the current workaround I'm using is to simply not send the
        Subscription-State header, even though this is a "must" in RFC3265.

        Show
        haukex added a comment - Note that the current workaround I'm using is to simply not send the Subscription-State header, even though this is a "must" in RFC3265.
        Hide
        binod added a comment -

        Transferring to Bhavani

        Show
        binod added a comment - Transferring to Bhavani
        Hide
        haukex added a comment -

        bump... we are having the problem with a different UA that is sending us NOTIFYs
        where the code is not under our control, so the workaround (which is not very
        clean anyways) does not apply anymore.

        Show
        haukex added a comment - bump... we are having the problem with a different UA that is sending us NOTIFYs where the code is not under our control, so the workaround (which is not very clean anyways) does not apply anymore.
        Hide
        haukex added a comment -

        Analysis:

        RFC3265 (SUBSCRIBE/NOTIFY) section 3.3.4 specifies that the ending of a
        subscription does not necessarily imply the ending of the dialog, as is the case
        here, as the dialog was established with an INVITE and that has not yet been
        terminated.

        There are two points in the code where a NOTIFY with "Subscription-State:
        terminated" causes the SipSession to go to TERMINATED:

        1. When the NOTIFY is sent, in
        com.ericsson.ssa.sip.SipSessionImplBase.updateSipSessionState(SipServletRequest,
        PathNode.Type)

        2. When the 200 OK for the NOTIFY is received, in
        SipSessionImplBase.updateSipSessionState(SipServletResponse, PathNode.Type)

        These places in the code should not be unconditionally setting the session state
        to TERMINATED, instead they should be checking if there are further uses for the
        session, such as other subscriptions or an INVITE application state.

        However, unless I'm missing something, at the above places in the code I don't
        see any state variables that would indicate that there is still an INVITE
        transaction active. It seems the source of the problem occurs much earlier, in
        com.ericsson.ssa.sip.UA.getFSM(SipServletMessage), where a single FSM is picked
        based solely on the request method, and it seems that the SUBSCRIBE_REFERSession
        does not have any knowledge of the other INVITESession.

        Another point, it seems
        com.ericsson.ssa.sip.SUBSCRIBE_REFERSession.isNotifyTerminatedState(SipServletMessage)
        does not work properly. It returns false when "Subscription-State:
        terminated;reason=noresource", which is the header as required by the REFER RFC.

        I actually see some commented out code and TODO's in UA.java that refers to
        "multidialogs e.g. within a subscribe session" and such things, with references
        "Not implemented, optimization for application pgm" ... ?

        Used code from b30 promoted.

        Show
        haukex added a comment - Analysis: RFC3265 (SUBSCRIBE/NOTIFY) section 3.3.4 specifies that the ending of a subscription does not necessarily imply the ending of the dialog, as is the case here, as the dialog was established with an INVITE and that has not yet been terminated. There are two points in the code where a NOTIFY with "Subscription-State: terminated" causes the SipSession to go to TERMINATED: 1. When the NOTIFY is sent, in com.ericsson.ssa.sip.SipSessionImplBase.updateSipSessionState(SipServletRequest, PathNode.Type) 2. When the 200 OK for the NOTIFY is received, in SipSessionImplBase.updateSipSessionState(SipServletResponse, PathNode.Type) These places in the code should not be unconditionally setting the session state to TERMINATED, instead they should be checking if there are further uses for the session, such as other subscriptions or an INVITE application state. However, unless I'm missing something, at the above places in the code I don't see any state variables that would indicate that there is still an INVITE transaction active. It seems the source of the problem occurs much earlier, in com.ericsson.ssa.sip.UA.getFSM(SipServletMessage), where a single FSM is picked based solely on the request method, and it seems that the SUBSCRIBE_REFERSession does not have any knowledge of the other INVITESession. Another point, it seems com.ericsson.ssa.sip.SUBSCRIBE_REFERSession.isNotifyTerminatedState(SipServletMessage) does not work properly. It returns false when "Subscription-State: terminated;reason=noresource", which is the header as required by the REFER RFC. I actually see some commented out code and TODO's in UA.java that refers to "multidialogs e.g. within a subscribe session" and such things, with references "Not implemented, optimization for application pgm" ... ? Used code from b30 promoted.
        Hide
        haukex added a comment -

        This apparently also occurs when SailFin is acting as a proxy.

        Show
        haukex added a comment - This apparently also occurs when SailFin is acting as a proxy.
        Show
        Bhavanishankar added a comment - Added a regression test case for this : https://sailfin.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=7603 https://sailfin.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=7604
        Show
        Bhavanishankar added a comment - Fix in TRUNK: https://sailfin.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=7617 https://sailfin.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=7618 (ssr test change) Fix in 2.0 branch: https://sailfin.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=7621 https://sailfin.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=7622 (ssr test change) Added a regression test case in 2.0 branch : https://sailfin.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=7623

          People

          • Assignee:
            Bhavanishankar
            Reporter:
            haukex
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: