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 <[EMAIL PROTECTED]>/* 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.
> <http://in.rd.yahoo.com/tagline_mail_5/*http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/>
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
