Hi,
Quoting from Bis-09, section 22.1:
"4860 UACs creating an ACK message will duplicate all of the Authorization
and Proxy-Authorization header
4861 field values that appeared in the INVITE to which the ACK
corresponds."
Please note the word "duplicate". I suppose the ACK must essentially copy
the credentials from the INVITE to which it corresponds. Further take the
case when a stateful proxy sends an ACK for a 4xx response received from a
forked branch. The proxy has no way of calculating the "response" digest.
It
can only copy credentials from the INVITE and send the ACK downstream.
Regards,
-Madhusudan.
>>Can someone clarify the authentication credentials needed for an ACK
>>request?
>>
>>
>>When I get a 401 or 407 response to an INVITE, I use the method in
>>RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication)
>>to calculate a response.
>>
>>For calculating A2, I refer to this section in RC2617:
>>
>>3.2.2.3 A2
>>
>> If the "qop" directive's value is "auth" or is unspecified, then A2
>> is:
>>
>> A2 = Method ":" digest-uri-value
>>
>> If the "qop" value is "auth-int", then A2 is:
>>
>> A2 = Method ":" digest-uri-value ":" H(entity-body)
>>
>>
>>So when the "Method" is INVITE, I set it to "INVITE", so A2 will
>>become something like this:
>>INVITE:sip:[EMAIL PROTECTED]:1234567890ABCDEF01234567890ABCDEF0
>>
>>This method seems to work fine for interoperability with some systems.
>>
>>However other systems require authentication to be sent with the ACK
>>request.
>>
>>In RFC2543 bis-09, it says (section "13.2.2.4 2xx responses"):
>>
>> The UAC core MUST generate an ACK request for each 2xx received from
>> the transaction layer. The header fields of the ACK are constructed
>> in the same way as for any request sent within a dialog (see Section
>> 12) with the exception of the CSeq and the header fields related to
>> authentication. The sequence number of the CSeq header field MUST be
>> the same as the INVITE being acknowledged, but the CSeq method MUST
>> be ACK. The ACK MUST contain the same credentials as the INVITE. If
>> the 2xx contains an offer (based on the rules above), the ACK MUST
>> carry an answer in its body. If the offer in the 2xx response is not
>> acceptable, the UAC core MUST generate a valid answer in the ACK and
>> then send a BYE immediately.
>>
>>
>>NOTE this part:
>>"The ACK MUST contain the same credentials as the INVITE."
>>
>>So if the INVITE had this:
>>Proxy-Authorization:Digest username="0201", realm="Hello.com",
>> nonce="TW9uIE1hciAyNiAxOToyNDoyMiBHTVQrMDI6MDAgMjAwMQ==",
>> uri="sip:[EMAIL PROTECTED]:5060", qop=auth, nc=00000000,
>> cnonce="938D0344A666C36C4FD93DC460746031",
>> response="16c79f065598d1394389c21f2fbbe456",
>> opaque="TW9uIE1hciAyNiAxOToyNDoyMiBHTVQrMDI6MDAgMjAwMQ=="
>>
>>Does this mean that the ACK should use exactly the response as was sent
>>in INVITE?
>>
>>
>>Or does it, as I suspect, mean that the response should
>>be recalculated with the same parameters as in the original INVITE
>>challenge? That is, with the same Qop, Nonce, CNonce, NC, etc.?
>>
>>And when you calculate the ACK "response"
>>(response="16c79f065598d1394389c21f2fbbe456") should you use
>>ACK as the "Method" when calculating A2 - so A2 becomes
>>something like this?
>>ACK:sip:[EMAIL PROTECTED]:1234567890ABCDEF01234567890ABCDEF0
>>
>>
>>Any help is much appreciated.
>>
>>Regards,
>>
>>Attila
>>
>>
>>
>>Attila Sipos
>>Software Engineer
>>
>><http://www.vegastream.com>
>>
>>
___________________________________________________________________________
_
>>_______
>>
>>
>>VegaStream : A World of difference for your Integrated Communications
>>
>>EMEA Office (UK)
>>Tel + 44 - 1344 784900 Fax + 44 - 1344 784901
>>USA Office
>>Tel + 1 - 561-995-2300 Fax + 1 - 561-995-2600
>>
>>This e-mail and any attachments hereto are strictly confidential and
>>intended solely for the addressee. If you are not the intended addressee
>>please notify the sender by return and delete the message. You must not
>>disclose, forward or copy this e-mail or attachments to any third party
>>without the prior consent of the sender.
>>_______________________________________________
>>Sip-implementors mailing list
>>[EMAIL PROTECTED]
>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
