[SIPForum-discussion] Bye Method

[Zulaloglu, John]

While Pablo’s answer is correct with his use of the word “should”; another gent, Paul’s comment about this “not being forbidden” is also correct.

I need to learn to use the word “should” more frequently to avoid making incomplete and sometimes inaccurate statements.

This is a scenario where you “can” use BYE request but “should” use CANCEL request instead:

-User A calls user B…
-B responds with 180 Ringing with the “To” header field having a tag, which means an “early dialog” is established
-B has not responded with a final response yet, the dialog is neither confirmed nor terminated, we are still in the “early dialog” phase
-Now the caller (user A) “can” send a BYE request to the called party (user B) but “should” send CANCEL request instead
-Called party (user B) “cannot” send a BYE request to the caller (user A) during early dialog

The 3 parts from the RFC 3261 reference Pablo made below could be used to confirm that you “can” use BYE request after receiving a 180 Ringing response in the scenario above.

“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.
“
“The impact of a non-2xx final response to INVITE on dialogs and
   sessions makes the use of CANCEL attractive. “

“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. “



John Zülaloğlu | Sr. Communication Services Engineer | [cid:image001.jpg at 01CACA7E.46C44B80]  | Voice 214.387.2602

From: Zulaloglu, John
Sent: Saturday, July 04, 2015 9:18 PM
To: Valencia Diaz Pablo; Suman Mohanty; discussion at sipforum.org
Cc: Zulaloglu, John
Subject: RE: [SIPForum-discussion] Bye Method

+1

Unless anyone can produce an exception with references to solid data, I’d suggest going with Pablo’s answer.

If you send a BYE request for a call that has not been established with a final response, you should receive a 481 Call/Transaction Does Not Exist response as explained in the following youtube video: https://youtu.be/vCDUR2PgerA?t=48m8s

If you receive a 180 Ringing response and hang up before the call is answered, you will send out a CANCEL request (not a BYE request) as demonstrated in the following example: https://youtu.be/Rruqwe3kAWU?t=1m5s

Thanks,
John Zülaloğlu | Sr. Communication Services Engineer | [cid:image001.jpg at 01CACA7E.46C44B80]  | Voice 214.387.2602

From: discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org> [mailto:discussion-bounces at sipforum.org] On Behalf Of Valencia Diaz Pablo
Sent: Tuesday, June 30, 2015 2:14 PM
To: Suman Mohanty; discussion at sipforum.org<mailto:discussion at sipforum.org>
Subject: Re: [SIPForum-discussion] Bye Method

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> [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<mailto: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/20150711/7c1cd75e/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1156 bytes
Desc: image001.jpg
URL: <http://sipforum.org/pipermail/discussion/attachments/20150711/7c1cd75e/attachment-0002.jpg>