For the scenario 1, I think, as PRACK is a in-dialog request, according to RFC3261, it SHOULD be retransmitted till timer-F expires.
For the scenario 2, I think, we can STOP retransmitting PRACK (even if it the Transaction has NOT timed-out), 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
