Chapter 26 Multimedia Telephony Services: PSTN/ISDN Simulation Services We described earlier that the core IMS enables multimedia services and traditional telephony services. In this section we focus on the traditional telephony services that, in the context of the PSTN and ISDN, are globally known as PSTN/ISDN supplementary services. Traditional supplementary services are: Call Forwarding, Call Hold/Resume, Connected Line Identification Presentation/Restriction, etc. In IMS, Applications Servers (ASes) are also able to provide PSTN/ISDN simulation services. These are telephony services similar in nature to the PSTN/ISDN supplementary services, but different in the realization since SIP is the call control protocol and is quite different to the PSTN/ISDN protocols. PSTN/ISDN simulation services are a simulated version of the PSTN/ISDN supplementary services. However, the aim of the service remains. A number of these PSTN/ISDN simulation services are specified. Most of them assume an AS that is able to provide the service, either to the originating or to th e terminating party. It is perfectly valid to combine several of these services into a single AS, a decision that is left to the implementors. The PSTN/ISDN simulation services were initially developed by ETSI TISPAN in the context of services for fixed access to IMS. Later, especially when TISPAN IMS merged with 3GPP IMS, the TISPAN-created PSTN/ISDN simulation services were slightly improved for mobile access devices and renamed as IMS multimedia telephony services. Through this chapter we used both terms, IMS multimedia telephony services and PSTN/IS DN simulation services in an interchangeable manner. As for documentation aspects, 3GPP combines all of these services in a single specification, 3GPP TS 24.173 [36], which is an umbrella that contains pointers to each of the specifications that describe one or more related services. However, for historical reasons, ETSI published the set of PSTN/ISDN simulation services in the ETSI namespace of specifications. Each service or group of related services is described as a separate specification. Later, those ETSI specifications were contributed to 3GPP, and published under the 3GPP namespace. In general, the reader who is interested in more information should be looking at 3GPP TS 24.173 [36]. PSTN/ISDN simulation services were developed with a clear focus on compatibility with existing PSTN/ISDN supplementary services. Although PSTN/ISDN simulation services were originally created in the context of fixed broadband access to IMS, they have been embraced and are nowadays part of the full IMS, including wireless devices. ´ıa- M ar t´ın The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition Gonzalo Camarillo and Miguel A. Garc © 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1 530 CHAPTER 26. MULTIMEDIA TELEPHONY SERVICES Each PSTN/ISDN simulation service is based on the corresponding supplementary service in the PSTN/ISDN. However, in many cases the name of the service is change d in IMS, since in SIP the concept of a call can be broadened with messages, subscriptions, notifications, or multimedia sessions. Therefore, most of the PSTN/ISDN simulation services refer to communication rather than calls. In Table 26.1 we take a brief look at each of these PSTN/ISDN simulation services. The O/T column indicates whether the service is provided to the originating side of a call (i.e., the caller) or the terminating side (i.e., the callee). 26.1 Providing Audible Announcements Before we start looking into the different Multimedia Telephony Services, we ought to describe a common building block that is used by a few of these services: providing an audible announcement. In effect, this is inherited from the PSTN/ISDN services, where the only mechanism to provide feedback to the user was to provide an audible announcement. In IMS, one could use other mechanisms to provide feedback, such as sending an instant message, rendering a web page in the display of the phone, etc. However, the common minimum denominator, device-independent mechanism, is to provide an audible announcement. This section describes the different ways to provide an audible announcement. These feature can be used by most of the Multimedia Telephony Services that we describe in the following sections. The procedures for audible announcements are specified in ETSI TS 183 028 [142] and its equivalent 3GPP TS 24.628 [60]. Audible announcements can be provided at the time a session is being established, during an established session, or at the time the session is being released. The procedures are slightly different in each case. Audible announcements can also be sent when a session attempt is rejected. 26.1.1 Announcement at the Time a Session is Being Established In the case of an audible announcement that is provided at the time the session is being established there are four different ways to implement it. (i) If the announcement is to be rendered at the callee, then the Call-Info header field in the INVITE request carries the SIP or HTTP URI that identifies the source of the announcement. This makes the callee’s terminal fetch the URL included in the header and render it to the user. (ii) If the announcement is to be rendered at the caller, then an Alert-Info header field is included in a 180 (Ringing) response. The header contains a SIP or HTTP URI that identifies the source of the announcement. The caller’s terminal fetches the URL included in the header and renders it to the user. (iii) Using the Early Media mechanisms for the gateway model specified in RFC 3960 [111] in conjunction with the P-Early-Media header field (specified in RFC 5009 [128]). (iv) Using the Early Media mechanisms in an early dialog, as specified in RFC 3960 [111], in conjunction with the P-Early-Media header field (specified in RFC 5009 [128]). The overall effect consists of the caller having two early SIP dialogs at the time the session is being established. One dialog is establishe d between the caller and the 26.1. PROVIDING AUDIBLE ANNOUNCEMENTS 531 Table 26.1: PSTN/ISDN simulation services in IMS PSTN/ISDN simulation PSTN/ISDN supplementary Abbreviation service service O/T CDIV Communication Diversion Call Diversion T CFU Communication Forwarding Unconditional Call Forwarding Unconditional T CFB Communication Forwarding on Busy user Call Forwarding Busy T CFNR Communication Forwarding on No Reply Call Forwarding No Reply T CFNL Communication Forwarding on Not Logged-in —T CONF Conference Conference Calling O/T MWI Message Waiting Indication Message Waiting Indication T OIP Originatin g Identification Presentation Calling Line Identification Presentation T OIR Originatin g Identification Restriction Calling Line Identification Restriction O TIP Terminating Identification Presentation Connected Line Identification Presentation O TIR Terminating Identification Restriction Connected Line Identification Restriction T CW Communication Waiting Call Waiting T HOLD Communication Hold Call Hold O/T ACR Anonymous Communication Rejection Anonymous Call Rejection T CB Communication B arring Call Barring O/T ICB Incoming Communication Barring Incoming Call Barring T OCB Outgoing Communication Barring Outgoing Call Barring O AoC Advice of Charge Advice of Charge O CCBS Completion of Communications to Busy Subscriber Completion of Calls to Busy Subscriber O CCNR Completion of Communications on No Reply Completion of Calls on No Reply O MCID Malicious Communication Identification Malicious Call Identification T ECT Explicit Communication Transfer Explicit Call Transfer O/T 532 CHAPTER 26. MULTIMEDIA TELEPHONY SERVICES callee; the other is established between the caller and the AS. The AS can then send unidirectional early media on the pre-session established with that early dialog. Figure 26.1: Announcement to the callee using the Call-Info header field Figure 26.1 shows the realization of an announcement played to the callee b y using the mechanism based on the Call-Info header field. The S-CSCF and AS can be located in either the caller’s or the callee’s network. The call flow starts when the S-CSCF receives an INVITE request (1) that, due to initial Filter Criteria evaluation, is fo rwarded (3) to an AS. The AS inserts a protoCall-Info header field that contains an HTTP link pointing to a file located in the AS itself. Then the AS perfo rms regular routing and forwards back the request (5) to the S-CSCF, which further routes it (7) to is destination. The callee receives the INVITE request (7) and invokes the URL included in the Call-Info header field, sending 26.1. PROVIDING AUDIBLE ANNOUNCEMENTS 533 then an HTTP GET request (9) to retrieve the file, which is sent in a 200 (OK) response (10). Then the callee locally plays that file. The callee also sends a 180 (Ringing) response (11) which is forwarded back to the user. The session setup continues as per regular procedures. Figure 26.2: Announcement to the caller using the Alert-Info header field Figure 26.2 shows the realization of an announcement played to the caller by using the mechanism based on the Alert-Info header field. The S-CSCF and AS can be located in either the caller’s or the callee’s network. The call flow starts when the S-CSCF receives an INVITE request (1) that, due to initial Filter Criteria evaluation, it is forwarded (3) to an AS. The AS performs regular routing and forwards back the request (5) to the S-CSCF, which further routes it (7) to is destination. At some point in time the callee sends a 180 (Ringing) response (9) that is received at the AS (10). The AS then adds an Alert-Info header field 534 CHAPTER 26. MULTIMEDIA TELEPHONY SERVICES that contains an HTTP link pointing to a file located on the AS itself and forward the 180 (Ringing) response (11) back to the S-CSCF and the caller (12). The caller then invokes the URI included in the Alert-Info header field of the 180 (Ringing) response; in this case, since it is an HTTP URI, it invokes an HTTP GET request (13) to retr ieve the file, which is sent in a 200 (OK) response (14). The caller plays the announcement as a ringing tone until the session is setup (i.e., reception of a 200 (OK) response for an INVITE request). Figure 26.3: Announcement during the establishment of a session. Early m edia with early dialog Figure 26.3 depicts the call flow applicable to one of these mechanisms to provide an announcement at the time the session is established. The flow, which uses the early media mechanisms, assumes an AS that can be serving eith er th e caller or callee. The flow starts when a S-CSCF, either in the caller or callee network, receives an INVITE request (1) to establish a new session. Becau se o f initial Filter Criteria evaluation, the S-CSCF routes the INVITE request (3) to an AS, which, together with the MRF, decides to play an announcement. The AS interacts with the MRFC to provide the announcement. The MRFC interacts (5) with the MRFP to provide the connection address for an early dialog. The MRFC then creates a reliable 183 (Session Progress) response (6) that contains SDP with 26.1. PROVIDING AUDIBLE ANNOUNCEMENTS 535 the connection parameters of the MRFP. This 183 response also contains a P-Early-Media header field indicating that authorized early media will be sent in sendonly mode. Since this 183 (Session Progress) response contains SDP, it is sent reliably to the caller, so, it requires to be acknowledged with a PRACK request (8, 9), which is responded with a corresponding 200 (OK) response (10, 11). At this point in time, the caller is able to receive audio from the MRFP. The MRFC then commands (12) the MRFP to start playing the announcement. The MRFP plays the announcement (13), and when it finishes, it interacts (14) with the MRFC to inform it. The MRFC interacts with the AS to continue processing the initial INVITE request, which is routed to its destination via the S-CSCF (15, 17). The session setup continues as per regular procedures. 26.1.2 Announcement During the Duration of the Session In the case of an audible announcement that is provided at any time when the session has been already established, there are two mechanisms to implement it. Both of them require the presence of an AS in the signaling path acting as a B2BUA. • The AS creates a re-INVITE request that contains a Call-Info header field pointing to the source of the announcement. This re-INVITE request can be sent to either the caller, the callee, or both. • The AS reuses the existing audio media stream to play media o n it. This might require a re-INVITE to change the connection address or the supported media types (codecs). 26.1.3 Announcement at the End of the Session An AS that is already in the signaling path acting as a B2BUA may also send an audible announcement towards the end of the session. In this case the mechanism consists of delaying the release of the session and reusing either the established audio media stream, or creating an additional one, to play the announcement. 26.1.4 Announcement When a Session is Rejected Audible announcements can be also provided when an Application Server is rejecting the establishment of a session. Assume that a caller sends an INVITE request that is received by an AS which decides to reject the call. The AS wants to provide an audible announcement to the caller, potentially indicating the reasons for the rejection. In this case, there are four mechanisms to implement the announcement. • The AS includes an Error-Info header field in a 300, 400, 500, or 600 class response to the INVITE request. The Error-Info header field contains a URL that points to the source of the announcement. • Using the Early Media mechanisms for the gateway model specified in RFC 3960 [111] in conjunction with the P-Early-Media header field (specified in RFC 5009 [128]) and the Reason header field containing a cause value. • Using the Early Media mechanisms in an early dialog specified in RFC 3960 [111] in conjunction with the P-Early-Media header field (specified in RFC 5009 [128]) and the Reason header field containing a cause value. 536 CHAPTER 26. MULTIMEDIA TELEPHONY SERVICES • The AS first accepts the communication request, plays the in-band announcement over the established audio media stream, and then tears down the session. 26.2 Communication Diversion (CDIV) and Communication Forwarding The Communication Diversion service allows a user to divert their communications to another user. The service is specified in ETSI TS 183 004 [134] and 3GPP TS 24.604 [65] and comprises a number of diversion services: Communication Forwarding Uncondi- tional (CFU), Communication Forwarding on Busy user (CFB), Communication Forwarding on No Reply (CFNR), Communication Deflection (CD), Communication Forwarding o n Subscriber Not Reachable (CFNRc), and Communication Forwarding on Not Logged- in (CFNL). The service is implemented in an application server that, depending on the actual service, automatically diverts all session attempts to the g iven user, or after the SIP request has been sent to the user, but the user sent a busy response, did not answer, etc. CDIV also implements the History-Info header field to record a f orwarding operation. This allows both the caller and callee to learn that the call has suffered some forwarding en route. We described the History-Info in Section 5.9.1. Let us take a look at the service flow with the help of Figure 26.4. The reader may have noticed that the figure is quite simplified and only nodes and signaling flows that are relevant for the implementation of the service are depicted. According to Figure 26.4, the S-CSCF that is responsible for the called party receives an INVITE request (1), addressed in the Request-URI to the called party, e.g., sip:bob@home2.net. The S-CSCF evaluates the initial Filter Criteria an d, as a result, forwards the INVITE request (2) to an AS, wh ich happens to execute the Communication Forwarding Unconditional service. If the AS is acting as a Back-To-Back User Agent, then it can terminate the SIP signaling and generate a 181 (Call is being forwarded) response back to the calling party. The B2BUA AS, as part of the service logic, replaces the Request-URI field with that of the diverted user, e.g., sip:charlie@home3.net, creates a new SIP dialog, and generates a n ew INVITE request addressed to the new target. If the AS is acting as a proxy, the procedures are similar, except that the AS does not generate 181 responses, and continues to proxy the received INVITE request, therefore, keeping the From, To, Call-ID, etc. header fields intact. The AS also records the retargeting when it adds a new value to the History-Info header field. Figure 26.5 shows an example of this History-Info header field. The first entry in the History-Info header field denotes the original Request-URI, while the second entry indicates the retargeted URI. The cause parameter, specified in RFC 4458 [192], which receives the code 302, has the purpose of indicating the type of communication diversion service. Table 26.2 contains the complete list of redirection codes and their mapping to communication diversion services. Since the History-Info header field might create privacy concerns, a new value called history is added to the Privacy header field. A user who does not want the network to record the history information adds the history value to the Privacy header field. 26.3. COMMUNICATION DIVERSION NOTIFICATION (CDIVN) 537 Figure 26.4: Communication Diversion: Communication Forwarding Unconditional History-Info: <sip:bob@home2.net>;index=1, <sip:charlie@home3.net;Reason=SIP;cause=302>;index=1.1 Figure 26.5: The AS inserts a History-Info header field to INVITE request (5) Table 26.2: Mapping between diversion conditions and the cause parameter code Communication diversion condition Code Communication Forwarding Busy 486 Communication Forwarding on No Reply 408 Communication Forwarding Unconditional 302 Communication Forwarding on Not Logged-in 404 Communication Forwarding on Subscriber Not reachable 503 Communication Deflection (Immediate response) 480 Communication Deflection (During Alerting) 487 26.3 Communication Diversion Notification (CDIVN) The Communication Diversion Notification (CDIVN) is not a service by itself, but a complement to CDIV. It allows users of the CDIV service to be informed when the service is actually executed, i.e., when a diversion is served to the user. 538 CHAPTER 26. MULTIMEDIA TELEPHONY SERVICES CDIVN is implemented on top of the SIP-event notification fra mework specified in RFC 3265 [264]. The service has defined a new event package, called comm-div-info, whose data format provides the required notification information. When a UA wants to use the CDIVN service, it sends a SUBSCRIBE request addressed to the Public User Identity of the user. The Event header field is populated with the name of the event package: comm-div-info. This SUBSCRIBE request is routed, with the help of the initial Filter Criteria, to the AS that executes CDIV serv ices. T hen, whenever the CDIV AS executes a diversion to this user, it sends a notification with detailed information. Figure 26.6: Communication D iversion Notification Figure 26.6 depicts a complete flow including Communication Diversion and Commu- nication Diversion Notification. There are three users and three networks involved. For the sake of simplicity, only relevant nodes and messages are shown. The flow starts when the u ser who has activated the CDIV service subscribes to the complementary CDIVN service by sending a SUBSCRIBE request (1) addressed to himself, and containing the Event header field set to the comm-div-info event. His S-CSCF receives the request, evaluates the initial Filter Criteria, and forwards the SUBSCRIBE request (2) [...]... subtotal EUR 0.22 normal-charging Figure 26. 11: Example of an AoC XML document An associated MIME type of application/vnd.etsi.aoc+xml identifies an AoC XML document in a Content-Type header field of the message... Figure 26. 11 shows an example of one of these charging documents that contains AoC-S and AoC-D information . Chapter 26 Multimedia Telephony Services: PSTN/ISDN Simulation Services We described earlier that the core IMS enables multimedia services and traditional telephony services. In. Sons, Ltd. ISBN: 97 8- 0- 47 0- 5166 2- 1 530 CHAPTER 26. MULTIMEDIA TELEPHONY SERVICES Each PSTN/ISDN simulation service is based on the corresponding supplementary service in the PSTN/ISDN. However,. 22:12:31 -0 700 Priority: normal Message-ID: 267 75334485@mwi.home1.net Message-Context: video-message Figure 26. 8: NOTIFY request (7) in the MWI service 542 CHAPTER 26. MULTIMEDIA TELEPHONY SERVICES it