Hello people,
I'll appreciate your opinion regarding the following problem. While testing interoperability I've encountered fact that some registrars reject REGISTER, because it contains a few Authorization headers (not a Proxy-Authorizations). -> REGISTER <- 401 + WWW-Authenticate Header (H1) -> REGISTER + Authenticate Header (H1r) (with wrong password) <- 401 + WWW-Authenticate Header (H2) -> REGISTER + Authenticate Header (H1r) (with wrong password) + Authenticate Header (H2r) (with correct password) <- 400 : more than one Authenticate headers. I've found in RFC 3261 (section 22.3): -------------------------------------------------- It is possible for multiple challenges associated with the same realm to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication Required). This can occur, for example, when multiple proxies within the same administrative domain, which use a common realm, are reached by a forking request. When it retries a request, a UAC MAY therefore supply multiple credentials in Authorization or Proxy-Authorization header fields with the same "realm" parameter value. The same credentials SHOULD be used for the same realm. That is why I deduced standard compliance of my Stack. On the other hand I would like to be interoperable. The way I can think of - not to send the Authorization Header, rejected in the past, if the new Authorization Header to the same Registrar presents in the REGISTER. The problem is to relate the received Authorization Header to the Registrar. The same 'realm', for example, can be used by few Registrars (in accordance to the quote above). Therefore 'realm' can't be used for Proxy identification. Summarizing I have 2 questions: 1. Am I standard complaint, if I send REGISTER with a few Authorization headers? 2. If I do, what the way to identify the WWW-Authenticate headers, belonging to the same Server? Thank you, Igor Novoseltsev Programmer Technology Business Unit RADVISION _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
