Hi Igor, I agree with Sanjay email.
"Same uri as in Invite. Here is text from RFC 3261: UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds." And here is the URI parameter stuff: "1. The URI included in the challenge has the following BNF: URI = SIP-URI / SIPS-URI" Regards, Markus Igor Vanin wrote: > Hello, Markus > On Mon, 09 Oct 2006 17:11:02 +0200 "Markus Hofmann" <[EMAIL PROTECTED]> wrote > to "Igor Vanin" <[EMAIL PROTECTED]>: > > MH> the Authorization header must be exactly the same because the uri is > MH> in the calculation of the response. A proxy or UA will maybe not > MH> process the ACK because of a wrong response. > MH> We are copy the Authentication header to the ACK > > Markus, thank you for your response. > But I am in doubt that the Authorization header must be *exactly* the same. > Yes, the UAC, when calculating the auth.response, MUST use the same > credentials as in the INVITE. But don't forget, that in the response > calculation procedure parameters the request method name is included. We > calculate "response" using the same nonce, auth.username, password, etc., but > use method name "ACK" instead of "INVITE", so, the "response" is not exactly > the same as in INVITE. > > [...] > MH> Igor Vanin wrote: >>> Which URI should I use in "uri" parameter of Authorization header >>> field in ACK request after 200 response from server: the same URI as in >>> INVITE request or new Request-URI obtained from Contact HF of 200 >>> response? >>> >>> After INVITE/401/ACK transaction, my softphone sends to the Proxy an >>> INVITE request with the following lines: >>> >>> INVITE sip:[EMAIL PROTECTED] SIP/2.0 >>> To: <sip:[EMAIL PROTECTED]> >>> Authorization: Digest >>> username="testcaller",realm="sip.example.com",nonce="55555",uri="sip: >>> [EMAIL PROTECTED]",response="[skippedmyfirstresponse]" >>> >>> Then I receive 200 response from server: >>> >>> SIP/2.0 200 OK >>> To: <sip:[EMAIL PROTECTED]>;tag=111 >>> Contact: <sip:[EMAIL PROTECTED]:5060> >>> >>> Then the UAC core generates ACK request with updated Request-URI: >>> >>> ACK sip:[EMAIL PROTECTED] SIP/2.0 >>> To: <sip:[EMAIL PROTECTED]>;tag=111 >>> Which Authorization header field is correct? >>> This: >>> Authorization: Digest >>> username="testcaller",realm="sip.example.com",nonce="55555",uri="sip: >>> [EMAIL PROTECTED]",response="[skippedmysecondresponse]" or >>> this: Authorization: Digest >>> username="testcaller",realm="sip.example.com",nonce="55555",uri="sip: >>> [EMAIL PROTECTED]:5060",response="[skippedmysecondresponse]" ? >>> >>> RFC-3261 claims that the ACK MUST contain the same credentials as the >>> INVITE. Is the "uri" parameter the part of "credentials", or it >>> should match the Request-URI of each request? > > -- > With best regards, Igor Vanin, St. Petersburg, Russia > mailto:[EMAIL PROTECTED] http://gpmail.spb.ru > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
