An issue that arises early in many discussions about this
topic is whether to use email addresses of the form
username@example.org or to use extension
numbers as the account identifiers.
In most cases, users still need to be able to be contactable using either type of address, but the question remains: should their phone login to the system using a named username or using an extension number?
Extension numbers are the standard in many traditional phone systems and some people have simply tried to replicate this model when moving to IP-based RTC.
There are three big reasons why numbers are popular: numbers can be dialed from anywhere else in the PSTN, numbers are easier to dial for people who are not calling from a computer (phones only have 12 buttons) and there is not always a one-to-one mapping between people and phones. One additional feature of numbers is that they are slightly less personal, somebody does not know exactly who will answer when they call a landline in a house shared by a large family and when somebody leaves a job, their phone number can be assigned to their successor.
Mobile telephones and smartphones in particular have dramatically reduced the significance of these factors that encouraged the continued use of numbers. For example, the inconvenience of manually dialing a SIP or XMPP address is not such a big factor because people are more likely to have these details in their address books.
Phone numbers also have disadvantages. One of these is the dependency on phone companies, the ITU and government bureaucracies who administer the numbering system. Users can be forced to change their phone number when changing provider. Dialing codes change, making it necessary to update old records in an address book. Each group of numbers is tightly bound to the infrastructure of a specific the telephone exchange, leading to inflexibility when relocating or when a local service outage occurs.
Use alphabetic usernames rather than extension numbers internally. SIP, XMPP and email each support a slightly different set of characters in usernames so only use the set of characters supported for all protocols. Wherever a device is being used with named accounts, such as a desktop PC where users login and have access to their own company email account, or a smartphone that is only used by one person and has been configured to access a named email account, provision the same personalized SIP/XMPP address on that device. Where a device is shared, such as a conference room phone, create a named account for that purpose.
It is generally helpful if the same username is used for login, email address, SIP and XMPP addresses. If the login names are not the same as email addresses, use the email addresses as the SIP and XMPP addresses.
To give users the convenience of dialing extension numbers from regular phones, create mappings from the extension numbers to the usernames.
This strategy offers significantly more potential for the future as more and more services will rely on usernames and fewer services will place emphasis on phone numbers.
When using this strategy, it is necessary to implement mappings from phone numbers to usernames as part of the ingress processing and for calls that go out to the PSTN over SIP or ISDN trunks, it is necessary to implement the reverse mapping, ensuring that the caller ID of each outgoing call is personalized based on the internal username.
It is not strictly necessary to use passwords for SIP, XMPP and TURN, you can use certificate authentication instead. Nonetheless, many people find that some of their users can only support password authentication or they don't want the complexity of managing public key infrastructure (PKI).
XMPP transmits passwords in cleartext, so all XMPP connections should be secured with TLS to avoid eavesdropping. The benefit of this approach is that XMPP users can be authenticated against any type of pre-hashed passwords or using a method such as LDAP bind to verify the supplied credential.
SIP and TURN use a DIGEST algorithm very similar to HTTP DIGEST. The DIGEST algorithm requires the server to have either an unencrypted copy of the password, a password encrypted with the HA1 algorithm or a service (such as RADIUS) that can perform delegated DIGEST authentication.
If unencrypted passwords are available, then the SIP and TURN servers can use them to construct the HA1 hash value or you can precompute the HA1 values and store them in a database.
HA1 hash values should be considered as sensitive as unencrypted passwords. Even though the plaintext password can't be recovered in a simple manner, anybody in possession of the HA1 value is able to use it to construct a response to a HTTP or SIP DIGEST challenge, thereby impersonating the user who owns that password. Therefore, do not keep HA1 hash values in world-readable configuration files or publicly accessible in LDAP.
The HA1 hash includes the username, the password and the realm. A HA1 hash can be easily constructed at the UNIX command line as demonstrated in Example 7.1, “Computing HA1”.
Example 7.1. Computing HA1
$ echo -n "alice:example.org:secret" | md5sum 543e1aec5d3614f03141652d6ada51b2 - $ echo -n "alice@example.org:example.org:secret" | md5sum 1441a999b257bcd0cf5166930039876a -
In both examples, the realm is example.org.
In the first case, the user authenticates using the
username alice. In the second case, the user
authenticates using the username alice@example.org.
This second permutation is referred to by some products as
HA1B. Some people prefer to use the full
user@domain syntax to support virtual hosting
with a single realm value on a single SIP
proxy or TURN server.