Hi Piotr:)
RFC only implies that proxy should not challenge the ACK message and moreover it says that client sending ACK should duplicate Authorization and Proxy-Authorization headers. This it what my client does. But according to the description of the proxy_authorize function it only verifies that credentials are valid. This function doesn't cause the challenge response to be sent to the client. This is performed with the usage of proxy_challenge function. "The function verifies credentials according to RFC2617. If the credentials are verified successfully then the function will succeed and mark the credentials as authorized (marked credentials can be later used by some other functions). If the function was unable to verify the credentials for some reason then it will fail and the script should call proxy_challenge which will challenge the user again." In my opinion, that is why proxy_authorize function should generate the uid avp for ACK request if verification of credential gives positive result.
Waiting for any feedback. Regards Tomasz
On Nov 8, 2007 4:51 PM, Piotr Grabowski pgrabowski@gmail.com wrote:
Hi Tomek, I think this is your answer ;) :
RFC 3261 22.1
While a server can legitimately challenge most SIP requests, there are two requests defined by this document that require special handling for authentication: ACK and CANCEL. Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. 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. Servers MUST NOT attempt to challenge an ACK.
-- PG
2007/11/8, Tomasz Zieleniewski tzieleniewski@gmail.com:
Hi,
When I invoke proxy_authorize and radius_proxy_authorize for an ACK message the is no uid avp present. All other messages which are authorized work fine. Why is that so?? Is it the right behaviour??
Bests regards Tomasz
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers