comments inline :-)
-Rockson 
________________________________

From: Arunachala [mailto:[email protected]] 
Sent: Wednesday, December 17, 2008 4:49 PM
To: Rockson Li (zhengyli)
Cc: [email protected]; [email protected]
Subject: Re: [Sip-implementors] INVITE Behaviour When PRACK is not
respondedwith 2xx


For the scenario 1, 
   I think, as PRACK is a in-dialog request, according to RFC3261, it
SHOULD be retransmitted till timer-F expires.  
[RL] this has nothing to do with in-dialog request, it's just the basic
non-invite transaction capability. 

For the scenario 2, 
   I think, we can STOP retransmitting PRACK (even if it the Transaction
has NOT timed-out),  
[RL]I agree, since the call is gone, UAC core can destroy the
transaction for PRACK explicitly
 because the early dialog which PRACK might have facilitated the
establishment of, has been terminated by CANCEL. Also, even if we
retransmit PRACK, UAS would NOT find any unacknowledged '18x'  (which
matches the CSeq# and CSeq method in RAck of PRACK), so it would send a
'481' in response. 

-Arun


On Tue, Dec 16, 2008 at 6:36 PM, Rockson Li (zhengyli)
<[email protected]> wrote:


        IMO, you should differentiate the retransmission of PRACK in uac
core
        and transaction layer.
        PRACK is a normal req, which has its own transaction, so it's
        transaction who would assure the retransmission of the PRACK,
not UAC
        core layer.
        On retransmission in transaction  expires, I don't think it's
necessary
        for UAC core to retransmit the PRACK.
        
        My 2 $
        
        -Rockson
        
        -----Original Message-----
        From: [email protected]
        [mailto:[email protected]] On
Behalf Of
        [email protected]
        
        Sent: Tuesday, December 16, 2008 6:26 PM
        To: [email protected]
        Subject: [Sip-implementors] INVITE Behaviour When PRACK is not
        respondedwith 2xx
        
        
        
        
        Dear all,
        
         Could you please let me know the behaviour of UAC in the
following
        scenario (RFC3262 doesn't seem to address this behaviour).
        
        Scenario 1:
        
        UAC          UAS
        ----INV------->
        <---180--------
        ---PRACK----->
        (Peer didnt respond to PRACK because of some problem) <---200
INV----
        ----ACK------->
        ----PRACK-----> ??
        
        Should UAC retransmit PRACK ?
        or
        Should the PRACK retransmissions stop after receiving 200OK to
INVITE?
        
        
        Scenario 2:
        
        UAC          UAS
        ----INV------->
        <---180--------
        ----PRACK----->
        (Peer didnt respond to PRACK because of some problem)
        ----CANCEL---->
        <---200 CAN----
        <---487 INV----
        ----ACK------->
        ----PRACK-----> ??
        
        Should UAC retransmit PRACK ?
        or
        Should the PRACK retransmissions stop after receiving 487 to
INVITE?
        
        Thanks & Regards
        Tamal Tanu Biswas
        
        
        
        
        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
        [email protected]
        
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
        
        _______________________________________________
        Sip-implementors mailing list
        [email protected]
        
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
        


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to