The PRACK essentially acknowledges that the UAC has received the RPR from the UAS. So the UAS keeps retransmitting 18x with the described backoff timer until it gets a "valid" PRACK for that RPR. If the UAS is challenging PRACKs, then it won't consider the PRACK "valid" for the purpose of acknowledging the RPR until the PRACK is received with the proper credentials. So no, RPR doesn't "end" when it gets just a PRACK - it needs to be PRACK with the proper credentials, and thus the one resent after the challenge.
But again, I strongly recommend you DO NOT challenge PRACKs. No one does this in the real world, and my guess is you will run into serious interop problems if you do it. There is no real value in doing it anyway. There is no real security value, for example. (there's a small nit one for offerless Invite call flows, but it's a nit) -hadriel ________________________________ From: praveen dandin [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 29, 2008 10:04 AM To: Paul Kyzivat Cc: Hadriel Kaplan; Sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Can PRACK be challenged?? Thanks for your response. I have one more doubt. 1) How long the 18x be maintained so as to match incoming PRACK with it? Is it till UAS receives the first matching PRACK or till 2xx is sent for the PRACK? If RPR transaction with 18x is removed after matching the first PRACK (to which failure response is sent) then how to identify the matching RPR for the next PRACK which comes with the credentials? The RFC 3262 section 3 says: If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response. The UAS can be certain at this point that the provisional response has been received in order. It SHOULD cease retransmissions of the reliable provisional response, and MUST remove it from the list of unacknowledged provisional responses. Does it mean RPR transaction (i.e., 18x) should be removed only when 2xx is sent for the PRACK? Also the RFC 3262 section 1 says: Reliable provisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message is received. The PRACK request plays the same role as ACK, but for provisional responses. There is an important difference, however. PRACK is a normal SIP message, like BYE. Here it mentions that the retransmission of 18x should cease after receiving the PRACK.If it so, then the PRACK with credentials will not have the matching RPR as the RPR will get removed when first PRACK is received. Is this not contradicting with the above statement(i.e., statement from 3262 section 3)?? Thanks, Praveen Dandin Paul Kyzivat <[EMAIL PROTECTED]> wrote: Praveen, See inline. praveen dandin wrote: > Thanks Paul and Hadriel. > Hi Paul, > With respect to your following answer I have a doubt. > > Paul>Note that it is apparently common for credentials to *not* be required > for in-dialog requests, but there is no law about this, so certainly there > MAY be a challenge. > >>> Is it valid for an UAS to challenge the requests of the same call when it >>> has received the proper credentials through the previous challenge (just >>> like here where INVITE is already challenged and the proper credentials are >>> being received)?? > > I suppose my last query (How the PRACK transactions be maintained in > this case?)was not complete. Let us consider the below call scenario. > > / UAC UAS/ > > / | INVITE/ > > / |--------------------------------------------------->|/ > > / | 401 |/ > > / |<---------------------------------------------------|/ > > / | ACK |/ > > / |--------------------------------------------------->|/ > > / | INVITE with credentials |/ > > / > |---------------------------------------------------->|/ > > / | 180 |/ > > / |<----------------------------------------------------|/ > > / | PRACK without credentials |/ > > / > |---------------------------------------------------->|/ > > / 401/ > > / |<----------------------------------------------------|/ > > / | PRACK with credentials |/ > > / |---------------------------------------------------->|/ > > / 200 (PRACK)/ > > / > |<----------------------------------------------------|/ > > / / > > As per RFC 3261 "PRACK with credentials" MUST > > have Cseq incremented w.r.t that of "PRACK without credentials". > > Now my doubt is how the new PRACK i.e., "PRACK with credentials" be matched > to the RPR transaction as Cseq of PRACK does not match to that of 180?. The > RFC 3262 section 3 says : > > A matching PRACK is defined as one within the same dialog as the > response, and whose method, CSeq-num, and response-num in the RAck > header field match, respectively, *the method from the CSeq, the > sequence number from the CSeq, *and the sequence number from the RSeq of > the reliable provisional response. > > Does the above statement indicates that the matching PRACK can be obtained by > matching just the values in RAck of PRACK but not its Cseq with that of RPR?? I don't see how it could be any other way. The CSeq of the PRACK itself has no role in this. Parsing the above more explicitly: A matching PRACK is defined as one within the same dialog as the response, and whose (1) method (in the RAck header field) (2) CSeq-num (in the RAck header field) (3) response-num) (in the RAck header field) match, respectively, *the (1) method from the CSeq (of the reliable provisional response) (2) sequence number from the CSeq (of the reliable provisional response) (3) sequence number from the RSeq (of the reliable provisional response) None of this refers to the CSeq of the PRACK. Paul > I did not find any relevant data to handle such a scenario from RFCs > 3261 n 3262. Is there any draft which addresses such a scenario? > > Thanks, > Praveen Dandin > > */Paul Kyzivat /* wrote: > > I can't disagree with Hadriel on this. :-) > > Bottom line is: if you are implementing a UAS, you should think long > and > hard before deciding to challenge a PRACK. Avoid it if you can. > > If you are implementing a UAC, be prepared to respond to the challenge > of a PRACK. > > Paul > > Hadriel Kaplan wrote: > > As Paul said, you don't have to include credentials in PRACK, and > a PRACK can be challenged - but it is incredibly rare to challenge > them. And frankly there's very little point/benefit in challenging a > PRACK. Also, if you challenge a PRACK, you may run into interop > issues with some vendors. > > > > -hadriel > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:sip- > >> [EMAIL PROTECTED] On Behalf Of praveen > dandin > >> Sent: Thursday, April 24, 2008 10:43 AM > >> To: Sip-implementors@lists.cs.columbia.edu > >> Subject: [Sip-implementors] Can PRACK be challenged?? > >> > >> Hi, > >> Consider the below call scenario. > >> UAC UAS > >> | INVITE > >> |--------------------------------------------------->| > >> | 401 | > >> |<---------------------------------------------------| > >> | ACK | > >> |--------------------------------------------------->| > >> | INVITE with credentials | > >> |---------------------------------------------------->| > >> | 180 | > >> |<----------------------------------------------------| > >> | PRACK | > >> |---------------------------------------------------->| > >> > >> Now my queries are: > >> 1) Is it MUST to send the credentials in PRACK? > >> [RFC 3261 section 22.3 says "If a UA receives a Proxy-Authenticate > >> header field value in a 401/407 response to a request with a > particular > >> Call-ID, it should incorporate credentials for that realm in all > >> subsequent requests that contain the same Call- > >> ID." > >> But the RFC does not mention what if UAC is challenged with WWW- > >> Authenticate header] > >> > >> 2) If credentials are not provided in PRACK then can UAS challenge > >> PRACK? > >> > >> 3) If its possible to challenge the PRACK with 401, should the > >> subsequest PRACK with Authorization credential have the > incremented CSeq > >> as compared to the previous PRACK? > >> [RFC 3261 section 22.2 says"When a UAC resubmits a request with its > >> credentials after receiving a 401 (Unauthorized) or 407 (Proxy > >> Authentication Required) response, it MUST increment the CSeq > header field > >> value as it would normally > >> when sending an updated request."] > >> > >> 4) How the PRACK transactions be maintained in this case? > >> > >> Please provide your valuable inputs. > >> > >> Thanks, > >> Praveen Dandin > >> > >> > >> --------------------------------- > >> Connect with friends all over the world. Get Yahoo! India Messenger. > >> _______________________________________________ > >> Sip-implementors mailing list > >> Sip-implementors@lists.cs.columbia.edu > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ------------------------------------------------------------------------ > Get the freedom to save as many mails as you wish. Click here to know > how. > > size=1 width="100%" align=center> Bring your gang together. Do your thing. Find your favourite Yahoo! Group.<http://in.rd.yahoo.com/tagline_groups_9/*http:/in.promos.yahoo.com/groups/> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
