The architecture is completely distributed. Internet-style alternate servers
using DNS for load distribution provide a high degree of reliability. Single
points of failure are thus avoided. There is no need to rely on boxes that have
the infamous “five nines” of the PSTN.
Two or more levels of authentication are required in this architecture. Users
need to authenticate themselves to the controller, and controllers need to
authenticate themselves to the various servers, especially if some of the ser-
vices are outsourced.
In the examples that follow, PSTN-IP VoIP gateways are not shown for clar-
ity in describing the SIP call flows.
The Control of Service Context
The use of the SIP URI described in Chapter 4, “DNS and ENUM,” is all that’s
required to build complex component service systems for large provider net-
works. A good example would be the options for addressing a voicemail
server and the various functions of voicemail [6]. The various voicemail func-
tions are shown in Table 19.1 with three options to design the SIP URIs:
- The function is the name in the user part of the SIP URI.
- A voicemail phone number is used separately for each user and each
voicemail function. - Use the attribute modein the domain part to distinguish the functions
for the same SIP URI.
Table 19.1 Options for Service Context for Voicemail Using the SIP URI
URI IDENTITY EXAMPLE SCHEME 1
EXAMPLE SCHEME 2
EXAMPLE SCHEME 3
Deposit with standard sip:[email protected]
greeting sip:[email protected]
sip:[email protected];mode=deposit
Deposit with on phone sip:sub-rjs-deposit-busy.vm.mci.com
greeting sip:[email protected]
sip:[email protected];mode=3991243
Deposit with special sip:[email protected]
greeting sip:[email protected]
sip:[email protected];mode=sg
326 Chapter 19