Topic
  • 4 replies
  • Latest Post - ‏2011-06-19T06:53:55Z by SystemAdmin
cheungda
cheungda
20 Posts

Pinned topic Container invalidates session after 302

‏2011-06-15T18:45:24Z |
Hi,

I'm resurrecting a discussion that was buried inside a previous thread. In JSR289, when setInvalidateWhenReady is true, the container invalidates the session when receiving a 302. Is there a reason for this behaviour? According to RFC3665, the call flow example suggests the next INVITE after 302 can be sent on the same session.

If the implemented behaviour is to always clean up on a non-2xx response, would I see the same thing happen on a 422 Session Interval Too Small or a 491 Request Pending ? I would not expect the session to be invalidated after receiving these, but just want to confirm.

Perhaps a follow-up question could be, is it possible selectively auto invalidate?

Thanks
Darryl Cheung
Updated on 2011-06-19T06:53:55Z at 2011-06-19T06:53:55Z by SystemAdmin
  • cheungda
    cheungda
    20 Posts

    Re: Container invalidates session after 302

    ‏2011-06-15T18:47:32Z  
    And I recall one option was to setInvalidateWhenReady(false) which does prevent the 302 from being invalidated, but would prefer to use the container default as it does a better job at cleaning up sessions for the most part.

    Darryl
  • SystemAdmin
    SystemAdmin
    45 Posts

    Re: Container invalidates session after 302

    ‏2011-06-16T08:39:41Z  
    • cheungda
    • ‏2011-06-15T18:47:32Z
    And I recall one option was to setInvalidateWhenReady(false) which does prevent the 302 from being invalidated, but would prefer to use the container default as it does a better job at cleaning up sessions for the most part.

    Darryl
    According to JSR 289 section 6.2.4.1.2 the container determines the SIpSession to be in a ready-to-invalidate state if:
    A SipSession acting as a UAC transitions from the EARLY state back to the INITIAL state on account of receiving a non-2xx final response (6.2.1 Relationship to SIP Dialogs, point 4) and has not initiated any new requests (does not have any pending transactions).

    This explains why the sip session is moving to ready to invalidate if 3xx-6xx response is received on an initial request. (if you do not have outgoing transactions)

    Section 6.2.4.1.2 also explains how the application can register a listener that will be invoked when any session is ready to invalidate, when the listener is invoked you can choose to stop the automatic invalidation.
  • cheungda
    cheungda
    20 Posts

    Re: Container invalidates session after 302

    ‏2011-06-16T15:31:43Z  
    According to JSR 289 section 6.2.4.1.2 the container determines the SIpSession to be in a ready-to-invalidate state if:
    A SipSession acting as a UAC transitions from the EARLY state back to the INITIAL state on account of receiving a non-2xx final response (6.2.1 Relationship to SIP Dialogs, point 4) and has not initiated any new requests (does not have any pending transactions).

    This explains why the sip session is moving to ready to invalidate if 3xx-6xx response is received on an initial request. (if you do not have outgoing transactions)

    Section 6.2.4.1.2 also explains how the application can register a listener that will be invoked when any session is ready to invalidate, when the listener is invoked you can choose to stop the automatic invalidation.
    I looked at 6.2.1 in the JSR289 spec and it lines up with you said. Also, it says that

    When a UAC receives a 3xx for a request initiated outside of a dialog and decides to retry with the
    Contact addresses received in the 3xx, it is recommended to reuse the same To, From and Call-ID for
    the new request http://RFC 3261, section 8.1.3.4.

    Our application overrides the doRedirectResponse() but hands off call logic processing to another thread, letting the SipContainer thread return. If I created a new INVITE transaction before letting the doRedirectResponse() return, would this prevent the session from being invalidated?
  • SystemAdmin
    SystemAdmin
    45 Posts

    Re: Container invalidates session after 302

    ‏2011-06-19T06:53:55Z  
    • cheungda
    • ‏2011-06-16T15:31:43Z
    I looked at 6.2.1 in the JSR289 spec and it lines up with you said. Also, it says that

    When a UAC receives a 3xx for a request initiated outside of a dialog and decides to retry with the
    Contact addresses received in the 3xx, it is recommended to reuse the same To, From and Call-ID for
    the new request http://RFC 3261, section 8.1.3.4.

    Our application overrides the doRedirectResponse() but hands off call logic processing to another thread, letting the SipContainer thread return. If I created a new INVITE transaction before letting the doRedirectResponse() return, would this prevent the session from being invalidated?
    Yes, if the doRedirectResponse() is creating a new outgoing request the ready to invalidate should not get called since there are open transaction on this session (according to the RFC)