sipservlet-spec
  1. sipservlet-spec
  2. SIPSERVLET_SPEC-21

Clarification on when the container is responsible for invalidating derived sessions.

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-pr
    • Labels:
      None

      Description

      Example:
      INVITE is proxied and forked by something downstream.
      Several 1xx responses are received with different to-tags
      A 2xx is received.

      What happens to the derived sessions with to-tags that don't match the one in the 2xx? It's not clear from the standard who should invalidate them. Since there is also the possibility of a race condition at the downstream proxy where you could get multiple 2xx responses it's not clear that invalidating all the other sessions except the one for which you get the 2xx is the right thing to do.

      The other case is receiving only final error responses because its not clear from the standard if its OK at that point to go ahead and invalidate the associated derived sessions.

        Activity

        Hide
        binod added a comment -

        Here is some proposed rules to cover the derived session invalidation situations.

        • If the servlet act as UAC, when non-2XX final response is received , all sessions , on EARLY or INITIAL state,
          in the same forking context (as specified in section 8.2.6 Forking and SipSessions) also return to INITIAL state
        • If the servlet act as UAC, if 2xx final response for INVITE is received and subsequently when the transaction timer M fires
          as per RFC 6026, all sessions , on EARLY or INITIAL state, in the same forking context (as specified in section 8.2.6 Forking and SipSessions)
          transitions to TERMINATED state.
        • If the servlet act as Proxy, when a non-2xx final response is forwarded as the best response, all sessions , on EARLY or INITIAL state,
          in the same forking context (as specified in section 8.2.6 Forking and SipSessions) transitions to TERMINATED state.
        • If the servlet act as a Proxy and if a 2xx final response for INVITE request is forwarded as best response and
          subsequently when the transaction timer M fires as per RFC 6026, all sessions, on EARLY or INITIAL state,
          in the same forking context (as specified in section 8.2.6 Forking and SipSessions) transitions to TERMINATED state.
        Show
        binod added a comment - Here is some proposed rules to cover the derived session invalidation situations. If the servlet act as UAC, when non-2XX final response is received , all sessions , on EARLY or INITIAL state, in the same forking context (as specified in section 8.2.6 Forking and SipSessions) also return to INITIAL state If the servlet act as UAC, if 2xx final response for INVITE is received and subsequently when the transaction timer M fires as per RFC 6026, all sessions , on EARLY or INITIAL state, in the same forking context (as specified in section 8.2.6 Forking and SipSessions) transitions to TERMINATED state. If the servlet act as Proxy, when a non-2xx final response is forwarded as the best response, all sessions , on EARLY or INITIAL state, in the same forking context (as specified in section 8.2.6 Forking and SipSessions) transitions to TERMINATED state. If the servlet act as a Proxy and if a 2xx final response for INVITE request is forwarded as best response and subsequently when the transaction timer M fires as per RFC 6026, all sessions, on EARLY or INITIAL state, in the same forking context (as specified in section 8.2.6 Forking and SipSessions) transitions to TERMINATED state.
        Hide
        binod added a comment -

        Fixed in the latest draft distributed to EG (0.9)

        Show
        binod added a comment - Fixed in the latest draft distributed to EG (0.9)

          People

          • Assignee:
            binod
            Reporter:
            bpulito
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: