Folks,
An issue seems to have come up amongst several production implementations,
and some folks are claiming that what they are doing is "within the scope of
the spec", when indeed it is not.
The issue is the value of the username attribute for the digest
Authorization header. When the proxy (or UAS) issues a challenge, the client
is supposed to query the caller for their username and password within the
specified realm. Apparently, one client implementation takes that username
value, and automatically appends a "@domain.com", where domain.com is some
domain name extracted from either the 401/407 or a static configuration (not
sure which). This user@host value is then placed in the username parameter
of the Authorization header. They apparently do this because a proxy vendor
claimed that this was allowed within the spec, and was required by that
particular proxy vendor.
This is simply wrong.
The username and password have NO SEMANTIC SIGNIFICANCE to any SIP system.
Their values are pre-arranged between the provider and the user. If one
provider wishes for users to type in their full user@host names, thats fine;
they simply tell their subscribers that this is what to enter, and they set
up their databases to be keyed off of the whole thing. Other providers may
choose to just use a username. Others may use phone numbers. A SIP system
cannot make any assumptions about the meaning or construction of these
fields, period. A client should pass exactly the username and password
received into the algorithm, and return that username exactly in the
Authorization header.
If this problem persists, end users will need to be told to enter different
values depending on the client software and/or proxy in use. Very bad. Fix
this problem, please.
-Jonathan R.
---
Jonathan D. Rosenberg 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
