Columbia VoIP Testbed
Overview		Architecture	SIP End Clients	Interoperability
Home | Issues 1 2 3 4 5 6 | Robustness Tests |
Issue #1: Use of different formats for authentication name Category Lack of clarity in the specification Description SIP provides a stateless, challenge-based mechanism for authentication that is based on digest authentication in HTTP. When using digest authentication, a User Agent Client (UAC) trying to establish a session with a User Agent Server (UAS) or trying to register with a registrar, may be challenged by its proxy or the registrar to provide its credentials. The UAC then resends its request along with the authentication information in the Authorization header. We have identified that UACs follow different formats for the authentication username field, while composing this header. Three such variations are as shown – 1. Authorization: Digest username=“user”, realm=“domain”, nonce=“xxx”, uri=“sip:proxy.provider.com”, response=“yyy”, algorithm=MD5 2. Authorization: Digest username=“user@domain”, realm=“domain”, nonce=“xxx”, uri=“sip: proxy.provider.com”, response=“yyy”, algorithm=MD5 3. Authorization: Digest username=“sip:user@domain”, realm=“domain”, nonce=“xxx”, uri=“sip: proxy.provider.com”, response=“yyy”, algorithm=MD5 Implications Having no common format of authentication name between the UA and any of the SIP registrar/proxy servers in the signaling path, will result in a registration failure and/or call setup failure.
Instance #1 Some SIP registrars/proxies expect the Authentication name to be the same as the SIP-URI, while some others expect it to be just the username part of the SIP-URI. This creates problems as a UA will have to supply user credentials in different forms, while operating with different SIP registrars/proxies. Packet traces / Call-flows 3Com SIP server not accepting registration requests. Fixes / Workarounds Use a Back to Back User Agent (B2BUA) like Asterisk to mediate between the SIP UA and the SIP Server.
Instance #2 A related issue is the composition of SIP "From" and "Authentication" headers by the UAs. If a UA generates both these headers from a single input supplied by the user (namely, username), there is a potential problem as either of these headers may have more/less/mangled text. In cases where such UAs are operating with a SIP registrar/proxy that expects Authentication name in a different format, the UAs receive either a "404 User not found" or "403 Forbidden" responses back. Such problems are not seen in UAs that accept separate values for composing "From" and "Authentication" headers. Packet traces / Call-flows Polycom PVX/VSX failing to register with 3Com SIP server. Fixes / Workarounds Use a Back to Back User Agent (B2BUA) like Asterisk to mediate between the SIP UA and the SIP Server.