[SIPForum-discussion] BYE during setup phase

[shash]

BYE should have some C-Seq, Call-ID, these parameter's should identify this
BYE corrosponding to a dialog !


In below case dialog is not yet established as 2XX response is not yet
received by the UAC. 

RFC states 

<Quote>

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

</Unquote>

Most probable respnse from UAS in below case should be 6XX. thoughts !!! :)



Regards
Shash









"Devaraja G M" <devrajgm at techmahindra.com> wrote:
>
>Hi Anshu,
>
>If  UAC send BYE during calll setup phase then what would be the
>response for BYE method. 
>Scenario is:- 
>
>UAC                                        UAS, 
>
>INVITE- - -- - - --- -- - - - -- - - -- - - -- -> 
><- - - -- - - - -- - - ---- - - -- - -- --- - -- - - 100 Trying 
><- - - -- - - - -- - - ---- - - -- - -- --- - -- - - 180 Ringing 
>BYE  - -- - - --- -- - - - -- - - -- - - -- ->
>
> 
>
>Answer (rfc 3261 : section : 15)
>
> 
>
>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.
>
>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.
>
> 
>
>Note : 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.
>
> 
>
>A UAS first processes the BYE request according to the general UAS
>processing described in Section 8.2.
>
>A UAS core receiving a BYE request checks if it matches an existing
>dialog. If the BYE does not match an
>
>existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction
>Does Not Exist) response and pass
>
>that to the server transaction. This rule means that a BYE sent without
>tags by a UAC will be rejected.
>
> 
>
>In the early dialog establishment, it is better to send Cancel for the
>above scenario, if  we send BYE instead of Cancel, then UAS should send
>4XX Response ( It should be 481 response code (Call/Transaction Does Not
>Exist))
>
> 
>
> 
>
>Regards,
>
>Devaraj G.M
>
>________________________________
>
>From: discussion-bounces at sipforum.org
>[mailto:discussion-bounces at sipforum.org] On Behalf Of Anshupriya Nayak
>Sent: Thursday, September 06, 2007 9:18 AM
>To: discussion at sipforum.org
>Subject: [SIPForum-discussion] BYE during setup phase
>
> 
>
>
>HI All, 
>
>If  UAC send BYE during calll setup phase then what would be the
>response for BYE method. 
>Scenario is:- 
>
>UAC                                        UAS, 
>
>INVITE- - -- - - --- -- - - - -- - - -- - - -- -> 
><- - - -- - - - -- - - ---- - - -- - -- --- - -- - - 100 Trying 
><- - - -- - - - -- - - ---- - - -- - -- --- - -- - - 180 Ringing 
>BYE  - -- - - --- -- - - - -- - - -- - - -- -> 
>                                ?????? 
>
>
>Regards 
>Anshu
>
>***********************  Aricent-Private   *********************** 
>
>"DISCLAIMER: This message is proprietary to Aricent  and is intended
>solely for the use of 
>the individual to whom it is addressed. It may contain privileged or
>confidential information and should not be 
>circulated or used for any purpose other than for what it is intended.
>If you have received this message in error, 
>please notify the originator immediately. If you are not the intended
>recipient, you are notified that you are strictly
>prohibited from using, copying, altering, or disclosing the contents of
>this message. Aricent accepts no responsibility for 
>loss or damage arising from the use of the information transmitted by
>this email including damage from virus."
>
> 
>
>
>
>============================================================================================================================
> 
>Disclaimer:
>
>This message and the information contained herein is proprietary and
confidential and subject to the Tech Mahindra policy statement, you may
review the policy at <a
href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a>
externally and <a
href="http://tim.techmahindra.com/Disclaimer.html">http://tim.techmahindra.com/Disclaimer.html</a>
internally within Tech Mahindra.
>
>============================================================================================================================