Subject: RE: [Sip] [SIP Cacel Method]

From: "Prakash Maria susai - NPD, Chennai" <[email-masked]>
Date: Fri, 2 Dec 2005 17:04:41 +0530

Hi Kapil,

Please see my comments inline....

-----Original Message-----
From: Kapil Nayar [mailto:[email-masked]]
Sent: Friday, December 02, 2005 4:10 AM
To: Prakash Maria susai - NPD, Chennai; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Sip] [SIP Cacel Method]

Hi

I guess you are confusing the timerB with timerA - 
timerB(64xT1) is the transaction timeout timer started
to receive the final response to INVITE. 
[Prakash]=> It is true, that timer B is the transaction timeout.

If it
expires, the UAC should consider the transaction
cancelled and may destroy the local context. While
some implementations would like to send CANCEL just to
make sure the INVITE is indeed cancelled.
[Prakash]=> When timer B fires, implementations may send a CANCEL, though it
is not mentioned so in the RFC.
What I meant to convey was that it is not a MUST to send CANCEL when timer B
fires.
Section 17.1.1.2 does NOT mention that transaction must inform the TU, when
timeout has occurred in "Proceeding" state.
It however, mentions that transaction should inform the TU, when timeout has
occurred in "Calling" state.

The Expires header serves this purpose. It would start a timer on sending
INVITE, and on expiry, would send CANCEL.
 
Please let me know if the understanding is wrong.
Thanks,
Prakash.

--- "Prakash  Maria susai  - NPD, Chennai"
<[email-masked]> wrote:

> Hi,
>  
> As Sreeram has mentioned, it cannot be Timer B,
> since Timer B is not active
> once 1xx is got.
> The some other timer could be a Timer started
> through Expires Header
> indicated in INVITE request.
>  
> Thanks,
> Prakash.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, November 30, 2005 1:04 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip] [SIP Cacel Method]
> 
> 
> Yes you must generate ACK in second case also.
>  
> also, in case2) it is not "timerb timeout" as the
> caller received
> provisional response its state machine goes to
> "proceeding state"
> It should be some other timer implemented  at the
> uac to handle the case
> when there is no final response in the "proceeding
> state"    
>  
> HTH,
> Sreeram.
> 
>   _____  
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Chen
> Shuping
> Sent: Wednesday, November 30, 2005 11:50 AM
> To: [email-masked]
> Subject: [Sip] [SIP Cacel Method]
> 
> 
> Hi,All
>  
>   I have such a doubt:
>  
>    In RFC 3261 17.1.1.2  Time_B timeout in Calling
> state,Invite transaction
> transit to terminated
>  
> state,What if Timer_B timeout in Proceeding 
> state(this could happen when
> the callee is not in office,
>  
> his softphone keep ringring until caller's timer_b
> timeout).
>  
> In my implementation my call flow like this:
>  
> CASE 1:
>  
> caller                                         
> callee
> ------------INVITE------------------->
> <-----------100 Trying-----------------
> <-----------180 Ringing--------------
>  
> caller hang up
>  
> --------------Cancel----------------->
> <-------------200 for Cancel--------
> <-------------487----------------------
> ---------------ACK------------------>
>  
> CASE 2:
>  
> INVITE-------------------> 
> <-----------100 Trying-----------------
> <-----------180 Ringing--------------
>  
> caller keep waiting ,Timer_b time out
>  
> --------------Cancel----------------->
> <-------------200 for Cancel--------
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
>  
> My question is should I generate ACK for the second
> case.
>  
>  
> Thanks
>  
>  
>  
>  
> 
> 
> Disclaimer:
> 
> This message and any attachment(s) contained here
> are information that is confidential, proprietary to
> HCL Technologies and its customers, privileged or
> otherwise protected by law. The information is
> solely intended for the individual or the entity it
> is addressed to. If you are not the intended
> recipient of this message, you are not authorized to
> read, forward, print, retain, copy or disseminate
> this message or any part of it. If you have received
> this e-mail in error, please notify the sender
> immediately by return e-mail and delete it from your
> computer.
> > _______________________________________________
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
> Protocol
> Use [email-masked] for questions
> on current sip
> Use [email-masked] for new developments on the
> application of sip

___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
voicemail http://uk.messenger.yahoo.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip