Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: milestone 1
    • Component/s: doc
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,508

      Description

      The release notes could say something like this:

      The extension of the lifetime of the SipApplicationSession works the same as it
      did in JSR-116. This means that the application is in control over the duration
      of the SipApplicationSession, subject to approval by the container. In the
      setExpires the application indicates the time when the SipApplicationSession
      should expire relative to the moment the setExpires is called. The container can
      modify, reject or accept the duration indicated in the setExpires. If the
      session is not invalidated, then x minutes after the last setExpires was invoked
      the sessionExpired callback is performed. In this callback the application can
      try to extend the duration of the SipApplicationSession by invoking a new
      setExpires(), again subject to modification, rejection or acceptance by the
      container.

      This model is different from the HTTP expiration time logic. In HTTP the session
      is automatically extended, outside of the control of the application, whenever a
      new HTTP request is received in that HTTP session.
      For this reason, converged applications that start out with the same expiration
      time of the SipApplicationSession and on the HTTP session will notice that the
      SAS might timeout before the HTTP session if new requests were received on the
      HTTP session.

      The best way to deal with the different expiration time handling of the
      SipApplicationSession and the HTTPSession is to start with a large enough
      SipApplicationSession expiration time, i.e., the total time that the application
      session is expected to live (which might include several HTTP requests).
      The SipApplicationSession lifetime might even be set to infinite, specifically
      if there invalidateWhenReady semantics are used, in which case the
      SipApplicationSession will be invalidated when the last protocol child session
      becomes invaldated.
      The initial expiration time for the SipApplicationSession can be configured in
      the deployment descriptor.

      If the maximum total duration can be estimated in advance, no further code is
      needed, as it is then alright to invalidate both the SipApplicationSession and
      the HTTPSession when the SipApplicationSession expires.

      If maximum the duration can not be estimated in advance, then the
      SipApplicationSession can be extended when it expires, as shown in the code
      snippet below.
      In the SipApplicationSessionListener implementation do something like this:

      public void sessionExpired(SipApplicationSessionEvent sasEvent) {
      // check if the SAS needs to be extended first, if so:
      int granted = sasEvent.getApplicationSession().setExpires(2);
      if (granted <= 0)

      { System.out.println("extension rejected"); }

      else if (granted < 2)

      { System.out.println("extension granted with lower value " + granted); }

      // else allowed
      }

        Issue Links

          Activity

          Hide
          erikvandervelden added a comment -

          added dependancy

          Show
          erikvandervelden added a comment - added dependancy
          Hide
          prasads added a comment -

          Re-assigning to Chinmayee

          Show
          prasads added a comment - Re-assigning to Chinmayee
          Hide
          chinmayee_srivathsa added a comment -

          Needs to be release noted

          Show
          chinmayee_srivathsa added a comment - Needs to be release noted
          Hide
          chinmayee_srivathsa added a comment -

          see page 13 in the attached file

          Show
          chinmayee_srivathsa added a comment - see page 13 in the attached file

            People

            • Assignee:
              chinmayee_srivathsa
              Reporter:
              erikvandervelden
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: