[SIPForum-discussion] BYE during setup phase
Lokesh Agrawal
lokesh.agrawal at gmail.com
Thu Sep 6 08:27:35 UTC 2007
Hi all,
I am very much agree with Devaraja.
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 but it can be 487 also.
here is an example.....
Alice Bob
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| BYE F3 |
|----------------------->|
| 200 OK(BYE) F4 |
|<-----------------------|
| 487 F5 |
|<-----------------------|
| ACK F6 |
|----------------------->|
| |
| |
In this scenario, Alice establishes an early dialog with the receiving
180 response. Alice sends a BYE on the early dialog. According to
Section 15 of RFC3261, callee's UA MUST NOT send a BYE on early dialogs,
but the caller's UA MAY send a BYE on early dialogs.
Message Details
F1 INVITE Alice -> Bob
INVITE sip:bob at biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice at atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob at biloxi.example.com>
Call-ID: 3848276298220188511 at atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice at client.atlanta.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 180 Ringing Bob -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice at atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511 at atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob at client.biloxi.example.com;transport=udp>
Content-Length: 0
/* Alice forms an early dialog by receiving a 180 response to ini-INVITE.
However Bob is not sure that Alice received the 180 response. */
F3 BYE Alice -> Bob
BYE sip:bob at client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
Max-Forwards: 70
From: Alice <sip:alice at atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511 at atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* Alice sends a BYE on the early dialog and Alice terminates
a session (if any). */
F4 200 OK(BYE) Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
;received=192.0.2.101
From: Alice <sip:alice at atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511 at atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* Bob sends a 200 OK to a BYE of Alice, and Bob terminates
a session (if any). */
F5 487 Request Terminated(INVITE) Bob -> Alice
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
;received=192.0.2.101
From: Alice <sip:alice at atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511 at atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob at client.biloxi.example.com;transport=udp>
Content-Length: 0
/* Bob should terminate the early dialog when he receives a BYE.
Bob sends a 487 response to terminate a INVITE transaction
in the similar way to handle a CANCEL from Alice, because the
INVITE transaction remains after terminating the early dialog. */
F6 ACK Alice -> Bob
ACK sip:bob at biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice at atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob at biloxi.example.com>
Call-ID: 3848276298220188511 at atlanta.example.com
CSeq: 1 ACK
Contact: <sip:alice at client.atlanta.example.com;transport=udp>
Content-Length: 0
/* Alice sends an ACK to a 487 response as processing of the
ini-INVITE transaction. (The dialog has been already terminated,
but the ini-INVITE transaction remains) */
Thanks and Regards
Lokesh Agrawal
Persistent Systems (P) Ltd.
On 9/6/07, 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 http://www.techmahindra.com/Disclaimer.htmlexternally and
> http://tim.techmahindra.com/Disclaimer.html internally within Tech
> Mahindra.
>
>
> ============================================================================================================================
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070906/7ccbdfbf/attachment-0002.html>
More information about the discussion
mailing list