Who said anything about changing the protocol? In both the scenarios if UAC is sending PRACK means UAS sent a 'reliable 1xx response'. And hence UAS should be expecting PRACK and should send a '200' for the PRACK. Since it is NOT responding to the PRACK, but responding to UAS, it is clearly NOT behaving as per RFC3262, Section 3. Or if UAC is incorrectly formating the PRACK request which UAS which drops. In this case, UAC is NOT behaving as per RFC and is misbehaving.
So, if we assume both UAC and UAS are RFC (3261 and 3262) compliant, then these scenarios won't occur at all, if we assume network is NOT dropping ONLY PRACK requests. Note that many a times you can't correct the mis-behaving UA. It can be a remote SIP peer from some other vendor, with which your SIP entity has to interact. -Arun On Wed, Dec 17, 2008 at 2:44 AM, Serbang, Nabam (Nabam) <[email protected]>wrote: > 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
