[SIPForum-discussion] Bye Method
Paul Kyzivat
pkyzivat at alum.mit.edu
Tue Jul 21 12:54:18 UTC 2015
I just noticed I never responded to this.
On 7/11/15 1:41 AM, Zulaloglu, John wrote:
> 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
Again, as I already said, whether "should" is appropriate depends on
user A's intent.
If A no longer wants any session, then CANCEL is the best choice.
If A is not interested in a session with the particular UA that has
responded, but might still be interested in a session with some other
answering UA, then BYE would be better.
Of course, this latter case usually only arises if A has already also
received a provisional response from another UA. But even if this is not
the case, it is *possible* that a response will come later from another
fork. It is even possible that there is a serial forking proxy won't try
another UA until the first one gives up.
You can't use CANCEL in this case because CANCEL is hop by hop - it
can't be sent *within* a particular early dialog.
But these are obscure cases. Most UAs don't have a UI rich enough for
the user to indicate a preference for such nuances.
Thanks,
Paul
> -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
>
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
More information about the discussion
mailing list