Tech-Report Number CUCS-002-99
`
`Implementing Intelligent Network Services with the Session
`Initiation Protocol
`
`Jonathan Lennox
`Department of Computer Science
`Columbia University
`lennox@cs.columbia.edu
`Phone: (212) 939 7018
`
`Henning Schulzrinne
`Department of Computer Science
`Columbia University
`hgs@cs.columbia.edu
`Phone: (212) 939 7042
`
`Thomas F. La Porta
`Bell Laboratories
`Lucent Technologies
`tlp@bell-labs.com
`Phone: (732) 949-2281
`
`Internet telephony is receiving increasing interest as an alternative to traditional telephone networks. This article
`shows how the IETF’s Session Initiation Protocol (SIP) can be used to perform the services of traditional Intelligent
`Network protocols, as well as additional services.
`
`Abstract
`
`0
`
`Bright House Networks - Ex. 1025, Page 1
`
`

`
`Contents
`
`1
`
`Introduction
`
`2 Overview
`2.1 Billing . .
`
`. . . .
`
`. . .
`
`. . . .
`
`. . . .
`
`. . . .
`
`. . .
`
`. . . .
`
`. . . .
`
`. . . .
`
`. . . .
`
`. . .
`
`. . . .
`
`. . . .
`
`3 Architecture of IPtel signaling
`
`4 Capability Set 1: Service Features
`. . . .
`. . . .
`4.1 Abbreviated Dialing (ABD) . .
`. . . .
`. . . .
`4.2 Attendant (ATT) .
`. . .
`. . . .
`. . . .
`. . . .
`4.3 Authentication (AUTC) . . . .
`. . . .
`. . . .
`4.4 Authorization code (AUTZ)
`.
`. . . .
`. . . .
`4.5 Automatic call back (ACB) . .
`. . . .
`. . . .
`4.6 Call distribution (CD) .
`. . . .
`. . . .
`. . . .
`4.7 Call forwarding (CF)
`.
`. . . .
`4.8 Call forwarding on busy/don’t answer (CFC)
`4.9 Call gapping (GAP) . .
`. . . .
`. . . .
`. . . .
`4.10 Call hold with announcement (CHA) .
`. . . .
`4.11 Call limiter (LIM) . . .
`. . . .
`. . . .
`. . . .
`4.12 Call logging (LOG) . . . . . .
`. . . .
`. . . .
`4.13 Call queueing (QUE) .
`. . . .
`. . . .
`. . . .
`4.14 Call transfer (TRA) . .
`. . . .
`. . . .
`. . . .
`4.15 Call waiting (CW) . . .
`. . . .
`. . . .
`. . . .
`4.16 Closed user group (CUG) . . .
`. . . .
`. . . .
`4.17 Consultation calling (COC) . .
`. . . .
`. . . .
`4.18 Customer profile management (CPM)
`. . . .
`4.19 Customer recorded announcement (CRA)
`. .
`4.20 Customized ringing (CRG) . .
`. . . .
`. . . .
`4.21 Destinating user prompter (DUP) . . .
`. . . .
`4.22 Follow-me diversion (FMD)
`.
`. . . .
`. . . .
`4.23 Mass calling (MAS) . .
`. . . .
`. . . .
`. . . .
`4.24 Meet-me conference (MMC) .
`. . . .
`. . . .
`4.25 Multi-way calling (MWC)
`. .
`. . . .
`. . . .
`4.26 Off-net access (OFA) .
`. . . .
`. . . .
`. . . .
`4.27 Off-net calling (ONC) .
`. . . .
`. . . .
`. . . .
`4.28 One number (ONE) . .
`. . . .
`. . . .
`. . . .
`4.29 Origin dependent routing (ODR) . . .
`. . . .
`4.30 Originating call screening (OCS) . . .
`. . . .
`4.31 Originating user prompter (OUP) . . .
`. . . .
`4.32 Personal numbering (PN) . . .
`. . . .
`. . . .
`4.33 Premium charging (PRMC) . .
`. . . .
`. . . .
`4.34 Private numbering plan (PNP)
`. . . .
`. . . .
`4.35 Reverse charging (REVC)
`. .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`
`1
`
`3
`
`3
`4
`
`4
`
`4
`5
`5
`5
`5
`7
`7
`7
`7
`7
`8
`8
`8
`9
`9
`9
`9
`10
`10
`10
`10
`11
`11
`11
`11
`11
`12
`12
`12
`12
`13
`13
`13
`14
`14
`14
`
`Bright House Networks - Ex. 1025, Page 2
`
`

`
`. . . .
`. . . .
`4.36 Split charging (SPLC) .
`4.37 Terminating call screening (TCS) . . .
`4.38 Time dependent routing (TDR) . . . .
`
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`
`5 Capability Set 1: Services
`. . . .
`. . .
`. . . .
`. . . .
`.
`5.1 Abbreviated dialling (ABD)
`. . . .
`. . .
`. . . .
`. . . .
`.
`5.2 Account card calling (ACC)
`. . . .
`. . .
`5.3 Automatic alternative billing (AAB) . . . . .
`. . . .
`. . .
`5.4 Call distribution (CD) .
`. . . .
`. . . .
`. . . .
`. . . .
`. . .
`5.5 Call forwarding (CF)
`.
`. . . .
`. . . .
`. . . .
`. . . .
`. . .
`5.6 Call rerouting distribution (CRD) . . .
`. . . .
`. . . .
`. .
`5.7 Completion of calls to busy subscriber (CCBS)
`. . . .
`. . .
`5.8 Conference calling (CON)
`. .
`. . . .
`. . . .
`. . . .
`. . .
`5.8.1 Conference calling add-on . .
`. . . .
`. . . .
`. . .
`5.8.2 Conference calling meet-me .
`. . . .
`. . . .
`. . .
`5.9 Credit card calling (CCC) . . .
`. . . .
`. . . .
`. . . .
`. . .
`5.10 Destination call routing (DCR) . . . .
`. . . .
`. . . .
`. . .
`5.11 Follow-me diversion (FMD)
`.
`. . . .
`. . . .
`. . . .
`. . .
`5.12 Freephone (FPH)
`. . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . .
`5.13 Malicious call identification (MCI) . .
`. . . .
`. . . .
`. . .
`5.14 Mass calling (MAS) . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . .
`5.15 Originating call screening (OCS) . . .
`. . . .
`. . . .
`. . .
`5.16 Premium rate (PRM)
`.
`. . . .
`. . . .
`. . . .
`. . . .
`. . .
`5.17 Security screening (SEC) . . .
`. . . .
`. . . .
`5.18 Selective call forwarding on busy/don’t answer (SCF) . . .
`5.19 Selective call forwarding . . .
`. . . .
`. . . .
`. . .
`. . . .
`5.20 Call forwarding on busy . . .
`. . . .
`. . . .
`. . .
`. . . .
`5.21 Call forwarding on don’t answer (no reply)
`.
`. . . . . . .
`5.22 Split charging (SPL)
`.
`. . . .
`. . . .
`. . . .
`. . .
`. . . .
`5.23 Televoting (VOT) . . .
`. . . .
`. . . .
`. . . .
`. . .
`. . . .
`5.24 Terminating call screening (TCS) . . .
`. . . .
`. . .
`. . . .
`5.25 Universal access number (UAN)
`. . . . . . .
`. . .
`. . . .
`5.26 Universal personal telecommunications (UPT) . . .
`. . . .
`5.27 User-defined routing (UDR)
`.
`. . . .
`. . . .
`. . .
`. . . .
`5.28 Virtual private network (VPN)
`. . . .
`. . . .
`. . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`. . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`6 Capability Set 2
`6.1 Wireless services . . .
`6.2
`Inter-network services .
`6.3 Multimedia . . .
`. . .
`6.4 Call pick-up . . .
`. . .
`6.5 Calling name delivery .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`. . .
`. . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`. . .
`. . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`. . . .
`
`14
`14
`15
`
`15
`15
`15
`15
`16
`17
`17
`17
`18
`18
`18
`18
`19
`19
`19
`20
`20
`20
`20
`20
`21
`21
`21
`21
`21
`21
`21
`22
`22
`22
`22
`
`23
`23
`23
`23
`24
`24
`
`2
`
`Bright House Networks - Ex. 1025, Page 3
`
`

`
`7 SIP Services not in IN
`7.1 OPTIONS . . .
`. . . .
`. . . .
`. . .
`. . . .
`. . .
`7.2 Third-party Call Control
`7.3 Additional invitation parameters . . .
`7.4 Forwarding short-circuiting . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`. . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . .
`. . .
`. . .
`. . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`
`. . . .
`. . . .
`. . . .
`. . . .
`
`24
`24
`24
`25
`25
`
`1 Introduction
`
`In the development of Internet telephony, we want to ensure that all the features supported by modern advanced
`telephony systems can be supported. This article describes many of the features as they are implemented in traditional
`telephone networks, and then describes how they can be implemented in Internet Telephony with the IETF’s Session
`Initiation Protocol and its extensions.
`The initial task of enumerating a large number of advanced telephony services is the same one that Study Group
`11 of the International Telecommunications Union Telecommunications Standards Sector (ITU-T) addressed in the
`process of developing their standards for Intelligent Networks. The study group published its accumulated descriptions
`of services and service features in Annex B of ITU-T recommendation Q.1211: Introduction to Intelligent Network
`Capability Set 1 [1]. Since these service descriptions were compiled from a number of disparate sources, the document
`acknowledges that they may be self- and mutually-inconsistent.
`This paper will describe the implementation of Internet Telephony services by following Q.1211’s descriptions
`of each service and service feature, noting the specific description of each one so as to clarify the ambiguities and
`inconsistencies in the descriptions.
`Study Group 11 has written a follow-up document, Q.1221: Introduction to Intelligent Network Capability Set
`2. This document has not yet been formally ratified or released by the ITU; I address it, in less exhaustive detail, in
`section 6.
`
`2 Overview
`
`The architectural model of Internet telephony is rather different than that of the traditional telephone network. The
`base assumption is that all signaling and media flow over an IP-based network, either the public Internet or various
`intranets. This is a dramatic change in the ability of nodes in the network to communicate: in the traditional telephone
`architecture, nodes can generally only communicate with those other nodes to which they are directly connected.1
`IP-based networks, on the other hand, present the appearance at the network level that any machine can communicate
`directly with any other, unless the network specifically restricts them from doing so, through such means as firewalls.
`This architectural change necessitates a dramatic transformation in the architectural assumptions of traditional
`telephone networks. In particular, whereas in a traditional network a large amount of administrative control, such
`as call-volume limitation, implicitly resides at every switch, and thus additional controls can easily be added there
`without much architectural change, in an Internet environment an administrative point of control must be explicitly
`engineered into a network, as in a firewall; otherwise end systems can simply bypass any device which attempts to
`restrict their behavior.
`In addition, the Internet model transforms the locations at which many services are performed. In general, end
`systems are assumed to be much more intelligent than in the traditional telephone model; thus, many services which
`traditionally had to reside within the network can be moved out to the edges, without requiring any explicit support
`for them within the network. Other services can be performed by widely separated specialized servers which result in
`call setup information traversing paths which might be extremely indirect when compared with the physical network’s
`actual topology.
`
`1This is somewhat of an oversimplification for the modern SS7 backbone signalling network. Signals do not necessarily follow the same physical
`path as the trunks; however, except for some specialized functions such as lookups in the 800-number database, call-setup signals must proceed
`hop-by-hop from one switch to another, indirectly following the trunks’ path.
`
`3
`
`Bright House Networks - Ex. 1025, Page 4
`
`

`
`Most of the services and service features of ITU-T Q.1211 can be provided by the IETF’s draft signaling standards
`for Internet Telephony, SIP (the Session Initiation Protocol) [2] and, for some more specialized features, its Call
`Control extensions [3].
`
`2.1 Billing
`
`The one broad class of features which cannot be directly provided by SIP and SIP-CC is those which involve payment
`responsibility. In Internet telephony, it is still somewhat unclear what services can actually be charged for; clearly, for
`those services which can be performed by end systems, an external entity cannot expect to exact any fee for them, other
`than the one-time sales price the vendor of the end-system or its software receives. Those services which do reside in
`the network can be generally divided up into three categories: those residing at a single point, such as user-location
`or premium-rate end systems; those which involve better-than-best-effort packet delivery; and those which leave the
`Internet for some other network, such as PSTN gateways.
`A number of billing models are possible for each of these types of services. Three of them seem to be most likely:
`the subscription model, the “New Jersey Turnpike” model, and the “Garden State Parkway” model. The subscription
`model involves a user paying for an unlimited amount of service in advance; this is most likely applicable for the
`single-point services discussed above. The “New Jersey Turnpike” model is payment by settlement — when a service
`is initiated, the user commits to paying after completion for however much service he or she has used. This is the
`model of current residential or charge-card service in traditional telephony. The third model, “Garden State Parkway”,
`is pay as you go; a user commits some token before the service is initiated which allows a certain amount of service,
`and commits further tokens along the way. This is the model of traditional coin-operated telephone calls, or pre-paid
`calling cards.
`Regardless of the billing model used, the format of billing information for Internet telephony is essentially orthog-
`onal to questions of its signalling. Work is currently ongoing in the IETF’s Internet Open Trading Protocol working
`group to define standards for exchange of such information.
`
`3 Architecture of IPtel signaling
`
`The flow and control model of SIP signaling is generally based on the existing models of Internet e-mail (operating at
`signaling rather than background-batch speeds) and (to a somewhat lesser extent) the World Wide Web.
`Every SIP address specifies (through the usual DNS-style addressing) a server domain in which the address resides.
`Addressing is deliberately reminiscent of e-mail: sip:huseri@hdomaini or sip:huseri@hhosti. An end system,
`when placing a call, will either directly look up the remote destination specified in the address, to send it the SIP
`invitation directly, or it will forward the call invitation to a local proxy, which will perform this lookup function for it
`(and can perform other functions as well). The resolved destination may be the address of the actual destination end
`system; it may be a recipient-side proxy, which handles such services as user location and firewall punch-through; or
`it could be a redirection server, which informs the originating station of a different server at which it should search for
`the user.
`It is important to note that unless specifically architected (as in firewalls) no proxy server can guarantee that it will
`be on the server path for calls between any pair of end systems. Also note that the majority of the Internet path over
`which both media and signals will flow (the backbone) will never see any signaling information as anything other than
`IP packets to be routed to their destinations.
`Some more specific details of the Internet telephony architecture are discussed in the sections describing their
`corresponding IN services.
`
`4 Capability Set 1: Service Features
`
`Q.1211 divides the services it describes into two broad categories: “services,” which are what an Intelligent Network
`vendor would actually wish to provide to customers; and “service features,” which are lower-level building blocks
`used to construct the services.
`
`4
`
`Bright House Networks - Ex. 1025, Page 5
`
`

`
`This section describes all the service features listed in Q.1211, Annex B, section 2; Section 5 describes the services
`built out of these service features (from Annex B section 1), and any unique aspects of them in the Internet telephony
`environment.
`For each service, Q.1211 lists a number of service features which are considered either core to it, those without
`which it would not be useful, or optional, which provide added value to the feature. For each service feature, this sec-
`tion lists the services which Q.1211 specifies use that feature. Similarly, in section 5, each service lists its component
`service features.
`See table 1 for a summary of the characteristics of each service feature.
`
`4.1 Abbreviated Dialing (ABD)
`
`Used for: ABD (core); ACC (core); AAB (optional); CCC (optional); VPN (optional)
`
`Abbreviated dialing allows the definition of short (e.g., two digit) digit sequences to represent the
`actual dialing digit sequence for a public or private numbering scheme.
`
`In Internet telephony, an end system would typically do this work; either by storing an internal table of locally-
`defined shortcut addresses for the actual addresses it would send, or (for setups more analogous to VPNs) by having
`end systems configured to consult a local database server (running, e.g., LDAP) for address-translation queries.
`This translation could also be performed by a local proxy or redirection server through which the end system
`always sends its outgoing call requests.
`
`4.2 Attendant (ATT)
`
`Used for: VPN (optional)
`
`This allows VPN users to access an attendant (operator) position within the VPN for providing VPN
`service information (e.g, VPN numbers) by dialing a special access code.
`
`An Internet telephony end system needs only to be configured with an address of an appropriate local operator to
`translate the special access code to the actual local address of an attendant, or some address which will resolve to that
`address.
`
`4.3 Authentication (AUTC)
`
`Used for: FPH (optional); SEC (core); VPN (optional)
`
`This allows verification that a user is allowed to access certain options in the telephone network.
`
`SIP allows for transactions to be authenticated, using either the standard HTTP “basic” or “digest” authentication,
`or an extended authentication using more sophisticated methods such as PGP or S/MIME. Unlike in the traditional
`telephone system, calls can be authenticated end-to-end to remote parties, in addition to providing authentication to
`the signaling infrastructure; these are the Authenticate and Proxy-Authenticate headers respectively.
`
`4.4 Authorization code (AUTZ)
`
`Used for: ACC (core); AAB (core); CCC (core); UPT (core); VPN (optional)
`
`This allows a user (typically in a VPN) to override the restrictions placed on the system from which
`calls are made.
`
`This can be accomplished by using Proxy-Authenticate as described in the previous service feature, or, in simpler
`situations, by specifying a password in a SIP URL.
`
`5
`
`Bright House Networks - Ex. 1025, Page 6
`
`

`
`Characteristics
`Section Location
`
`Service Feature
`Code
`Name
`Authentication
`AUTC Authentication
`AUTZ Authorization code
`Billing
`PRMC Premium charging
`REVC Reverse charging
`SPLC
`Split charging
`Filtering
`Originating call screening
`OCS
`Terminating call screening
`TCS
`Forwarding
`CD
`Call distribution
`CF
`Call forwarding
`CFC
`Call forwarding on busy/don’t answer
`ONE
`One number
`ODR
`Origin dependent routing
`PN
`Personal numbering
`TDR
`Time dependent routing
`Translation
`ABD
`Abbreviated dialling
`ATT
`Attendant
`PNP
`Private numbering plan
`User interface
`CW
`Call waiting
`CRG
`Customized ringing
`Other
`Automatic call back
`ACB
`Call gapping
`GAP
`Call hold with announcement
`CHA
`Call limiter
`LIM
`Call logging
`LOG
`Call queueing
`QUE
`Call transfer
`TRA
`Closed user group
`CUG
`Consultation calling
`COC
`Customer profile management
`CPM
`Customer recorded announcement
`CRA
`Destinating user prompter
`DUP
`Follow-me diversion
`FMD
`Mass calling
`MAS
`MMC Meet-me conference
`MWC Multi-way calling
`OFA
`Off-net access
`ONC
`Off-net calling
`OUP
`Originating user prompter
`
`4.3
`4.4
`
`4.33
`4.35
`4.36
`
`4.30
`4.37
`
`4.6
`4.7
`4.8
`4.28
`4.29
`4.32
`4.38
`
`4.1
`4.2
`4.34
`
`4.15
`4.20
`
`4.5
`4.9
`4.10
`4.11
`4.12
`4.13
`4.14
`4.16
`4.17
`4.18
`4.19
`4.21
`4.22
`4.23
`4.24
`4.25
`4.26
`4.27
`4.31
`
`End / Proxy
`Proxy
`
`-
`-
`-
`
`End / Proxy
`End / Proxy
`
`Proxy / Redirect
`Proxy / Redirect
`Proxy / Redirect
`Proxy / Redirect
`Proxy / Redirect
`Proxy / Redirect
`Proxy / Redirect
`
`End / Proxy / Redirect
`End / Proxy / Redirect
`End / Proxy / Redirect
`
`End
`End
`
`Call Time
`
`Setup
`Setup
`
`-
`-
`-
`
`Setup
`Setup
`
`Setup
`Setup
`Setup
`Setup
`Setup
`Setup
`Setup
`
`Setup
`Setup
`Setup
`
`Setup
`Setup
`
`End
`Proxy
`End
`End
`All
`End / Proxy
`End
`End / Proxy
`End
`End / Proxy / Redirect
`End
`End
`End
`Proxy
`Other
`End
`All
`Proxy
`All
`
`Setup
`Setup
`In call
`Setup
`All
`Setup
`In call
`Setup
`In call
`Indep. of call
`In call
`In call
`Indep. of call
`Setup
`Setup
`Setup
`All
`Setup
`Setup
`
`Table 1: This table indicates the characteristics of each service feature, and sorts them into rough categories. For the
`“location” column, “End” means the service can be provided at an end system, “Proxy” means at a proxy server, and
`“Redirect” at a redirection server.
`
`6
`
`Bright House Networks - Ex. 1025, Page 7
`
`

`
`4.5 Automatic call back (ACB)
`
`Used for: CCBS (core)
`
`This feature allows the called party to automatically call back the calling party of the last call directed
`to the called party.
`
`This can be handled entirely by end systems, which need only store and make available to the user the previous
`invitations they have received. Note that this is not restricted to only the last call; the number of old invitations a SIP
`end system remembers is bounded only by its local storage.
`
`4.6 Call distribution (CD)
`
`Used for: CD (core); DCR (core); FPH (optional); MAS (optional); PRM (optional); SPL (optional); VOT (optional);
`UAN (optional); VPN (optional)
`
`This service feature allows the served user to specify the percentage of calls to be distributed among
`two or more destinations. Other criteria may also apply to the distribution of calls to each destination.
`
`This is one of the core purposes of a proxy (or, potentially, redirect) server, which could make decisions for the
`destination addresses for a request based on any data or state it sees fit, including a random choice or previous call
`volumes.
`
`4.7 Call forwarding (CF)
`
`Used for: CF (core)
`
`This service feature allows the user to have his incoming calls addressed to another number, no matter
`what the called party line status may be.
`
`This is the simplest case of proxying or redirection: unconditionaly directing the calls to the forwarding address.
`
`4.8 Call forwarding on busy/don’t answer (CFC)
`
`Used for: CRF (optional); FPH (optional); PRM (optional); SCF (core); SPL (optional); UAN (optional)
`
`This service feature allows the called user to forward particular calls if the called user is busy or does
`not answer within a specified number of rings.
`
`A proxy server can implement this by awaiting the response to a call invitation. If the target end system does
`responds that it is busy, or does not respond within a certain period of time, the proxy server can initiate a new proxy
`request, or return a redirection. Alternatively, an end system could be configured to return a redirection if it is busy or
`not picked up.
`
`4.9 Call gapping (GAP)
`
`Used for: FPH (optional); PRM (optional); SCF (core); SPL (optional); UAN (optional)
`
`This feature allows the service provider to restrict the number of calls to a served user to prevent
`congestion of the network.
`
`7
`
`Bright House Networks - Ex. 1025, Page 8
`
`

`
`The intended scenario of this service feature is that vast numbers of people simultaneously call the same destination
`address, for instance because it was announced on television, and the network needs to ensure that its servers and
`signalling network are not overloaded.
`The simplest case of this is when the overloaded server does not have the necessary resources to completely fulfill
`the request, but it can still process it and send a basic response. In this case, a SIP server can send a 503 error response,
`“Server Unavailable.”
`Somewhat more complicated is the case when the volume of traffic expected is such that a single server will not be
`able to handle even this class of error responses. In this case, one solution would be to have an “outer ring” of proxy
`servers which can either statelessly forward the request to the actual server, or return a 503 error; the central server
`would communicate with the periphery through non-SIP means to tell them what fraction of requests to let through.
`If network signalling bandwidth is an issue, the outer ring of servers can be dispersed over a large range of network
`locations; DNS load-balancing can be used to distribute signalling information among them.
`
`4.10 Call hold with announcement (CHA)
`
`Used for: VPN (optional)
`
`The call hold with announcement service feature allows a subscriber to place a call on hold with
`options to play music or customized announcements to the held party.
`
`This can be handled simply by switching the media which is being sent to the remote party. It can either originate
`from the same end system, or from a media server, perhaps triggered by a media server control protocol such as RTSP
`[4]. (RTSP servers are normally restricted from sending media to a third party, but if the RTSP server and SIP server
`trust each other this could be overridden.)
`
`4.11 Call limiter (LIM)
`
`Used for: CRD (optional); FPH (optional); MAS (optional); PRM (optional); SPL (optional); VOT (optional); UAN
`(optional)
`
`This service feature allows a served user to specify the maximum number of simultaneous calls to a
`served user’s destination. If the destination is busy, the call may be routed to an alternative destination.
`
`This can easily be done by an end system, which may return redirection messages to an alternate location.
`
`4.12 Call logging (LOG)
`
`Used for: ABD (optional); ACC (optional); AAB (optional); CD (optional); CF (optional); CRD (optional); CCBS
`(optional); CON (optional); CCC (optional); DCR (optional); FMD (optional); FPH (optional); MCI (core); MAS
`(optional); OCS (optional); PRM (optional); SEC (optional); SCF (optional); SPL (optional); VOT (optional); TCS
`(optional); UAN (optional); UPT (optional); UDR (optional); VPN (optional)
`
`This service feature allows for a record to be prepared each time that a call is received to a specified
`telephone number.
`
`Obviously, any element of a SIP system may log anything it wishes, if it has someplace to store the log.
`
`8
`
`Bright House Networks - Ex. 1025, Page 9
`
`

`
`4.13 Call queueing (QUE)
`
`Used for: CRD (optional); FPH (optional); MAS (optional); PRM (optional); SPL (optional); VOT (optional); UAN
`(optional); VPN (optional)
`
`This service feature allows calls which would otherwise be declared busy to be placed in a queue and
`connected as soon as the free condition is detected. Upon entering the queue, the caller hears an initial
`announcement informing the caller the call will be answered when a line is available.
`
`There are two approaches that can be taken to this: SIP-level signaling, or end-system-level queueing. SIP-level
`allows the recipient (whether an end system or proxy) to signal to the caller with a “182 Queued” message, informing
`it of its status. This message cannot specify a media connection per se, but it could include as a payload or a URL
`reference a static media file (or other format, such as HTML) describing the situation or current queue status.
`Alternately, a system could do queueing entirely at an end system, accepting the call from a signaling level and
`directing the call’s media to a server which plays appropriate announcements about the queued call’s state. When the
`call is de-queued to be picked up, the queueing server either transfers the call (if the calling system supports SIP Call
`Control [3]) or proxies the signaling to the appropriate end system while directing the media transmission there. This
`solution is more similar to how call queueing is handled in the traditional telephone network.
`
`4.14 Call transfer (TRA)
`
`Used for: VPN (optional)
`
`The call transfer service feature allows a subscriber to place a call on hold and transfer the call to
`another location.
`
`The SIP Call Control draft allows a wide and flexible variety of decentralized call transfer and multi-party call
`operations. (See section 7.2 for further discussion of this.)
`
`4.15 Call waiting (CW)
`
`Used for: CCBS (optional)
`
`This service feature allows a subscriber to receive a notification that another party is trying to reach
`his number while he is busy talking to another calling party.
`
`Due to the separation of signaling and media in Internet telephony, this feature is entirely an end-system issue. An
`end system which receives a call invitation while in a call may alert the user however it wishes, if it so chooses.
`
`4.16 Closed user group (CUG)
`
`Used for: VPN (optional)
`
`This service feature allows the user to be a member of a set of VPN users who are normally authorized
`to make and receive calls only within the group.
`
`Both making calls and receiving calls within a group are restrictions which in SIP require administrative control
`of end systems. The end systems can either directly enforce these calling restrictions, or they can insist that all their
`signalling go through a fixed local proxy, which enforces these rules.
`Alternately, if the desired closed group corresponds to the end systems on some particular part of the underlying
`network topology, firewalls could keep calls restricted to that sub-network.
`
`9
`
`Bright House Networks - Ex. 1025, Page 10
`
`

`
`4.17 Consultation calling (COC)
`
`Used for: CON (optional); VPN (optional)
`
`The consultation calling service feature allows a subscriber to place a call on hold, in order to initiate
`a new call for consultation.
`
`Initiating new calls is possible at any time in Internet Telephony. Placing a call on hold is a matter of either ignoring
`its media, if bandwidth is not an issue; or, more efficiently, sending it a re-invitation with media turned off. In either
`case, the local end system would likely either stop sending media or transmit a recorded message to the remote party.
`
`4.18 Customer profile management (CPM)
`
`Used for: ABD (optional); CD (optional); CF (optional); CRD (optional); CON (optional); DCR (optional); FMD
`(optional); FPH (optional); MAS (optional); OCS (optional); PRM (optional); SEC (optional); SCF (optional); SPL
`(optional); VOT (optional); TCS (optional); UAN (optional); UPT (optional); UDR (optional); VPN (optional)
`
`This service feature allows the subscriber to real-time manage his service profile, i.e.
`destinations, announcements to be played,