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

From: [email-masked]
Date: Wed, 30 Nov 2005 17:55:31 +0530

Hi,
                           Please find my response within <Nisha> </Nisha>
Regards
Nisha
                                                                           
             Chen Shuping                                                  
             <shuping.chen@cec                                             
             wireless.com.cn>                                           To 
             Sent by:                  [email-masked]                        
             sip-bounces@ietf.                                          cc 
             org                                                           
                                                                   Subject 
                                       [Sip] [SIP Cacel Method]            
             11/30/2005 11:50                                              
             AM                                                            

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.

<Nisha>
      According to Section 13.1 of RFC, a UAC should respond with an ACK
for every final
response that it receives. In this case, 487 is a final response therefore
an ACK must be generated in the
CASE 2 described above.

----------------------Extract from RFC
3261----------------------------------------------------------
After possibly receiving one or more provisional responses, the UAC will
get one or more 2xx responses or
one non-2xx final response. Because of the protracted amount of time it can
take to receive final responses
to INVITE, the reliability mechanisms for INVITE transactions differ from
those of other requests (like
OPTIONS). Once it receives a final response, the UAC needs to send an ACK
for every final response
it receives. The procedure for sending this ACK depends on the type of
response. For final responses
between 300 and 699, the ACK processing is done in the transaction layer
and follows one set of rules (See
Section 17). For 2xx responses, the ACK is generated by the UAC core.

---------------------------End of extract from RFC
3261---------------------------------------------------
</Nisha>

Thanks

***********************  FSS-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) 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.  FSS  accepts no  responsibility  for loss or
damage arising from the use of  the information transmitted
by this email including damage from virus."

_______________________________________________
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