[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] How In early dialog state can UAC send BYE?
From:       Francisco_José_Méndez_Cirera <mendezirera () gmail ! com>
Date:       2009-05-18 9:22:39
Message-ID: 5522bed90905180222o37b30032m6e834ee5e6f90669 () mail ! gmail ! com
[Download RAW message or body]

2009/5/14 <shamik.saha@wipro.com>

> Hi Kishore,
>
> To terminate a early dialog you can send both cancel and bye requests,since
> a cancel request can be sent because we already received a provisional
> response and a BYE can be sent as pointed by Inaki because the dialog
> identifiers are present,since the to tag is present in the UAS reply,now why
> will we send a bye instead of a cancel,as an answer to that I could like to
> refer a very old post,which will clear everything.
>
>
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2000-October/000214.html
>
>
> Inaki,
>
> Do you think cancel or bye which will be a better response to terminate a
> early dialog?


I saw that a BYE request is a better response than CANCEL request if you
wish terminate a particular dialog. However, if you want to cancel all early
dialog (when the initial INVITE is forked) the best response  is CANCEL
(should not contain a tag in the To header).

 Is it possible what I said?


>
>
> Thanks and regards,
>
> Shamik Saha
> Project Engineer
> Voice Protocols
> Cell :  +91-9886704155
>
> -----Original Message-----
> From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:
> sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of kishore sowdi
> Sent: Thursday, May 14, 2009 12:51 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] How In early dialog state can UAC send BYE?
>
> Hi,
> Section 15 of RFC 3261 says - "The caller's UA MAY send a BYE for
> eitherconfirmed or early dialogs, and the callee's UA MAY send a BYE
> onconfirmed dialogs, but MUST NOT send a BYE on early dialogs".
> Section 12.1 of RFC 3261 says - "A dialog established by a
> non-final response to a request is in the "early" state and it is called
> an early dialog".
> Section 9.1 of RFC 3261 says - "If no provisional response has been
> received, the CANCEL request MUST NOT be sent; rather, the client MUST wait
> for the arrival of aprovisional response before sending the request. If the
> original request has generated a final response, the CANCEL SHOULD NOT
> be sent, as it is an effective no-op, since CANCEL has no effect on requests
> that have already generated a final response".
> So , How In early dialog state can UAC send BYE?
>
> I want to know the used case when caller's UA will send a BYE for a early
> dailog case.
>
> Regards,Kishore
>
>
>      Explore and discover exciting holidays and getaways with Yahoo! India
> Travel http://in.travel.yahoo.com/_______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>



-- 
Francisco José Méndez Cirera
MendeZirerA@gmail.com "sin la C ni ná"

[prev in list] [next in list] [prev in thread] [next in thread]