Details

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

      Description

      Allows for Proxy application to terminate an established session by sending BYE requests in both directions as specified in 3GPP TS 24.229 section 5.2.8.1.2. It is not RFC3261 compliant behaviour as SIP proxies SHOULD NOT originate SIP requests so up for discussion

        Activity

        deruelle_jean created issue -
        binod made changes -
        Field Original Value New Value
        Assignee binod [ binod ]
        Hide
        binod added a comment - - edited

        Suggested method for this issue.

        /**

        • Returns a new BYE request. This method is used only by proxies that
        • need to be compliant with 3GPP specification section 5.2.8.1.2. Note
        • that this method does not exhibit strict compliance with RFC 3261 and
        • hence need to be used only for specific requirements.
          *
        • @param caller If this parameter is true, then the created BYE will
        • be targeted towards caller, otherwise, it will be targeted
        • towards callee.
          *
        • @return A new BYE request.
        • @throws IllegalStateException
        • if this <code>SipSession</code> has been invalidated or
        • if this <code>SipSession</code> is not in the CONFIRMED state or
        • if the session is not created on a proxy.
        • @since 2.0
          */
          SipServletRequest createBye(boolean caller);
        Show
        binod added a comment - - edited Suggested method for this issue. /** Returns a new BYE request. This method is used only by proxies that need to be compliant with 3GPP specification section 5.2.8.1.2. Note that this method does not exhibit strict compliance with RFC 3261 and hence need to be used only for specific requirements. * @param caller If this parameter is true, then the created BYE will be targeted towards caller, otherwise, it will be targeted towards callee. * @return A new BYE request. @throws IllegalStateException if this <code>SipSession</code> has been invalidated or if this <code>SipSession</code> is not in the CONFIRMED state or if the session is not created on a proxy. @since 2.0 */ SipServletRequest createBye(boolean caller);
        Hide
        tomrstrickland added a comment -

        I assume that this method is on SipSession?

        What is wrong with SipSession.terminate(...)?
        Or SipSession.createRequest(...) if you want to only terminate a usage?

        Show
        tomrstrickland added a comment - I assume that this method is on SipSession? What is wrong with SipSession.terminate(...)? Or SipSession.createRequest(...) if you want to only terminate a usage?
        Hide
        binod added a comment -

        Yep, it is on SipSession.

        1. SipSession.terminateDialog (I assume you mean that...)
        As per the 3GPP specification, it look like, some times the BYE need to be sent to both sides and some times only to one side.
        Also, there are a bunch of 3GPP specific changes that need to be done to the message. So, including these usecases, I thought, make the
        terminateDialog convoluted.

        2. SipSession.createRequest

        This is an option that may work as well. However, since we are not allowing proxy to create other subsequent requests and also, proxy app need
        a way to get more than one BYE request (to either direction), it appeared better to use a different method.

        Show
        binod added a comment - Yep, it is on SipSession. 1. SipSession.terminateDialog (I assume you mean that...) As per the 3GPP specification, it look like, some times the BYE need to be sent to both sides and some times only to one side. Also, there are a bunch of 3GPP specific changes that need to be done to the message. So, including these usecases, I thought, make the terminateDialog convoluted. 2. SipSession.createRequest This is an option that may work as well. However, since we are not allowing proxy to create other subsequent requests and also, proxy app need a way to get more than one BYE request (to either direction), it appeared better to use a different method.
        Hide
        tomrstrickland added a comment -

        I've skimmed 3GPP TS 24.229 version 11.9.0 Release 11 (Oct 2013):
        http://www.etsi.org/deliver/etsi_ts/124200_124299/124229/11.09.00_60/ts_124229v110900p.pdf

        I can see that the 3GPP wants to be able to send BYE in one or other direction. What will this mean from the container writer's point-of-view? Issues:

        1. If we send a BYE to the caller (or vice-versa: send a BYE to the callee), I assume that we just wipe the SipSession and that there is nothing left to do with the callee's side? We need to state what happens with regard to lifecycle here.

        2. This says nothing about SUBSCRIBE usage(s).

        3. This is more constrained that the terminate method: it only works in the CONFIRMED state. As an app writer, I would like to be able to get rid of a proxy session regardless of its state. This is a very useful addition to the app-writer's set of tools: I can write a proxy that can tear down calls. This would considerably simplify apps that would otherwise require a B2BUA.

        Perhaps you could consider the following alternative:

        void SipSession.terminateProxiedDialog(ProxyTerminationDirection)
        void SipSession.terminateProxiedDialog(ProxyTerminationDirection, AutomaticProcessingListener listener)

        /**

        • Terminates a SIP dialog that has been proxied. This behaviour breaks RFC
        • 3261, as a SIP proxy MUST NOT create and send requests down an
        • established dialog. However, some 3GPP applications need this ability
        • (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session).
        • Furthermore, there are many other SIP proxy implementations that break
        • this rule. Some applications are only be written as a B2BUA in order to
        • be able to later tear down the dialog, and since B2BUA applications are
        • much harder to write correctly than a proyx, then it may sometimes be
        • better to write a proxy that breaks this rule. Given the way that this
        • method breaks RFC 3261, this method should be used with caution and any
        • application that uses it should be carefully tested.
        • @param ProxyTerminationDirection the direction(s) in which messages must be sent in order to terminate the dialog.
          */
          void SipSession.terminateProxiedDialog(ProxyTerminationDirection)

        /**

        • Terminates a SIP dialog that has been proxied. This behaviour breaks RFC
        • 3261, as a SIP proxy MUST NOT create and send requests down an
        • established dialog. However, some 3GPP applications need this ability
        • (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session).
        • Furthermore, there are many other SIP proxy implementations that break
        • this rule. Some applications are only be written as a B2BUA in order to
        • be able to later tear down the dialog, and since B2BUA applications are
        • much harder to write correctly than a proyx, then it may sometimes be
        • better to write a proxy that breaks this rule. Given the way that this
        • method breaks RFC 3261, this method should be used with caution and any
        • application that uses it should be carefully tested.
        • @param ProxyTerminationDirection the direction(s) in which messages must be sent in order to terminate the dialog.
        • @param AutomaticProcessingListener Instance of AutomaticProcessingListener.
        • @since 2.0
          */
          void SipSession.terminateProxiedDialog(ProxyTerminationDirection, AutomaticProcessingListener listener)

        Self-explanatory:
        ProxyTerminationDirection enum:
        CALLER
        CALLEE
        CALLER_AND_CALLEE

        Show
        tomrstrickland added a comment - I've skimmed 3GPP TS 24.229 version 11.9.0 Release 11 (Oct 2013): http://www.etsi.org/deliver/etsi_ts/124200_124299/124229/11.09.00_60/ts_124229v110900p.pdf I can see that the 3GPP wants to be able to send BYE in one or other direction. What will this mean from the container writer's point-of-view? Issues: 1. If we send a BYE to the caller (or vice-versa: send a BYE to the callee), I assume that we just wipe the SipSession and that there is nothing left to do with the callee's side? We need to state what happens with regard to lifecycle here. 2. This says nothing about SUBSCRIBE usage(s). 3. This is more constrained that the terminate method: it only works in the CONFIRMED state. As an app writer, I would like to be able to get rid of a proxy session regardless of its state. This is a very useful addition to the app-writer's set of tools: I can write a proxy that can tear down calls. This would considerably simplify apps that would otherwise require a B2BUA. Perhaps you could consider the following alternative: void SipSession.terminateProxiedDialog(ProxyTerminationDirection) void SipSession.terminateProxiedDialog(ProxyTerminationDirection, AutomaticProcessingListener listener) /** Terminates a SIP dialog that has been proxied. This behaviour breaks RFC 3261, as a SIP proxy MUST NOT create and send requests down an established dialog. However, some 3GPP applications need this ability (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session). Furthermore, there are many other SIP proxy implementations that break this rule. Some applications are only be written as a B2BUA in order to be able to later tear down the dialog, and since B2BUA applications are much harder to write correctly than a proyx, then it may sometimes be better to write a proxy that breaks this rule. Given the way that this method breaks RFC 3261, this method should be used with caution and any application that uses it should be carefully tested. @param ProxyTerminationDirection the direction(s) in which messages must be sent in order to terminate the dialog. */ void SipSession.terminateProxiedDialog(ProxyTerminationDirection) /** Terminates a SIP dialog that has been proxied. This behaviour breaks RFC 3261, as a SIP proxy MUST NOT create and send requests down an established dialog. However, some 3GPP applications need this ability (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session). Furthermore, there are many other SIP proxy implementations that break this rule. Some applications are only be written as a B2BUA in order to be able to later tear down the dialog, and since B2BUA applications are much harder to write correctly than a proyx, then it may sometimes be better to write a proxy that breaks this rule. Given the way that this method breaks RFC 3261, this method should be used with caution and any application that uses it should be carefully tested. @param ProxyTerminationDirection the direction(s) in which messages must be sent in order to terminate the dialog. @param AutomaticProcessingListener Instance of AutomaticProcessingListener. @since 2.0 */ void SipSession.terminateProxiedDialog(ProxyTerminationDirection, AutomaticProcessingListener listener) Self-explanatory: ProxyTerminationDirection enum: CALLER CALLEE CALLER_AND_CALLEE
        Hide
        jonbo372 added a comment -

        I agree with Tom on having a SipSession.terminateProxiedDialog rather then createBye since Tom's suggestion goes well in hand with the SipSession.Terminate concept. Also, I'm afraid that the createBye can more easily be misunderstood since application developers are commonly creating and sending BYEs and therefore having a more explicit method will hopefully make developers actually read the javadoc before using the method instead of just assuming they know what it does.

        Show
        jonbo372 added a comment - I agree with Tom on having a SipSession.terminateProxiedDialog rather then createBye since Tom's suggestion goes well in hand with the SipSession.Terminate concept. Also, I'm afraid that the createBye can more easily be misunderstood since application developers are commonly creating and sending BYEs and therefore having a more explicit method will hopefully make developers actually read the javadoc before using the method instead of just assuming they know what it does.
        Hide
        binod added a comment -

        After the EG discussions, we decided to support all usages. Also decided to use UAMode
        instead of ProxyTerminationDirection. Here are the updated apis. Note that I omitted a
        sentence explicitly encouraging usage outside the 3GPP requirements.

        /**

        • Terminates a SIP dialog that has been proxied. This behaviour breaks RFC
        • 3261, as a SIP proxy MUST NOT create and send requests down an
        • established dialog. However, some 3GPP applications need this ability
        • (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session).
        • Given the way that this
        • method breaks RFC 3261, this method should be used with caution and any
        • application that uses it should be carefully tested.
          *
        • @throws IllegalStateException If this method is called when the
        • dialog termination has already been initiated or if the session
        • is created by any SIP method that does not establish a dialog.
        • @since 2.0
          */
          void terminateProxiedDialog();

        /**

        • Terminates a SIP dialog that has been proxied. This behaviour breaks RFC
        • 3261, as a SIP proxy MUST NOT create and send requests down an
        • established dialog. However, some 3GPP applications need this ability
        • (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session).
        • Given the way that this method breaks RFC 3261, this method should be used
        • with caution and any application that uses it should be carefully tested.
          *
        • @param listener Instance of AutomaticProcessingListener.
        • @throws IllegalStateException If this method is called when the
        • dialog termination has already been initiated or if the session
        • is created by any SIP method that does not establish a dialog.
        • @since 2.0
          */
          void terminateProxiedDialog(AutomaticProcessingListener listener);

        /**

        • Terminates a SIP dialog that has been proxied. This behaviour breaks RFC
        • 3261, as a SIP proxy MUST NOT create and send requests down an
        • established dialog. However, some 3GPP applications need this ability
        • (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session).
        • Given the way that this
        • method breaks RFC 3261, this method should be used with caution and any
        • application that uses it should be carefully tested.
          *
        • @param direction the direction in which messages must be sent in order to terminate the dialog.
        • @throws IllegalStateException If this method is called when the
        • dialog termination has already been initiated or if the session
        • is created by any SIP method that does not establish a dialog.
        • @since 2.0
          */
          void terminateProxiedDialog(UAMode direction);

        /**

        • Terminates a SIP dialog that has been proxied. This behaviour breaks RFC
        • 3261, as a SIP proxy MUST NOT create and send requests down an
        • established dialog. However, some 3GPP applications need this ability
        • (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session).
        • Given the way that this method breaks RFC 3261, this method should be used
        • with caution and any application that uses it should be carefully tested.
          *
        • @param direction the direction in which messages must be sent in order to terminate the dialog.
        • @param listener Instance of AutomaticProcessingListener.
        • @throws IllegalStateException If this method is called when the
        • dialog termination has already been initiated or if the session
        • is created by any SIP method that does not establish a dialog.
        • @since 2.0
          */
          void terminateProxiedDialog(UAMode direction, AutomaticProcessingListener listener);
        Show
        binod added a comment - After the EG discussions, we decided to support all usages. Also decided to use UAMode instead of ProxyTerminationDirection. Here are the updated apis. Note that I omitted a sentence explicitly encouraging usage outside the 3GPP requirements. /** Terminates a SIP dialog that has been proxied. This behaviour breaks RFC 3261, as a SIP proxy MUST NOT create and send requests down an established dialog. However, some 3GPP applications need this ability (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session). Given the way that this method breaks RFC 3261, this method should be used with caution and any application that uses it should be carefully tested. * @throws IllegalStateException If this method is called when the dialog termination has already been initiated or if the session is created by any SIP method that does not establish a dialog. @since 2.0 */ void terminateProxiedDialog(); /** Terminates a SIP dialog that has been proxied. This behaviour breaks RFC 3261, as a SIP proxy MUST NOT create and send requests down an established dialog. However, some 3GPP applications need this ability (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session). Given the way that this method breaks RFC 3261, this method should be used with caution and any application that uses it should be carefully tested. * @param listener Instance of AutomaticProcessingListener. @throws IllegalStateException If this method is called when the dialog termination has already been initiated or if the session is created by any SIP method that does not establish a dialog. @since 2.0 */ void terminateProxiedDialog(AutomaticProcessingListener listener); /** Terminates a SIP dialog that has been proxied. This behaviour breaks RFC 3261, as a SIP proxy MUST NOT create and send requests down an established dialog. However, some 3GPP applications need this ability (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session). Given the way that this method breaks RFC 3261, this method should be used with caution and any application that uses it should be carefully tested. * @param direction the direction in which messages must be sent in order to terminate the dialog. @throws IllegalStateException If this method is called when the dialog termination has already been initiated or if the session is created by any SIP method that does not establish a dialog. @since 2.0 */ void terminateProxiedDialog(UAMode direction); /** Terminates a SIP dialog that has been proxied. This behaviour breaks RFC 3261, as a SIP proxy MUST NOT create and send requests down an established dialog. However, some 3GPP applications need this ability (see 3GPP TS 24.229 section 5.2.8.1.2 Release of an existing session). Given the way that this method breaks RFC 3261, this method should be used with caution and any application that uses it should be carefully tested. * @param direction the direction in which messages must be sent in order to terminate the dialog. @param listener Instance of AutomaticProcessingListener. @throws IllegalStateException If this method is called when the dialog termination has already been initiated or if the session is created by any SIP method that does not establish a dialog. @since 2.0 */ void terminateProxiedDialog(UAMode direction, AutomaticProcessingListener listener);
        binod made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.0-pr [ 16895 ]
        Resolution Fixed [ 1 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: