[SIPForum-discussion] BYE during setup phase
amit kumar tyagi
amityagi123 at rediffmail.com
Thu Sep 6 11:38:11 UTC 2007
Hi all,
I am new to SIP .Can any body send me test plan document for SIP .
Thanks
with regds:
amit
On Thu, 06 Sep 2007 Devaraja G M wrote :
>
>Hi All,
>
>I Strongly agree with Lokesh.
>
>Thanks Lokesh for correcting me.
>
>We tried with Xlite softphone after receiving 180 ringing we sent
>Bye.(For the below mentioned Call flow Scenario)
>
>Xlite sent 200 OK for BYE and 487 for 180 ringing.
>
>Answer (rfc 3261 :)
>
> section : 15
>
>. The caller's (Alice ) UA MAY send a BYE for either confirmed or early
>dialogs,
>
>21.4.25 487 Request Terminated
>
>The request was terminated by a BYE or CANCEL request. This response is
>never returned for a CANCEL
>
>request itself.
>
>Thanks & Regards,
>
>Devaraj G.M
>
>
>
>________________________________
>
> From: Lokesh Agrawal [mailto:lokesh.agrawal at gmail.com]
>Sent: Thursday, September 06, 2007 1:58 PM
>To: Devaraja G M
>Cc: Anshupriya Nayak; discussion at sipforum.org
>Subject: Re: [SIPForum-discussion] BYE during setup phase
>
>
>
>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 < <mailto:sip:alice at atlanta.example.com>
>sip:alice at atlanta.example.com>;tag=9fxced76sl
>
> To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
>
> Call-ID: <mailto:3848276298220188511 at atlanta.example.com>
>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 <mailto:sip:bob at client.biloxi.example.com>
>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= <http://192.0.2.101>
>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 < <mailto:sip:bob at biloxi.example.com>
>sip:bob at biloxi.example.com>
>
> Call-ID: 3848276298220188511 at atlanta.example.com
>
> CSeq: 1 ACK
>
> Contact: < <mailto:sip:alice at client.atlanta.example.com>
>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 <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.html
>externally 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
>
>
>
>
>
>============================================================================================================================
>
>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.
>
>============================================================================================================================
>_______________________________________________
>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
with regds:
Amit kumar Tyagi
contact no-9342159442
Banglore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070906/1d62252a/attachment-0002.html>
More information about the discussion
mailing list