Antonella Napolitano Internet Draft CSELT draft-ricagni-megaco-umts-all-ip-00.txt Giuseppe Ricagni Italtel March 24, 2000 Category: Informational Expires in six months UMTS all-IP Mobility Management, Call and session control Procedures Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. A postscript version of this draft is available at http://195.103.28.224/ricagni/draft-ricagni-megaco-umts-all-ip-00.ps A PDF version of this draft is available at http://195.103.28.224/ricagni/draft-ricagni-megaco-umts-all-ip- 00.pdf Abstract This contribution contains a study aimed at investigating the possible protocols for multimedia call management in 3GPP All-IP networks, and at providing the shared technical background required to chose the most appropriate one. In this first version, call flows are described for multimedia calls using H.248 as the Ricagni, et al. Informational - Expires September 2000 [Page 1] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 call control protocol and for a basic call (voice call) over UMTS IP network. Further versions of this document will investigate other protocols among those selected by 3GPP (H.248, H.323, SIP), and the advantages and drawbacks of each approach will be highlighted. The network reference model is the same one proposed by 3GPP for an all-IP UMTS Core Network. [2] Table of Contents 1 Introduction .......................................................2 2 Assumptions ........................................................4 3 Some guidelines ....................................................5 4 Reference Model ....................................................5 5 Registration Procedure .............................................7 5.1 Attach Function ................................................7 5.2 PDP Context Activation and MEGACO Registration ................7 6 Call Management ....................................................9 6.1 UMTS Mobile-to-UMTS Mobile Call (PDP Context Activation and MEGACO Registration carried out) ...................................10 6.1.1 Some alternatives in the call management ...................12 6.2 UMTS Mobile-to PSTN call ......................................13 7 Security Considerations ...........................................16 8 References ........................................................16 9 Author's Addresses ................................................16 1 Introduction This contribution contains a study aimed to investigate the possible network solutions for multimedia call management. Call flows are described for multimedia calls using H.248 as the call control protocol and for a basic call (voice call) over UMTS IP network. The network reference model is the same one proposed by 3GPP for an all-IP UMTS Core Network. [2] Scenarios described are: . Registration . UMTS Mobile-to-UMTS Mobile call . UMTS Mobile-to-PSTN call Ricagni, et al. Informational - Expires September 2000 [Page 2] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 This document is a very preliminary work, and it might contain some inaccuracies. Further versions of this document will investigate other scenarios, such as 2nd generation GSM ME calls to UMTS IP terminals, GSM-to- PSTN via the IP backbone, calls where the receiving endpoint has not yet established a PDP context when called and others. Other protocols among those selected by 3GPP (H.248, H.323, SIP) will be analysed, and the advantages and drawbacks of each approach will be investigated. So far, some of the benefits that have been identified, deriving by the usage of MEGACO/H.248 are: 1) It renders virtually impossible for a non-compliant (or hacked) ME to bypass the CSCF and perform direct calls towards standard terminals, since MEs do not implement a complete signaling protocol but they are just dumb devices controlled by the CSCF. Control is therefore firmly in the hands of the network operator. 2) Powerful and flexible handling of QOS. A QOS profile can be stored in the Media Gateway Controller (CSCF in 3GPP terms) that can provide different DSCPs/RSVP profiles for different users and, if desired, time of day/day of week. 3) Seamless migration from IP only in the core network, to IP to the BTS, to IP to the ME. . Multiple of the above scenarios can coexist in the same network . Migration to one scenario to the other has no impact on the CSCF 4) Seamless interoperability with PSTN and 2G networks . There is virtually no difference in the call flows depicting the UMTS Mobile-to-UMTS Mobile Call and the UMTS Mobile-to-PSTN Call 5) Also caters for very small network, where CSCF, MGCF and MSC server functionality are implemented in a single machine, which can use the same call control and protocol for every device it controls (MEs, MGWs towards 2G networks, MGWs towards the PSTN) 6) Security: MEGACO mandates usage of IPSEC. Ricagni, et al. Informational - Expires September 2000 [Page 3] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 7) Simplification of the architecture through a reduction of network elements and reference points (CSCFs and MGCFs are virtually the same thing) 2 Assumptions The following assumptions have been considered. . The subscriber profiles are stored in the HSS in the Home Domain. . The HSS is enhanced to support 3GPP specific information (e.g. SGSN Identifier and Serving CSCF Address - the CSCF where the ME is currently registered- ) for user mobility tracking, Mobile equipment IP Address, UMTS service profile). . In case of roaming the subscriber profile in the home network must be interrogated by the serving network at least at registration and part of subscriber profile could be temporarily stored into the serving network. . CSCF is only involved in VOIP and multimedia calls. All other data transfers are handled by standard 3GPP GPRS procedures. . A ME (Mobile Equipment) registration procedure consists logically of a bearer level registration (i.e., GPRS Attach) and an application level registration (MEGACO ServiceChange). . The application level registration procedure entails registration with a Serving CSCF (S-CSCF). . Each CSCF handles MEGACO MGC functionality; address resolution and user location can be handled with HSS contribution. . In each network, when there is more than one CSCF, there is a Default CSCF (D-CSCF). This D-CSCF could take decision about S- CSCF that will serve user, if there is no strict link between GGSN and CSCF. It could be addressed during incoming call setup (i.e. setup for mobile terminated calls). . A Standard GTP tunnel between SGSN and GGSN is used. . SGSN and GGSN are transparent as regards messages exchanged between Mobile Equipment (ME) and CSCF. Ricagni, et al. Informational - Expires September 2000 [Page 4] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 . The MEGACO mid (Name/address of the MEGACO message originator, contained in every message), is an alphanumeric sting defined in [8]. We assume ME mid to be composed of a host prefix that can correspond to the terminal E.164 or IMSI or an alphanumeric username assigned to the ME USIM, and a domain suffix, representing the domain of the home network. . No investigation is made on IP header compression or other issues related to the transport of IP flows over the radio interface 3 Some guidelines In this document some basic guidelines are followed. . When it is possible, existing standards are used for all call management purpose. . When new messages or extensions are proposed, modifications have light impact on the existing standards (e.g. only slight modifications are suggested to GPRS standard) 4 Reference Model The 3GPP all-IP architecture for the UMTS Core Network [2] is showed in Fig. 1. ---- please refer to the postscript version for the figures ---- Figure 1 - 3GPP Reference Architecture. When a user requests service he could be in his Home Network (i.e. the network where it is stored in HSS its subscription profile) or in a Visited Network (i.e. a network belonging to different operator). In the following the most significant scenarios are identified, i.e. cases when the ME is roaming outside its Home PLMN. The ME is served by a SGSN in the Visited Network; i.e. this network is called the Serving Network. Services availability depends on the agreements between operators and may also be dependent on which CSCF the subscriber is registered to: . CSCF in the Home network Ricagni, et al. Informational - Expires September 2000 [Page 5] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 . CSCF in the Visited Network. SGSN could be connected with a GGSN in the Home network or a GGSN in the Visited Network. Since all ME IP traffic is tunneled to the GGSN, the GGSN is linked to CSCF. Four possible scenarios are identified (see Fig. 2): A. Home GGSN; Home CSCF. Both the user plane and the control plane go through Home Network. B. Home GGSN; Visited CSCF. The user plane is in the Home Network, but the control is managed by a visited CSCF. There is a problem with QoS requirements. In fact the Visited Network does not know the Home Network state. Moreover user signalling is handled in a sub-optimal way, as signalling traffic is first tunnelled to the home network, and then routed back to the visited one. This results in an increased post dial delay (The applicability of this case is FFS). C. Visited GGSN; Home CSCF. In this case the Home Network handles only the call control. There is a problem with QoS requirements. In fact Home Network does not know Visited Network state. It is necessary to exchange information with the D-CSCF of the Visited Network. (This case is FFS) D. Visited GGSN; Visited CSCF. Both user and control planes are handled by Visited Network. The Home Network might lose the possibility of manage every call aspects (e.g. call billing). In the Information Flows the differences for each scenario are shown. ---- please refer to the postscript version for the figures ---- Figure 2 _ Scenarios for SGSN connection. In the following, different protocols are highlighted with different arrows style. ---- please refer to the postscript version for the figures ---- Ricagni, et al. Informational - Expires September 2000 [Page 6] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 5 Registration Procedure 5.1 Attach Function The first step in the registration procedure is the bearer level registration with the SGSN in the Serving Network (Fig. 3). The attach procedure is the same of the GPRS one. For details about Attach Function see [3]. Note that SGSN retrieves from HSS the service subscription information with the message "Insert Subscriber Data". From this information SGSN checks if the user can access a MEGACO service. The registration procedure is the same for all scenarios mentioned above; in each scenario only the location of system nodes changes. ---- please refer to the postscript version for the figures ---- Figure 3 _ Attach Function. 5.2 PDP Context Activation and MEGACO Registration The second step is the application level registration. Firstly there is the PDP Context activation and after the MEGACO registration. It is assumed that the ME always first contacts the home D-CSCF (a list of CSCFs in the home domain is assumed to be stored in the ME USIM or can be dynamically retrieved by means of other mechanisms to be defined: e.g. SLP [5]) via a ServiceChange Command specifying the "Root" for the TerminationID and ServiceChangeMethod equal to Restart. On the basis of location information retrieved from the HSS (or by means of a reverse DNS lookup on the ME IP address(1), or any other means TBD), the home CSCF can redirect the ME to another CSCF by means of an MGCIdToTry parameter that describes the CSCF that should be contacted for further service by the ME. In this case the ME shall reissue the ServiceChange command to the new CSCF. In any case, the CSCF that successfully accepts a ME registration, will notify the mobile station's HSS of the association between itself (1) ---------------------------------------------------------------- As noted in paragraph 4, the CSCF will typically reside in the same network of the GGSN. Since IP traffic is routed to the GGSN in order to be tunnelled to the ME, the ME IP address will be an address in the GGSN network. A reverse DNS lookup on the ME IP address will therefore provide the GGSN domain name, e.g. foo.com. The D-CSCF in the GGSN network can be assumed to have URI: D-CSCF(1,2,3).foo.com. A much cleaner solution can make use of SRV DNS records [8]. Ricagni, et al. Informational - Expires September 2000 [Page 7] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 and the newly registered ME (identified by its E.164, IMSI or alphanumeric username). Another possibility would be that of the ME performing itself the reverse DNS lookup (or getting the S-CSCF URI during the attach function, or by other means to be defined), and contacting directly the S-CSCF in the GGSN network. This solution is seen as less flexible than the first one, there are some open issues with respect to authentication and, last but not least, the home domain might lose some kind of control on the ME, therefore it is FFS. ---- please refer to the postscript version for the figures ---- Figure 4 _ PDP Context Activation and MEGACO registration (CSCF linked with GGSN). Referring to Fig. 4 the flows are described. 1) The ME sends an "Activate PDP Context Request" indicating that it is required a MEGACO service. 2) Security function may be executed. 3) SGSN sends a "Create PDP Context Request" to GGSN (selected on subscription information). 4) The GGSN returns to SGSN a "Create PDP Context Response". If the ME requests a dynamic IP address, GGSN assigns to ME an IP address from its pool of available addresses. This address is sent in this message. 5) The ME receives the "Activate PDP Context Accept" and, if necessary, its dynamic IP address. 6) The ME starts the MEGACO registration procedure with the home D- CSCF by means of a ServiceChange Command specifying the "Root" for the TerminationID and ServiceChangeMethod equal to Restart. A list of CSCFs in the home domain is assumed to be stored in the ME USIM or can be dynamically retrieved by means of other mechanisms to be defined: e.g. SLP [5]. The Home CSCF, by means of a query to the HSS (not shown) or through the DNS-based mechanism above descibed, determines the most appropriate CSCF for the ME in its current location, and invites it to repeat the registration procedure with such CSCF. Ricagni, et al. Informational - Expires September 2000 [Page 8] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 7) The S-CSCF locates the ME HSS in the following way: a) The MEGACO mid (media GW ID), contained in the servicechange messge, will be a (maximum) 64 character string composed of two main parts: - An identifier for the ME, that will typically be its E.164 (or IMSI) or an alphanumeric username -A domain name identifying the home domain for the ME, e.g. xxx.com b) The HSS address can be derived from the domain name assuming a URI such as HSS.xxx.com. For redundancy purposes, HSS2.xxx.com, HSS3.xxx.com etc. can also be tried. A much cleaner solution can make use of SRV DNS records [6]. 8) Upon identification of the appropriate HSS, the S-CSCF sends a "Registration Notification" message to HSS with its Address updating user location information. The S-CSCF address is needed for call management. This is a new message not present in any standard. The exact nature of the authentication information to be exchanged, if any is necessary, is FFS. Moreover, with this message S-CSCF keeps HSS informed about ME Address if it has dynamic IP Address. 9) The HSS acknowledges the "Registration Notification" verifying if user is handled by the right network operator. Otherwise it rejects the "Registration Notification" and S-CSCF could not send a RCF message, but a RRJ (Registration Reject) message. The S-CSCF acknowledges the ServiceChange request. 10) The S-CSCF sends a modify command to the physical termination T1 (all MEs are supposed(2) to have a physical termination "T1") in the null context to instruct it to collect digits and detect the off-hook event, the occurrence of which will trigger notification messages 6 Call Management (2)---------------------------------------------------------------- This assumption can be relaxed issuing an AuditCapabilities message before the first command involving the ME's physical termination Ricagni, et al. Informational - Expires September 2000 [Page 9] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 6.1 UMTS Mobile-to-UMTS Mobile Call (PDP Context Activation and MEGACO Registration carried out) The information flows are shown in Fig. 5. The call is established between a UMTS Mobile calling user (ME1) and a UMTS Mobile called user (ME2). Each of these subscribers is roaming outside of his Home Network. It is assumed that the called party has PDP Context and MEGACO Registration already activated, i.e. each user, after the Attach Function, carries out the registration procedures shown in Figs. 3- 4. This is different from GPRS standard where the PDP Context Activation procedure is foreseen only when a ME send or receive data. If the PDP Context is not activated, it is necessary a solicitation of a Network-Requested PDP Context Activation procedure as in GPRS standard (note that GPRS standard allows this procedure only with static IP addresses). In Fig. 5 the four SGSN Connection scenarios are taken into account; the only difference among scenarios is the system nodes location. Afterwards, in the subsequent figures this difference will not be shown. ---- please refer to the postscript version for the figures ---- Figure 5 _ Mobile-to-Mobile (ME2 Registered). 1) ME1 detects an off-hook events, and notifies its S-CSCF1, sending the collected digits or URI. S-CSCF1 verifies the admission (e.g. on bandwidth measurement) for ME1 and it searches for ME2 location: it looks for the HSS Address in the ME2 Home Network, by means of the following procedure: a) In case of a called address in the form of a URI, it strips the host/username part, and skips to step c) b) In case of a called address in the form of an E.164, by looking up an internal table or by querying an external server (not shown), the calling S-CSCF determines the called party home network domain name: e.g. xxx.com c) The HSS address can be derived from the domain name assuming a URI such as HSS.xxx.com. For redundancy purposes, HSS2.xxx.com, HSS3.xxx.com etc. can also be tried. A much cleaner solution can make use of SRV DNS records [6]. Ricagni, et al. Informational - Expires September 2000 [Page 10] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 2) The S-CSCF sends a Send Routing Info (SRI, MAP message) to HSS. 3) The HSS replies to S-CSCF sending a SRI Ack with the S-CSCF2 Address. 4) S-CSCF1 request the creation of a new context, the addition of T1 and of a ephemeral receive only packet termination, indicating a choice of codecs. ME1 acknowlegs the creation of the new context, returns the name of the context (C1), the name of the newly created ephemeral Termination, the port where it accepts traffic, the chosen codecs, and a choice of codecs for the other endpoint 5) S-CSCF1 sends a Initial Address Message to S-CSCF2. The detailed analysis of the additional information elements (with respect to the standard ISUP message) required to support the information exchange is FFS. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP. 6) S-CSCF2 requests ME2 the creation of a new context, the addition of the physical termination T1 and of a send+receive ephemeral termination, indicating a choice of codecs and the data related to the other endpoint (IP1, port1, codecs1 etc.). S-CSCF2 requests the ringing signal to be applied to the (physical) T1 termination. QOS parameters such as the DSCP to apply to outgoing packets or the instruction to send out RSVP PATH messages towards IP1 can be provided at this stage. The phone start ringing. ME2 acknowleges the creation of the new context, returns the name of the context (C1r), the name of the newly created ephemeral termination, the port where it accepts traffic, and the chosen codecs 7) S-CSCF2 sends an Address Complete Message to S-CSCF1. As above mentioned, The detailed analysis of the additional information elements (with respect to the standard ISUP message) required to support the information exchange is FFS. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP 8) S-CSCF1 requests termination T1 to play the ringing tone and forwards to ME1: ME2 IP address (IP2), port and codecs chosen by ME2 9) ME2 notifies an off-hook event, and S-CSCF2 acknowledges the notify message 10) S-CSCF2 sends an Answer Message to S-CSCF1. As above mentioned, The detailed analysis of the additional information elements (with respect to the standard ISUP message) required to support Ricagni, et al. Informational - Expires September 2000 [Page 11] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 the information exchange is FFS. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP 11) S-CSCF1 requests termination T1 to change its state in send+receive and to be notified in case of user hangup. QOS parameters such as the DSCP to apply to outgoing packets or the parameters for the RSVP RESV messages to be sent to IP2 can be provided at this stage. The VOIP communication between the two MEs can now begin. 12) ME1 notifies S-CSCF1that user has hang up, and S-CSCF1 acknowledges 13) S-CSCF1 sends a Release Message to S-CSCF2. The detailed analysis of the additional information elements (with respect to the standard ISUP message) required to support the information exchange is FFS. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP. 14) S-CSCF2 deletes all terminations from the context C1r (and therefore the context itself). Termination T1 is requested to collect digits and to notify the off-hook event (for subsequent communications). All the deleted terminations report traffic statistics 15) S-CSCF2 sends a Release Complete Message to S-CSCF1. As above mentioned, The detailed analysis of the additional information elements (with respect to the standard ISUP message) required to support the information exchange is FFS. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP 16) S-CSCF1 deletes all terminations from the CTX C1 (and therefore the context itself). Termination T1 is requested to collect digits and to notify the off-hook event (for subsequent communications). All the deleted terminations report traffic statistics 6.1.1 Some alternatives in the call management If in the procedure above described is used the SGSN connection scenario D (i.e., the CSCF and the GGSN are in the Visited Network) the Home Network loses all call control. From an operator perspective this could not be the best choice. However, it is possible a Call Signalling always routed through D- CSCF in the Home Network. Fig. 6 shows the variant to call management. Ricagni, et al. Informational - Expires September 2000 [Page 12] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 The SRI message from S-CSCF1 is addressed to D-CSCF (the default CSCF in the called party home domain). The D-CSCF URI in the ME2 Home Network is computed by means of the following procedure: a) In case of a called address in the form of a URI, S-CSCF1 strips the host/username part, and skips to step c) b) In case of a called address in the form of an E.164, by looking up an internal table or by querying an external server (not shown), the calling S-CSCF determines the called party home network domain name: e.g. xxx.com c) The D-CSCF address can be derived from the domain name assuming a URI such as D-CSCF.xxx.com. For redundancy purposes, D-CSCF2.xxx.com, D-CSCF3.xxx.com etc. can also be tried. A much cleaner solution can make use of SRV DNS records [6]. D-CSCF, in turn, queries the HSS and retrieves the S-CSCF2 address, but D-CSCF does not return this information to S-CSCF1. Instead, D- CSCF returns its own address. In this way S-CSCF1 routes all call signalling to ME2 Home Network which forwards them to S-CSCF2. ---- please refer to the postscript version for the figures ---- Figure 6 _ Call Signalling routed through Home Network. 6.2 UMTS Mobile-to PSTN call In this section, information flows for a UMTS Mobile-to-PSTN call are described. The mobile terminal is always a MEGACO terminal. Packetised voice streams are converted to PSTN calls by means of a MGW (MediaGateWay). The MGCF (Media Gateway Control Function) controls the MGW via MEGACO Protocol and it terminates PSTN signalling. The T-SGW is the Transport Signalling GateWay (in 3GPP terminology): it relays ISUP signalling to the MGCF, according to the SIGTRAN architecture [4]. Ricagni, et al. Informational - Expires September 2000 [Page 13] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 The following message sequence chart highlights how an UMTS-to-PSTN call is handled in a very similar way to the previous case (UMTS Mobile-to-UMTS Mobile Call) ---- please refer to the postscript version for the figures ---- Figure 7 _ Mobile-to-PSTN Call Management. 1) ME1 detects an off-hook events, and notifies its S-CSCF1, sending the collected digits. S-CSCF verifies the admission (e.g. on bandwidth measurement) for ME1 and begins the call routing procedure, to select the appropriate MGCF, based on the user- dialled digits. Such selection can be based on a) A TRIP-based call routing database (Telephony Routing over IP) [7] b) A query to a generic internal or external routing database (e.g. the D-CSCF) c) A pre-set list of gateway controllers located in the originating network, that then forward the call on the PSTN d) Any other valid method 2) If the above routing procedure is successful (the dialled number is valid), S-CSCF requests the creation of a new context, the addition of the physical termination T1 and of a ephemeral receive-only packet termination, indicating a choice of codecs. ME acknowledges the creation of the new context, returns the name of the context (C1), the name of the newly created ephemeral Termination, the port where it accepts traffic, the chosen codec(s), and a choice of codecs for the other endpoint 3) S-CSCF sends an Initial Address Message to MGCF. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP. 4) MGCF requests MGW to create a new context, the addition of a physical termination and of a send+receive packet ephemeral termination, indicating a choice of codecs and the data related to the other endpoint (IP1, port1, codecs1 etc.). MGCF requests the ringing signal to be applied to the (physical) termination. QOS parameters such as the DSCP to apply to outgoing packets or the instruction to send out RSVP PATH messages towards IP1 can be provided at this stage. The phone start ringing. MGW acknowledges the creation of the new context, returns the name of the context Ricagni, et al. Informational - Expires September 2000 [Page 14] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 (C1r), the name of the newly created ephemeral termination, the IP (IP2) and port where it accepts traffic, and the chosen codec 5) MGCF forwards the ISUP Initial Address Message to T-SGW. The T- SGW, in turn, forwards the IAM message to the PSTN. 6) The PSTN returns an Address Complete Message to MGCF through T- SGW. 7) MGCF forwards the ACM message to S-CSCF. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP 8) S-CSCF1 requests termination T1 to play the ringing tone and forwards to ME the IP address, port and codecs chosen by MGW 9) The PSTN returns an Answer Message to MGCF through T-SGW. 10) MGCF forwards the Answer Message to S-CSCF. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP 11) S-CSCF1 requests termination T1 to change its state in send+receive and to be notified in case of user hangup. QOS parameters such as the DSCP to apply to outgoing packets or the parameters for the RSVP RESV messages to be sent to IP2 can be provided at this stage. The VOIP communication between ME and MGW can now begin. 12) ME notifies S-CSCF that user has hang up, and S-CSCF acknowledges 13) S-CSCF sends a Release Message to MGCF. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP. 14) MGCF forwards the Release message to the PSTN, through the T-SGW 15) The PSTN returns an Release Complete Message to MGCF through T- SGW 16) MGCF deletes all terminations from the context C1r (and therefore the context itself). All the deleted terminations report traffic statistics 17) MGCF sends a Release Complete Message to S-CSCF. SIP+, Q.1901 (Q.BICC) can be used as an alternative to ISUP 18) S-CSCF requests ME to delete all terminations from the CTX C1 (and therefore the context itself). Termination T1 is requested to collect digits and to notify the off-hook event (for Ricagni, et al. Informational - Expires September 2000 [Page 15] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 subsequent communications). All the deleted terminations report traffic statistics 7 Security Considerations Usage of the IPSEC protocol suite is foreseen. 8 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] 3GPP TR 23.922 v. 1.0.0 (1999-07), Architecture for an All IP Network. [3] Draft EN 301 344 v6.4.0 (1999-08), Digital cellular telecommunication system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 2, (GSM 03.60 version 6.4.0 Release 1997). [4] Framework architecture for Signaling Transport, IETF RFC 2719, October 1999. [5] Service Location Protocol, IETF RFC 2608, June 1999. [6] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [7] J. Rosenberg, H. Salama, M. Squire "Telephony Routing over IP(TRIP)" draft-ietf-iptel-trip-01.txt, work in progress [8] Fernando Cuervo, Bryan Hill, Nancy Greene,Christian Huitema,Abdallah Rayhan, Brian Rosen, John Segers "Megaco Protocol", draft-ietf-megaco-protocol-07.txt, work in progress 9 Author's Addresses Antonella Napolitano CSELT - CENTRO STUDI E LABORATORI TELECOMUNICAZIONI S.p.A. Via G. Reis Romoli, 274 10148 Torino Italy Email: Antonella.Napolitano@cselt.it Giuseppe Ricagni Italtel S.p.A Ricagni, et al. Informational - Expires September 2000 [Page 16] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 Via Reiss Romoli Castelletto di Settimo Milanese Settimo Milanese (MI) Italy Email: Giuseppe.Ricagni@italtel.it Ricagni, et al. Informational - Expires September 2000 [Page 17] UMTS all-IP Mobility Management, Call and session control Procedures March, 2000 Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Ricagni, et al. Informational - Expires September 2000 [Page 18]