Wow.......thats intersting. I guess you need to correct the mis-behaving UA. It would be mistake to change protocol just for one/few mis-behaving UA. What if that UA starts working rfc complaint. You will be in double trouble, i feel. Anyway, the solution lies how much you love that mis-behaving UA :-)
Thanks and regards Nabam Serbang ________________________________ From: Arunachala [mailto:[email protected]] Sent: Wednesday, December 17, 2008 4:07 PM To: Serbang, Nabam (Nabam) Cc: Rockson Li (zhengyli); [email protected] Subject: Re: [Sip-implementors] INVITE Behaviour When PRACK isnotrespondedwith 2xx Hi, In the scenario described, one of the UA is mis-behaving. If both UA's act according to RFC3262, and we assume PRACK packet is NOT getting lost in the network, these scenario will never occur. If UAS was RFC compliant, it would have NEVER sent the 200 OK for the INVITE, if there was a OFFER in the reliable 1xx response that UAS sent. So, what we are trying to do here is to find a workable solution for misbehaving UAs. Also, for scenario 2, if UAC is RFC3262 compliant, it SHOULD logically send individual CANCELs to cancel INVITE and PRACK transactions. -Arun On Wed, Dec 17, 2008 at 2:19 AM, Serbang, Nabam (Nabam) <[email protected]> wrote: Sorry guys. There was mistake. "...........Since UAC didn't recive 200 PRACK as yet and UAC didn't receive PRACK..." should as "......Since UAC didn't recive 200 PRACK as yet and UAS didn't receive PRACK...." Apologies for inconvenience. Thanks and regards Nabam Serbang -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Serbang, Nabam (Nabam) Sent: Wednesday, December 17, 2008 3:45 PM To: Arunachala; Rockson Li (zhengyli) Cc: [email protected] Subject: Re: [Sip-implementors] INVITE Behaviour When PRACK isnotrespondedwith 2xx >From rfc3262: "The UAS MAY send a final response to the initial request before having received PRACKs for all unacknowledged reliable provisional responses, unless the final response is 2xx and any of the unacknowledged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding responses. A UAS MUST NOT send new reliable provisional responses (as opposed to retransmissions of unacknowledged ones) after sending a final response to a request" Scenario 1: PRACK from UAC depends on initial INVITE. If invite had "Require" header field with value "100rel", UAS must send 1xx respone (except 100 trying) back to UAC. If UAS has sent 101-199 in reponse to INVITE (Remember there will be Rseq header field in prov. response) , UAS will be expecting PRACK from UAC. Since UAC didn't recive 200 PRACK as yet and UAC didn't receive PRACK, will 200 INV be accepted by UAC? I don't think so. I guess 481 will do or time out ( Possibily by UAS). Again INVITE, PRACK initiates transaction each, both the transaction should be rolled back as PRACK transaction is initiated by INVITE. No doubt you can let UAC accept after sending PRACK and before receiving 200 PRACK but that will be a violation of protocol, not just SIP but definitation of "transaction" as well. From rfc3262, "...........In that case, it MUST NOT send a final response until those provisional responses are acknowledged....", UAS definitely is not going to send 200 INV if PRACK is not received. Whats your take on this? Scenario 2: What "> ----CANCEL---->" is doing? Is it cancelling PRACK or INVITE? I guess you mean CANCEL to PRACK. Practically, I don't see any reason/way to cancel PRACK. It make sense for protocol completeness though. Anyway, if CANCEL was for PRACK, it should be re-transmitted reason as stated in scenarion 1 above. > 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 and regards Nabam Serbang -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Arunachala Sent: Wednesday, December 17, 2008 2:19 PM To: Rockson Li (zhengyli) Cc: [email protected] Subject: Re: [Sip-implementors] INVITE Behaviour When PRACK is notrespondedwith 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. 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 _______________________________________________ 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
