[SIPForum-discussion] Bye Method

[Valencia Diaz Pablo]

Hi Suman.

I think you shouldn’t send a Bye method if your haven’t received a Final (2XX) response. (RFC 3261 section 15)
       “this would imply a
      CANCEL request if the initial INVITE has not generated a final
      response, and a BYE to all confirmed dialogs after a final
      response.”

You should send a CANCEL instead.

BR

Pablo Valencia


15 Terminating a Session

   This section describes the procedures for terminating a session
   established by SIP.  The state of the session and the state of the
   dialog are very closely related.  When a session is initiated with an
   INVITE, each 1xx or 2xx response from a distinct UAS creates a
   dialog, and if that response completes the offer/answer exchange, it
   also creates a session.  As a result, each session is "associated"
   with a single dialog - the one which resulted in its creation.  If an
   initial INVITE generates a non-2xx final response, that terminates
   all sessions (if any) and all dialogs (if any) that were created
   through responses to the request.  By virtue of completing the
   transaction, a non-2xx final response also prevents further sessions
   from being created as a result of the INVITE.  The BYE request is
   used to terminate a specific session or attempted session.  In this
   case, the specific session is the one with the peer UA on the other
   side of the dialog.  When a BYE is received on a dialog, any session
   associated with that dialog SHOULD terminate.  A UA MUST NOT send a
   BYE outside of a dialog.  The caller's UA MAY send a BYE for either
   confirmed or early dialogs, and the callee's UA MAY send a BYE on
   confirmed dialogs, but MUST NOT send a BYE on early dialogs.

   However, the callee's UA MUST NOT send a BYE on a confirmed dialog
   until it has received an ACK for its 2xx response or until the server
   transaction times out.  If no SIP extensions have defined other
   application layer states associated with the dialog, the BYE also
   terminates the dialog.

   The impact of a non-2xx final response to INVITE on dialogs and
   sessions makes the use of CANCEL attractive.  The CANCEL attempts to
   force a non-2xx response to the INVITE (in particular, a 487).
   Therefore, if a UAC wishes to give up on its call attempt entirely,
   it can send a CANCEL.  If the INVITE results in 2xx final response(s)
   to the INVITE, this means that a UAS accepted the invitation while
   the CANCEL was in progress.  The UAC MAY continue with the sessions
   established by any 2xx responses, or MAY terminate them with BYE.

      The notion of "hanging up" is not well defined within SIP.  It is
      specific to a particular, albeit common, user interface.
      Typically, when the user hangs up, it indicates a desire to
      terminate the attempt to establish a session, and to terminate any
      sessions already created.  For the caller's UA, this would imply a
      CANCEL request if the initial INVITE has not generated a final
      response, and a BYE to all confirmed dialogs after a final
      response.  For the callee's UA, it would typically imply a BYE;
      presumably, when the user picked up the phone, a 2xx was
      generated, and so hanging up would result in a BYE after the ACK
      is received.  This does not mean a user cannot hang up before
      receipt of the ACK, it just means that the software in his phone
      needs to maintain state for a short while in order to clean up
      properly.  If the particular UI allows for the user to reject a
      call before its answered, a 403 (Forbidden) is a good way to
      express that.  As per the rules above, a BYE can't be sent.


De: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] En nombre de Suman Mohanty
Enviado el: viernes, 19 de junio de 2015 16:39
Para: discussion at sipforum.org
Asunto: [SIPForum-discussion] Bye Method


Hi All,

    Can anyone explains  in which scenario we can send bye message after receiving the 180 ringing?

Regards,
Suman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20150630/d9f86655/attachment-0002.html>