Internet Engineering Task Force J. Elwell Internet Draft Siemens J. McMillen Avaya Inc. JF. Rey/O. Rousseau draft-elwell-sipping-qsig2sip-diversion-00.txt Alcatel Expires: December 2003 June 2003 Interworking between SIP and QSIG for call diversion Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026 except that the right to produce derivative works is not granted. 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. Abstract This document specifies call diversion interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be able to establish, modify and terminate sessions involving a participant in the SIP Elwell et alia Expires - December 2003 [Page 1] Interworking between SIP and QSIG June 2003 network and a participant in the QSIG network, taking into account the impact of diversion during call establishment. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. 1 Introduction....................................................3 2 Terminology.....................................................4 3 Definitions.....................................................4 3.1 External definitions..........................................4 3.2 Other definitions.............................................4 3.2.1 Call diversion..............................................4 3.2.2 Call forwarding busy (CFB)..................................5 3.2.3 Call forwarding no reply (CFNR).............................5 3.2.4 Call forwarding unconditional (CFU).........................5 3.2.5 Corporate telecommunication Network (CN)....................5 3.2.6 Entity A....................................................5 3.2.7 Entity B....................................................5 3.2.8 Entity C....................................................5 3.2.9 Gateway.....................................................5 3.2.10 IP network.................................................5 3.2.11 Leg A......................................................6 3.2.12 Leg B......................................................6 3.2.13 Leg C......................................................6 3.2.14 Private Integrated Services Network (PISN).................6 3.2.15 Private Integrated services Network eXchange (PINX)........6 3.2.16 Rerouting entity...........................................6 3.2.17 User A.....................................................6 3.2.18 User B.....................................................6 3.2.19 User C.....................................................6 4 Acronyms........................................................6 5 Background and architecture for SIP-QSIG interworking...........7 6 Call diversion..................................................7 7 Call diversion in QSIG..........................................9 8 Call diversion in SIP..........................................10 9 Diversion interworking.........................................11 9.1 Scenarios for diversion interworking.........................11 9.2 Mapping of numbers and URIs..................................12 9.3 Derivation of QSIG diversion reasons.........................12 9.3.1 Scenario A1................................................13 9.3.2 Scenario B1................................................13 9.3.3 Scenario C2................................................13 9.4 Derivation of SIP response codes (scenarios A2 and C1).......14 9.5 Mapping the QSIG diversion counter...........................14 9.6 Interworking for scenario A1.................................14 9.7 Interworking for scenario A2.................................14 9.8 Interworking for scenario B1.................................14 9.9 Interworking for scenario B2.................................14 Elwell et alia Expires - December 2003 [Page 2] Interworking between SIP and QSIG June 2003 9.10 Interworking for scenario C1................................14 9.11 Interworking for scenario C2................................15 10 Example message sequences.....................................15 10.1 Scenario A1.................................................15 10.1.1 Successful call û history information in 200 response.....15 10.1.2 Successful call û history information in provisional response .................................................................16 10.1.3 Failed call...............................................17 10.2 Scenario A2.................................................18 10.2.1 Successful call û CFU or CFB..............................18 10.2.2 Successful call û CFNR....................................20 10.3 Scenario B1.................................................20 10.3.1 Successful diversion û CFU or CFB.........................20 10.3.2 Successful diversion û CFNR...............................22 10.3.3 Failure û callRerouting.err received......................23 10.3.4 Failure û No answer following CFNR........................24 10.4 Scenario B2.................................................25 10.4.1 Successful diversion......................................25 10.5 Scenario C1.................................................26 10.6 Scenario C2.................................................27 10.7 Scenario A1 followed by B1..................................28 10.8 Scenario A2 followed by scenario B2.........................29 10.9 Scenario C1 followed by scenario A1.........................30 10.10 Scenario C2 followed by scenario A2........................31 10.11 Scenario C1 followed by scenario B1........................32 10.12 Scenario C2 followed by scenario B2........................33 11 Security considerations.......................................34 12 Author's Addresses............................................34 13 Normative References..........................................34 Annex A - Change log.............................................35 1 Introduction This document specifies signalling interworking between "QSIG" and the Session Initiation Protocol (SIP) in support of call diversion within a corporate telecommunication network (CN). "QSIG" is a signalling protocol that operates between Private Integrated Services eXchanges (PINX) within a Private Integrated Services Network (PISN). A PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in ECMA Standards, in particular [2] (call control in support of basic services), [3] (generic functional protocol for the support of supplementary services) and a number of Standards specifying individual supplementary services. Diversion services are specified in [5] and the QSIG signalling protocol in support of these services is specified in [6]. In particular, this signalling protocol signals information about call diversion to the users involved. Elwell et alia Expires - December 2003 [Page 3] Interworking between SIP and QSIG June 2003 SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over IP [10], [11]. Telephone calls are considered as a type of multimedia session where just audio is exchanged. SIP is defined in [1]. An extension to SIP provides history information [8] that can be used to signal information about the retargeting of a request, in particular a call establishment request, as it is routed through a network. This document specifies signalling interworking for call diversion during the establishment of calls between a PISN employing QSIG and a corporate IP network employing SIP. It covers both the impact on SIP of call diversion in the QSIG network and the impact on QSIG of request retargeting in the SIP network. Signalling interworking for call diversion operates on top of signalling interworking for basic calls, which is specified in [9] Call diversion interworking between a PISN employing QSIG and a public IP network employing SIP is outside the scope of this specification. However, the functionality specified in this specification is in principle applicable to such a scenario when deployed in conjunction with other relevant functionality (e.g., number translation, security functions, etc.). This specification is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG and a corporate IP network employing SIP. 2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant SIP implementations. 3 Definitions For the purposes of this specification, the following definitions apply. 3.1 External definitions The definitions in [2] and [1] apply as appropriate. 3.2 Other definitions 3.2.1 Call diversion Elwell et alia Expires - December 2003 [Page 4] Interworking between SIP and QSIG June 2003 The act of retargeting a call during call establishment by changing the user identity that is used as the basis for routing to the destination. 3.2.2 Call forwarding busy (CFB) Call diversion invoked because the targeted user is busy. 3.2.3 Call forwarding no reply (CFNR) Call diversion invoked because the targeted user fails to reply within a certain time. 3.2.4 Call forwarding unconditional (CFU) Call diversion invoked for reasons other than those leading to CFB or CFNR. 3.2.5 Corporate telecommunication Network (CN) Sets of privately-owned or carrier-provided equipment that are located at geographically dispersed locations and are interconnected to provide telecommunication services to a defined group of users. NOTE. A CN can comprise a PISN, a private IP network (intranet) or a combination of the two. NOTE. Also known as enterprise network. 3.2.6 Entity A The entity that provides information about diversion to user A. 3.2.7 Entity B The entity that invokes diversion for a call targeted at user B. 3.2.8 Entity C The entity that provides information about diversion to user C. 3.2.9 Gateway An entity that performs interworking between a PISN using QSIG and an IP network using SIP. 3.2.10 IP network Elwell et alia Expires - December 2003 [Page 5] Interworking between SIP and QSIG June 2003 A network, unless otherwise stated a corporate network, offering connectionless packet-mode services based on the Internet Protocol (IP) as the network layer protocol. 3.2.11 Leg A The call segment between entity A and the rerouting entity for a call that undergoes diversion. 3.2.12 Leg B The call segment between the rerouting entity and entity B for a call that undergoes diversion. 3.2.13 Leg C The call segment between the rerouting entity and entity C for a call that undergoes diversion. 3.2.14 Private Integrated Services Network (PISN) A CN or part of a CN that employs circuit-switched technology. 3.2.15 Private Integrated services Network eXchange (PINX) A PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in accordance with [2]. 3.2.16 Rerouting entity The entity that performs call rerouting on request from entity B and that provides information about diversion to entity A and entity C. 3.2.17 User A The calling user of a call that undergoes diversion. 3.2.18 User B The user on behalf of which call diversion is invoked for an incoming call to that user. 3.2.19 User C The user to which a call is diverted. 4 Acronyms APDU Application Protocol Data Unit Elwell et alia Expires - December 2003 [Page 6] Interworking between SIP and QSIG June 2003 CFB Call forwarding busy CFNR Call forwarding no reply CFU Call forwarding unconditional IP Internet Protocol PINX Private Integrated services Network eXchange PISN Private Integrated Services Network SIP Session Initiation Protocol UA User Agent UAC User Agent Client UAS User Agent Server 5 Background and architecture for SIP-QSIG interworking The background and architecture of [9] applies. In addition, the interworking function in the protocol model handles interworking for call diversion services. This involves interworking between the QSIG call diversion protocol specified in [6] and SIP, including the use of SIP request history information as specified in [8]. 6 Call diversion Call diversion, as specified in QSIG and for the purposes of this document, is the act of retargeting a call during call establishment by changing the user identity that is used as the basis for routing to the destination. This can be viewed as being a change of destination user, although in some cases two identities can belong to the same user, e.g., a home number and office number. The three users involved are known as user A (the calling user A), user B (the called user or diverting user) and user C (the diverted-to user). Reasons for invoking diversion are various and can depend on factors such as the state of the line serving user B, the time of day and the type or identity of user A. It could also be as a result of action by user B(sometimes known as call deflection). A diversion can occur immediately. i.e., without alerting user B, or after a period of alerting without reply. With the exception of call deflection, diversion requirements must be pre-configured into some equipment acting on behalf of user B, e.g, a telephone, a PINX or a SIP proxy. This could be achieved, for example, by rules-based scripting. It is often useful or even important that the users involved in a diverted call (user A and user C) are informed of the diversion. This can be particularly important for automata, e.g., for a call diverted to a voice mail system it might be important to indicate to the system that the call has been diverted from user B. However, privacy considerations can sometimes lead to the suppression of this information. Elwell et alia Expires - December 2003 [Page 7] Interworking between SIP and QSIG June 2003 The general model for a call that undergoes diversion is shown in Figure 1. Entity B is the entity that invokes diversion, based on configuration or, in the case of call deflection, on request from user B. The Rerouting entity performs call rerouting on instruction from Entity B and provides information about the diversion to Entity A and Entity C. Entity A and Entity C handle diversion on behalf of users A and C respectively by providing information about diversion. (1) --------------------------------------> (2) <-------------- +--------+ Leg B | | +-----------|Entity B| | | | +--------+ +---------+ | +--------+ | | Leg A | |--+ |Entity A|-------------|Rerouting| | | | entity |--+ +--------+ +---------+ | +--------+ (4) | Leg C | | <-------------- +-----------|Entity C| | | (3) +--------+ --------------> Figure 1 û Logical model for diversion in a QSIG network From this model it can be seen that there are three call legs: - leg A between Entity A and the Rerouting entity (null if these two entities are collocated); - leg B between Entity B and the Rerouting entity (null if these two entities are collocated); - leg C between Entity C and the Rerouting PINX (null if PINX C and the rerouting PINX are the same). Diversion signalling on leg A provides information about diversion to Entity A, which can use it to provide information to user A. Diversion signalling on leg B instructs the Rerouting entity to carry out rerouting. Diversion signalling on leg C provides information about diversion to Entity C, which can use it to provide information to user C. Figure 1 also illustrates the basic dynamic behaviour: Elwell et alia Expires - December 2003 [Page 8] Interworking between SIP and QSIG June 2003 (1) Call establishment from user A as far as Entity B. (2) Rerouting request from Entity B to Rerouting Entity. (3) Rerouted call establishment from Rerouting Entity to Entity C accompanied by information about the diversion. (4) Information about the diversion from the Rerouting entity to Entity A. Diversions can be chained. In this case the rerouted call from the Rerouting entity reaches another Entity B. The same or a different Rerouting entity then reroutes the call towards the new user C. 7 Call diversion in QSIG Call diversion in QSIG is the act of retargeting a call during call establishment by changing the called party number, which is the user identity used as the basis for routing to the destination. Call diversion in QSIG follows the model described above. Entity A is located in user AÆs PINX (PINX A), Entity B is located in user BÆs PINX (PINX B) and Entity C is located in user CÆs PINX (PINX C). The Rerouting entity is located either at user BÆs PINX (diversion by forward switching) or at user AÆs PINX (diversion by rerouting). Because of potential interactions with other supplementary services, the signalling for which passes transparently through intermediate (Transit) PINXs, the rerouting PINX is constrained to be either PINX B or PINX A. The former case is known as diversion by forward switching, and is analogous to SIP retargeting by a proxy. The latter case is known as diversion by rerouting and is analogous to SIP retargeting by redirection. For the purposes of QSIG, diversions are classified into one of the following types: - call forwarding no reply (CFU)(forwarding as a result of no user reply after alerting user B for a certain time); - call forwarding busy (CFB)(forwarding as a result of user BÆs device being busy); and - call forwarding unconditional (CFU)(forwarding for reasons other than no reply or busy). NOTE. CFU is not necessarily entirely unconditional, since it can depend on other factors, e.g., time of day. In common with other supplementary services, QSIG signalling for diversion is based on [3] and comprises the following remote operations: Elwell et alia Expires - December 2003 [Page 9] Interworking between SIP and QSIG June 2003 - callRerouting - this confirmed operation is applicable to leg B and provides a means for PINX B to request the Rerouting PINX to reroute a call to user C. - cfnrDivertedLegFailed û this unconfirmed operation is applicable to leg B and indicates failure to establish call leg C subsequent to accepting a callRerouting operation. cfnrDivertedLegFailed applies only to CFNR (i.e. to diversions after user B has been alerted) and indicates to PINX B that user B should continue to be alerted. For other types of diversion leg B is cleared down as soon as the callRerouting operation is accepted, without waiting to see if the call towards user C can be established. - divertingLegInformation1 - this unconfirmed operation is applicable to leg A and signals information about the diversion to PINX A, including any privacy requirement of user B to prevent disclosure of diversion information to user A. Note that PINX A can use the information for internal purposes (e.g., call logging) but is trusted not to disclose private information to user A. - divertingLegInformation2 û this unconfirmed operation is applicable to leg C and signals information about the diversion to PINX C. - divertingLegInformation3 û this unconfirmed operation is applicable to legs A and C and signals privacy information from PINX C to PINX A. This privacy information provides the possibility for user C to suppress the disclosure of its identity to user A. PINX A must take into account both the privacy information in divertingLegInformation1 and the privacy information in divertingLegInformation3 before disclosing information to user A. Chained diversions are supported. PINX A receives a divertingLegInformation1 operation for each diversion, but often a divertingLegInformation3 operation only for the final diversion (since this information is not necessarily available until answer). The final PINX C receives a single divertingLegInformation2 operation containing information about the first and last diversions but not intermediate diversions. 8 Call diversion in SIP Call diversion is not specified for SIP. However, SIP does have the concept of retargeting an INVITE request. This occurs at a proxy, instigated either by the proxy itself or on request from a redirect using a 3xx response. Relating this to the model, the Rerouting entity for a SIP diversion is the proxy that retargets the INVITE request. Entity B is either that same proxy or a redirect that issues a 3xx response. A 3xx response therefore has some synergy with a QSIG callRerouting operation. Entity A is the UAC for the INVITE request and Entity C is the UAS of the retargeted-to user. Retargeting involves changing the Request-URI within the INVITE request, this field being the basis for routing the request. Elwell et alia Expires - December 2003 [Page 10] Interworking between SIP and QSIG June 2003 [1] does not provide signalling support for notifying user AÆs UA or user CÆs UA that retargeting has occurred. Additional signalling for this purpose is specified in [8], in accordance with requirements specified in [7]. This allows a retargeting proxy to insert a History-Info header into a request when it is forwarded downstream, i.e. on leg C towards Entity C. Moreover Entity C reflects the received History-Info header back over leg C and leg A towards Entity A. In this way, both Entity A and Entity C receive information about the retarget and can provide this information to their respective users. Chained retargets are supported. Entity A and Entity C receive information about multiple retargets carried out by various proxies along the path taken by the INVITE request. 9 Diversion interworking 9.1 Scenarios for diversion interworking From the descriptions in sections 7 and 8 it can be seen that both diversion in QSIG and retargeting, along with the History-Info header, in SIP can be mapped to the call diversion model described in section 6. Therefore interworking can be described in terms of this model. Interworking can occur on leg A, on leg B or on leg C. In either case, the Rerouting entity can be in either the SIP network or the QSIG network. This leads to 6 interworking scenarios. - Scenario A1: interworking on leg A, call from QSIG to SIP undergoing retargeting in the SIP network. Entity A in QSIG network, Rerouting entity, Entity B and Entity C in SIP network. - Scenario A2: interworking on leg A, call from SIP to QSIG undergoing diversion in the QSIG network. Entity A in SIP network, Rerouting entity, Entity B and Entity C in QSIG network. - Scenario B1: interworking on leg B, call from QSIG to SIP where QSIG network performs rerouting in response to a redirection request from the SIP network. Entity A, Entity C and Rerouting entity in QSIG network, Entity B in SIP network. - Scenario B2: interworking on leg B, call from SIP to QSIG where SIP network performs retargeting in response to a rerouting request from the QSIG network. Entity A, Entity C and Rerouting entity in SIP network, Entity B in QSIG network. Elwell et alia Expires - December 2003 [Page 11] Interworking between SIP and QSIG June 2003 - Scenario C1: interworking on leg C, call diverted by QSIG network to destination in SIP network. Entity A, Entity B and Rerouting entity in QSIG network, Entity C in SIP network. - Scenario C2: interworking on leg C, call retargeted by SIP network to destination in QSIG network. Entity A, Entity B and Rerouting entity in SIP network, Entity C in QSIG network. Call diversion interworking can occur more than once for a given call (chained diversions). The different instances of interworking can be on the same leg (where a leg passes through two or more gateways) or on different legs. For example, Entity A could be in a QSIG network, Rerouting Entity and Entity B could be in a SIP network, and Entity C could be in a QSIG network. In this case interworking occurs on leg A (scenario A1) and on leg C (scenario C2). Each instance of interworking conforms to one of the 6 scenarios listed above. No new interworking scenario is introduced as a result. Chained diversions can introduce mixed scenarios whereby a particular gateway plays the role of one scenario for the one diversion and either the same scenario or a different scenario for the next diversion. For example, consider a gateway performing a scenario C1 role as the result of diversion in the QSIG network (Rerouting entity in the QSIG network) to a diverted-to user in the SIP network. The gateway can also perform the role of scenario A1 if a further diversion occurs in the SIP network (Rerouting Entity in the SIP network). 9.2 Mapping of numbers and URIs Most of the examples shown in section 10 involve mapping of identifiers, e.g., the identifier representing the diverted to user or the identifier representing the diverting user. In QSIG users are identified by numbers. In SIP users are identified by URIs. Mapping of identifiers is described in detail in [12]. In some cases it may not be possible for a gateway to map a SIP URI to a QSIG number or vice versa. If it is not possible to derive an identifier that is essential for generating a signalling element relating to diversion, unless otherwise stated the call should be allowed to continue without that signalling element. 9.3 Derivation of QSIG diversion reasons The History-Info header contains one or more retargeted-to-URIs, each containing a Reason header as an optional parameter. The Reason header contains the reason for retargeting. Some of the scenarios require the derivation of a QSIG diversionReason element (indicating CFU, CFB or CFNR), and the Reason header, where available, is the Elwell et alia Expires - December 2003 [Page 12] Interworking between SIP and QSIG June 2003 most suitable source of information for this. Although the Reason header contains provision for reason codes other than SIP response codes, normally it will contain a SIP response code, particularly if it has originated at a native SIP entity as opposed to a gateway. There needs to be a default diversionReason to cater for cases where the Reason header is omitted or where it contains a reason that does not readily suggest a particular diversionReason. The particular mapping will depend on the scenario concerned. 9.3.1 Scenario A1 In QSIG, diversionReason CFNR is theoretically meaningful only after ALERTING. Also for the first diversion after ALERTING theoretically the only meaningful diversionReason is CFNR. However, in practice violating these rules will probably not cause problems at downstream PINXs. SIP response codes do not readily distinguish between the three diversionReason values, and therefore taking account of whether ALERTING has been sent is perhaps beneficial in selecting a more meaningful diversionReason value. The following rules are proposed: 1. If the reason code in the Reason header is 486 (Busy Here) or 600 (Busy Everywhere), map to CFB. 2. Otherwise if ALERTING has previously been sent, map to CFNR. 3. Otherwise map to CFU. 9.3.2 Scenario B1 History-Info is not normally contained in the 3xx response (except to denote previous retargets), and therefore there is no Reason header and the only source of information is the 3xx response code. The various 3xx response codes do not readily map to diversion reasons. The following rules are proposed: 1. If ALERTING has previously been sent, map to CFNR. 2. Otherwise map to CFU. 9.3.3 Scenario C2 In this scenario it is not possible to determine whether alerting was achieved prior to diversion. The following rules are proposed: Elwell et alia Expires - December 2003 [Page 13] Interworking between SIP and QSIG June 2003 1. If the reason code in the Reason header is 486 (Busy Here) or 600 (Busy Everywhere), map to CFB. 2. If the reason code in the Reason header is 480 (Temporarily Unavailable), map to CFNR. 3. Otherwise map to CFU. 9.4 Derivation of SIP response codes (scenarios A2 and C1) The diversionReason in divertingLegInformation1 and divertingLegInformation2 should ideally be mapped to a corresponding reason in the History-Info header, i.e., to the Reason header parameter of the retargeted-to-URI. Although there is provision for the Reason header to contain reasons other than SIP response codes, other reasons are less likely to be meaningful to the majority of implementations. Therefore it would be better to map diversionReason to appropriate SIP response codes. The following is proposed. 1. Map CFU to 302 (Moved Temporarily). 2. Map CFB to 486 (Busy Here). 3. Map CFNR to 480 (Temporarily Unavailable). 9.5 Mapping the QSIG diversion counter EDITOR'S NOTE. To be added. 9.6 Interworking for scenario A1 EDITOR'S NOTE. To be added. 9.7 Interworking for scenario A2 EDITOR'S NOTE. To be added. 9.8 Interworking for scenario B1 EDITOR'S NOTE. To be added. 9.9 Interworking for scenario B2 EDITOR'S NOTE. To be added. 9.10 Interworking for scenario C1 EDITOR'S NOTE. To be added. Elwell et alia Expires - December 2003 [Page 14] Interworking between SIP and QSIG June 2003 9.11 Interworking for scenario C2 EDITOR'S NOTE. To be added. 10 Example message sequences In the interests of keeping the diagrams simple, ACK and PRACK are not shown. The following notation is used for diversion information within QSIG messages: - xxx.inv û invoke application protocol data unit (APDU) of operation xxx. - xxx.res û return result APDU of operation xxx. - xxx.err û return error APDU of operation xxx. 10.1 Scenario A1 Call from QSIG to SIP undergoes diversion in SIP network. 10.1.1 Successful call û history information in 200 response +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || --------------------------->|| || QSIG CALL PROCEEDING || INVITE req <---------------------------|| Supported: HistInfo ||---------------------------> || || 100 ||<--------------------------- || || 180 QSIG ALERTING ||<--------------------------- <---------------------------|| || 200 || History-Info QSIG CONNECT ||<--------------------------- divertingLegInformation1.inv|| divertingLegInformation3.inv|| <---------------------------|| Elwell et alia Expires - December 2003 [Page 15] Interworking between SIP and QSIG June 2003 || Figure 2 û Example of scenario A1 û successful call û history information in 200 response NOTE 1. Normally the first targeted-to URI in the History-Info header will be the original targeted-to URI (the Request-URI in the INVITE request sent by the gateway), and therefore this URI can be discarded. The second targeted-to URI should be used to derive the number in divertingLegInformation1.inv. NOTE 2. If there is more than one targeted-to URI (in addition to the original targeted-to URI) it would be possible to include more than one divertingLegInformation1 invoke in the CONNECT message. NOTE 3. The diversionReason in divertingLegInformation1 needs to be derived from the History-Info header. See section 9.3. 10.1.2 Successful call û history information in provisional response +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || --------------------------->|| || QSIG CALL PROCEEDING || INVITE req <---------------------------|| Supported: HistInfo ||---------------------------> || || 100 ||<--------------------------- || || 180 || History-Info QSIG ALERTING ||<--------------------------- divertingLegInformation1.inv|| divertingLegInformation3.inv|| <---------------------------|| || 200 || History-Info QSIG CONNECT ||<--------------------------- <---------------------------|| || Figure 3 û Example of scenario A1 û successful call û history information in provisional response Elwell et alia Expires - December 2003 [Page 16] Interworking between SIP and QSIG June 2003 NOTE 1. This shows History-Info arriving in a 180 response. An alternative would be receipt of History-Info in a 183 response, in which case the divertingLegInformation1.inv would be sent in the PROGRESS message (if a PROGRESS message is to be sent) or in a FACILITY message. NOTE 2. Normally the first targeted-to URI in the History-Info header will be the original targeted-to URI (the Request-URI in the INVITE request sent by the gateway), and therefore this URI can be discarded. The second targeted-to URI should be used to derive the number in divertingLegInformation1.inv. NOTE 3. If there is more than one targeted-to URI (in addition to the original targeted-to URI) it would be possible to include more than one divertingLegInformation1 invoke in the ALERTING (or PROGRESS or FACILITY) message. NOTE 4. The diversionReason in divertingLegInformation1 needs to be derived from the History-Info header. See section 9.3. NOTE 5. The divertingLegInformation3.inv is shown as being sent in the same message as the divertingLegInfo1.inv. This is because SIP has no means of indicating later that the retargeted-to URI in the History-Info header is not to be disclosed to the calling user. In a QSIG environment the divertingLegInformation3.inv cannot be sent until it is clear that the diverted-to user does not require privacy, and therefore it is often deferred until the CONNECT message. A gateway could choose to defer until the CONNECT message, but there is no need. NOTE 6. If further provisional responses are received with extended information in the History-Info header, the additional targeted-to URIs can be used to generate further divertingLegInformation1 and divertingLegInformation3 invokes. NOTE 7. Another History-Info header will be present in the 200 OK response. Unless this contains additional targeted-to URIs, no divertingLegInformation1.inv should be included in the CONNECT message. 10.1.3 Failed call +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || Elwell et alia Expires - December 2003 [Page 17] Interworking between SIP and QSIG June 2003 --------------------------->|| || QSIG CALL PROCEEDING || INVITE req <---------------------------|| Supported: HistInfo ||---------------------------> || || 100 ||<--------------------------- || || 4xx/5xx/6xx || History-Info QSIG FACILITY ||<--------------------------- divertingLegInformation1.inv|| divertingLegInformation3.inv|| <---------------------------|| || QSIG DISCONNECT || <---------------------------|| || QSIG RELEASE || --------------------------->|| || QSIG RELEASE COMPLETE || <---------------------------|| || Figure 4 û Example of scenario A1 û failed call 10.2 Scenario A2 Call from SIP to QSIG undergoes diversion in QSIG network. 10.2.1 Successful call û CFU or CFB +--------------+ IP network | Interworking | PISN | unit | +--------------+ || INVITE req || Supported: HistInfo || --------------------------->|| || QSIG SETUP 100 ||---------------------------> <---------------------------|| || QSIG CALL PROCEEDING ||<--------------------------- || || QSIG FACILITY Elwell et alia Expires - December 2003 [Page 18] Interworking between SIP and QSIG June 2003 ||divertingLegInformation1.inv ||<--------------------------- || || QSIG ALERTING 180 ||<--------------------------- <---------------------------|| || QSIG CONNECT 200 ||divertingLegInformation3.inv History-Info ||<--------------------------- <---------------------------|| || Figure 5 û Example of scenario A2 (CFU or CFB) NOTE 1. In the History-Info header, the first targeted-to URI should be the Request-URI in the received INVITE request and the second targeted-to URI should be derived from the number in the divertingLegInformation1.inv. If more than one divertingLegInformation1.inv have been received in the same QSIG message or previous QSIG messages, additional targeted-to URIs can be derived. NOTE 2. History-Info should be omitted if Supported: HistInfo is not present in the INVITE request. NOTE 3. If information in the divertingLegInformation1 or divertingLegInformation3 invoke indicates that privacy is required for user CÆs number, then this will limit information that can be provided in the History-Info header. EDITORÆS NOTE. Progression of the History-Info I-D will need to be monitored carefully to see how privacy is handled and how it interacts with the privacy, P-Asserted-Identity and long-term identity specifications. At present it looks as if it will be necessary to suppress any History-Info header field that discloses the identity of C in this situation and use existing rules concerning P-Asserted-Identity. NOTE 4. Until the divertingLegInformation3.inv arrives, the gateway does not know whether privacy restrictions apply, and therefore History-Info cannot be sent earlier. If divertingLegInformation3.inv arrives before the CONNECT, History-Info may be sent in a provisional response (e.g., in 180 or 181). NOTE 5.If after sending a History-Info header in a provisional response, a further divertingLegInformation1.inv arrives, a further History-Info header can be sent subject to the rules above. This header should contain all targeted-to-URIs to date, including that derived from the latest divertingLegInformation1.inv. Elwell et alia Expires - December 2003 [Page 19] Interworking between SIP and QSIG June 2003 NOTE 6. Even if History-Info has been sent in a provisional response and no further divertingLegInformation1.inv has been received, the 200 response should contain a History-Info header containing all retargeted-to URIs. NOTE 7. The diversionReason needs to be reflected in the History-Info header. See section 9.4 10.2.2 Successful call û CFNR +--------------+ IP network | Interworking | PISN | unit | +--------------+ || INVITE req || Supported: HistInfo || --------------------------->|| || QSIG SETUP 100 ||---------------------------> <---------------------------|| || QSIG CALL PROCEEDING ||<--------------------------- || || QSIG ALERTING 180 ||<--------------------------- <---------------------------|| || || QSIG FACILITY ||divertingLegInformation1.inv ||<--------------------------- || QSIG CONNECT 200 ||divertingLegInformation3.inv History-Info ||<--------------------------- <---------------------------|| || Figure 6 û Example of scenario A2 (CFNR) 10.3 Scenario B1 Call from QSIG to SIP redirected back to QSIG network. 10.3.1 Successful diversion û CFU or CFB +--------------+ PISN | Interworking | IP network | unit | Elwell et alia Expires - December 2003 [Page 20] Interworking between SIP and QSIG June 2003 +--------------+ || QSIG SETUP || --------------------------->|| || QSIG CALL PROCEEDING || INVITE req <---------------------------|| Supported: HistInfo ||---------------------------> || || 100 ||<--------------------------- || || 3xx QSIG FACILITY ||<--------------------------- callRerouting.inv || <---------------------------|| || QSIG FACILITY || callRerouting.res || --------------------------->|| || QSIG DISCONNECT || --------------------------->|| || QSIG RELEASE || <---------------------------|| || QSIG RELEASE COMPLETE || --------------------------->|| || Figure 7 û Example of scenario B1 (call forwarding unconditional or call forwarding busy) NOTE 1. This scenario applies only if the gateway does not act as a rerouting proxy and issue a further INVITE request to the contact URI(s) supplied. The decision to do this might be based on the value of the contact URI(s). If the gateway acts as a rerouting proxy, scenario A1 applies to the sending of diversion information towards the calling user. NOTE 2. For derivation of the reroutingReason in callRerouting.inv, see section 9.3. NOTE 3. The number in callRerouting.inv should be derived from the Contact address header in the 3xx response. If there is more than one contact address, one must be selected, e.g., the first one that can be mapped to a number. Elwell et alia Expires - December 2003 [Page 21] Interworking between SIP and QSIG June 2003 NOTE 4. If the reroutingReason in callRerouting invoke indicates CFNR, the QSIG DISCONNECT will not arrive until the diverted call has been successfully established (alerting). The gateway should not attempt to accelerate the clearing of the leg because that will cause the QSIG rerouting PINX to clear the whole call. NOTE 5. The subscriptionOption in the callRerouting.inv should indicate no restriction, which means that user B has not requested any restriction on providing diversion information to user A. If privacy of this nature is required, SIP redirection is an inappropriate mechanism. 10.3.2 Successful diversion û CFNR +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || --------------------------->|| || QSIG CALL PROCEEDING || INVITE req <---------------------------|| Supported: HistInfo ||---------------------------> || || 100 ||<--------------------------- || || 180 QSIG ALERTING ||<--------------------------- <---------------------------|| || 3xx || History-Info QSIG FACILITY ||<--------------------------- callRerouting.inv || <---------------------------|| || QSIG FACILITY || callRerouting.res || --------------------------->|| || QSIG DISCONNECT || --------------------------->|| || QSIG RELEASE || <---------------------------|| || QSIG RELEASE COMPLETE || Elwell et alia Expires - December 2003 [Page 22] Interworking between SIP and QSIG June 2003 --------------------------->|| || Figure 8 û Example of scenario B1 (call forwarding no reply) NOTE 1. For derivation of the diversionReason in callRerouting.inv, see section 9.3. NOTE 2. Because this is CFNR, the QSIG DISCONNECT will not arrive until the diverted call has been successfully established (alerting). The gateway should not attempt to accelerate the clearing of the leg because that will cause the QSIG rerouting PINX to clear the whole call. NOTE 3. The subscriptionOption in the callRerouting.inv should indicate no restriction. 10.3.3 Failure û callRerouting.err received +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || --------------------------->|| || QSIG CALL PROCEEDING || INVITE req <---------------------------|| Supported: HistInfo ||---------------------------> || || 100 ||<--------------------------- || || 3xx QSIG FACILITY ||<--------------------------- callRerouting.inv || <---------------------------|| || QSIG FACILITY || callRerouting.err || --------------------------->|| || QSIG DISCONNECT || <---------------------------|| || QSIG RELEASE || --------------------------->|| || Elwell et alia Expires - December 2003 [Page 23] Interworking between SIP and QSIG June 2003 QSIG RELEASE COMPLETE || <---------------------------|| || Figure 9 û Example of scenario B1 (call forwarding unconditional or call forwarding busy) NOTE 1. If callRerouting.err is received, the gateway may attempt to take over the functions of the QSIG rerouting PINX. Otherwise it should initiate clearing as shown. 10.3.4 Failure û No answer following CFNR +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || --------------------------->|| || QSIG CALL PROCEEDING || INVITE req <---------------------------|| Supported: HistInfo ||---------------------------> || || 100 ||<--------------------------- || || 180 QSIG ALERTING ||<--------------------------- <---------------------------|| || 3xx || History-Info QSIG FACILITY ||<--------------------------- callRerouting.inv || <---------------------------|| || QSIG FACILITY || callRerouting.res || --------------------------->|| || QSIG FACILITY || cfnrDivertedLegFailed.inv || --------------------------->|| || QSIG DISCONNECT || <---------------------------|| || QSIG RELEASE || Elwell et alia Expires - December 2003 [Page 24] Interworking between SIP and QSIG June 2003 --------------------------->|| || QSIG RELEASE COMPLETE || <---------------------------|| || Figure 10 û Example of scenario B1 (call forwarding no reply followed by no answer) NOTE 1. Because the reroutingReason in callRerouting invoke indicates CFNR, a cfnrDivertedLegFailed invoke will arrive if diversion fails. The QSIG expectation is that alerting will continue at B, but SIP does not support this. Therefore the gateway will need to respond with a QSIG DISCONNECT. 10.4 Scenario B2 Call from SIP to QSIG redirected back to SIP network. 10.4.1 Successful diversion +--------------+ IP Network | Interworking | PISN | unit | +--------------+ INVITE req || Supported: HistInfo || -------------------------->|| || 100 || <---------------------------|| QSIG SETUP ||---------------------------> || || QSIG CALL PROCEEDING ||<--------------------------- || || QSIG ALERTING 180 ||<--------------------------- <---------------------------|| || QSIG FACILITY || callRerouting.inv 302 (Moved Temporarily)||<--------------------------- <---------------------------|| || QSIG FACILITY || callRerouting.res ||---------------------------> || || QSIG DISCONNECT ||---------------------------> || Elwell et alia Expires - December 2003 [Page 25] Interworking between SIP and QSIG June 2003 || QSIG RELEASE ||<--------------------------- || || QSIG RELEASE COMPLETE ||---------------------------> || Figure 11 û Example of scenario B2 (call forwarding no reply) NOTE 1. This scenario applies only if the gateway does not act as the rerouting PINX. This could be determined by configuration or on a dynamic basis (e.g., depending on the value of calledAddress). If the subscriptionOption in the callRerouting.inv indicates that presentation of the diverted-to number to the calling user is restricted, the gateway should act as the rerouting PINX. If the gateway acts as the rerouting PINX, scenario A2 applies to the sending of SIP history information towards the calling user. NOTE 2. 302 (Moved Temporarily) seems to be the nearest 3xx match, regardless of diversionReason. NOTE 3. There appears to be no requirement to include History-Info in the 302 response. NOTE 4. The Contact header in the 302 response should be derived from the number in the callRerouting.inv. NOTE 5. This diagram illustrates CFNR, since callRerouting invoke arrives after ALERTING. For CFNR, the rerouting PINX should wait to see if diversion is successful, so that the call can continue to alert B if not. There is no capability in SIP to indicate success or failure of a 3xx response, and therefore the call to B has to be cleared immediately (as for CFU and CFB). 10.5 Scenario C1 Call diverted in QSIG network to SIP network. +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || divertingLegInformation2.inv|| --------------------------->|| || INVITE req QSIG CALL PROCEEDING || Supported: HistInfo <---------------------------|| History-Info Elwell et alia Expires - December 2003 [Page 26] Interworking between SIP and QSIG June 2003 ||---------------------------> || || 100 ||<--------------------------- || || 180 QSIG ALERTING ||<--------------------------- <---------------------------|| || 200 || History-Info QSIG CONNECT ||<--------------------------- divertingLegInformation3.inv|| <---------------------------|| || Figure 12 û Example of scenario C1 NOTE 1. If originalCalledNr and originalDiversionReason are absent, two targeted-to URIs should be included in the History-Info header in the INVITE request. The first is derived from the divertingNr element. The second is derived from the diversionReason element and the Request-URI. See section 9.4 for deriving SIP response codes for inclusion in targeted-to URIs. NOTE 2. If originalCalledNr and originalDiversionReason are present, three targeted-to URIs should be included in the History-Info header in the INVITE request. The first is derived from the originalCalledNr element. The second is derived from the originalDiversionReason element and the divertingNr element. The last is derived from the diversionReason element and the Request-URI. NOTE 3. Rules need to be established for setting the presentationAllowedIndicator in divertingLegInformation3 invoke. It might depend on the presence of History-Info, P-Asserted-Identity and/or Privacy headers in the 200 response or provisional responses. 10.6 Scenario C2 Call diverted in SIP network to QSIG network. +--------------+ IP Network | Interworking | PISN | unit | +--------------+ INVITE req || Supported: HistInfo || History-Info || -------------------------->|| || Elwell et alia Expires - December 2003 [Page 27] Interworking between SIP and QSIG June 2003 100 || QSIG SETUP <---------------------------|| divertingLegInformation2.inv ||---------------------------> || || QSIG CALL PROCEEDING ||<--------------------------- || || QSIG ALERTING 180 ||<--------------------------- <---------------------------|| || QSIG CONNECT 200 || divertingLegInformation3.inv History-Info ||<--------------------------- <---------------------------|| || Figure 13 û Example of scenario C2 NOTE 1. divertingNr and diversionReason are derived from the penultimate and last targeted-to-uri respectively in the History-Info header. See section 9.3 for deriving diversionReason. NOTE 2. originalCalledNr and originalDiversionReason are derived from first and second targeted-to URI respectively in the History-Info header if there are more than two present. Otherwise these elements are omitted. NOTE 3. The History-Info header may be sent earlier in a provisional response (e.g, in 180 or 183). However, it must also be included in the 200 response. NOTE 4. Inclusion of History-Info in a response will depend on privacy considerations, including presentationAllowed indicator in divertingLegInformation3 invoke. 10.7 Scenario A1 followed by B1 +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || --------------------------->|| || QSIG CALL PROCEEDING || INVITE req <---------------------------|| Supported: HistInfo ||---------------------------> || Elwell et alia Expires - December 2003 [Page 28] Interworking between SIP and QSIG June 2003 || 100 ||<--------------------------- || || 183 || History-Info QSIG PROGRESS ||<--------------------------- <---------------------------|| || QSIG FACILITY || divertingLegInformation1.inv|| <---------------------------|| || 3xx QSIG FACILITY || History-Info callRerouting.inv ||<--------------------------- <---------------------------|| || QSIG FACILITY || callRerouting.res || --------------------------->|| || QSIG DISCONNECT || --------------------------->|| || QSIG RELEASE || <---------------------------|| || QSIG RELEASE COMPLETE || --------------------------->|| || Figure 14 û Example of scenario A1 followed by B1 NOTE 1. The sending of PROGRESS on receipt of a SIP 183 response is dependent on the conditions specified in [9]. NOTE 2. The History-Info in the 3xx response reflects previous retargets, not any retarget suggested by the 3xx response. 10.8 Scenario A2 followed by scenario B2 +--------------+ IP Network | Interworking | PISN | unit | +--------------+ INVITE req || Supported: HistInfo || -------------------------->|| || 100 || Elwell et alia Expires - December 2003 [Page 29] Interworking between SIP and QSIG June 2003 <---------------------------|| QSIG SETUP ||---------------------------> || || QSIG CALL PROCEEDING ||<--------------------------- || || QSIG FACILITY ||divertingLegInformation1.inv ||<--------------------------- || || QSIG FACILITY || callRerouting.inv 302 (Moved Temporarily)||<--------------------------- <---------------------------|| || QSIG FACILITY || callRerouting.res ||---------------------------> || || QSIG DISCONNECT ||---------------------------> || || QSIG RELEASE ||<--------------------------- || || QSIG RELEASE COMPLETE ||---------------------------> || Figure 15 û Example of scenario A2 followed by B2 NOTE. No History-Info is sent back because no divertingLegInformation3.inv has been received and therefore the privacy situation is uncertain. 10.9 Scenario C1 followed by scenario A1 +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || divertingLegInformation2.inv|| --------------------------->|| || INVITE req QSIG CALL PROCEEDING || Supported: HistInfo <---------------------------|| History-Info ||---------------------------> || Elwell et alia Expires - December 2003 [Page 30] Interworking between SIP and QSIG June 2003 || 100 ||<--------------------------- || || 180 QSIG ALERTING ||<--------------------------- <---------------------------|| || QSIG CONNECT || 200 divertingLegInformation1.inv|| History-Info divertingLegInformation3.inv||<--------------------------- <---------------------------|| || Figure 16 û Example of scenario C1 followed by A1 NOTE 1. This is similar to scenario C1 alone, except that scenario A1 applies for mapping History-Info in the 200 response (or a provisional response) to information in the divertingLegInformation1 invoke. Care should be taken only to map information relating to diversions in the IP network, not information derived from divertingLegInformation2 invoke. 10.10 Scenario C2 followed by scenario A2 +--------------+ IP Network | Interworking | PISN | unit | +--------------+ INVITE req || Supported: HistInfo || History-Info || -------------------------->|| || 100 || QSIG SETUP <---------------------------||divertingLegInformation2.inv ||---------------------------> || || QSIG CALL PROCEEDING ||<--------------------------- || || QSIG FACILITY ||divertingLegInformation1.inv ||<--------------------------- || || QSIG ALERTING 180 ||<--------------------------- <---------------------------|| || QSIG CONNECT 200 ||divertingLegInformation3.inv Elwell et alia Expires - December 2003 [Page 31] Interworking between SIP and QSIG June 2003 History-Info ||<--------------------------- <---------------------------|| || Figure 17 û Example of scenario C2 followed by A2 NOTE 1. The History-Info header in the 200 response should reflect both information from the History-Info header received in the INVITE request and information derived from the divertingLegInformation1.inv. However, if information in the divertingLegInformation1 or divertingLegInformation3 invoke indicates that privacy is required for user CÆs number, then this will limit information that can be provided in the History-Info header. 10.11 Scenario C1 followed by scenario B1 +--------------+ PISN | Interworking | IP network | unit | +--------------+ || QSIG SETUP || divertingLegInformation2.inv|| --------------------------->|| || INVITE req QSIG CALL PROCEEDING || Supported: HistInfo <---------------------------|| History-Info ||---------------------------> || || 100 ||<--------------------------- || || 3xx QSIG FACILITY || History-Info callRerouting.inv ||<--------------------------- <---------------------------|| || QSIG FACILITY || callRerouting.res || --------------------------->|| || QSIG DISCONNECT || --------------------------->|| || QSIG RELEASE || <----------------------------|| || QSIG RELEASE COMPLETE || --------------------------->|| Elwell et alia Expires - December 2003 [Page 32] Interworking between SIP and QSIG June 2003 || Figure 18 û Example of scenario C1 followed by B1 10.12 Scenario C2 followed by scenario B2 +--------------+ IP Network | Interworking | PISN | unit | +--------------+ INVITE req || Supported: HistInfo || History-Info || -------------------------->|| || 100 || QSIG SETUP <---------------------------||divertingLegInformation2.inv ||---------------------------> || || QSIG CALL PROCEEDING ||<--------------------------- || || QSIG ALERTING 180 ||<--------------------------- <---------------------------|| || QSIG FACILITY 302 (Moved Temporarily) || callRerouting.inv History-Info ||<--------------------------- <---------------------------|| || QSIG FACILITY || callRerouting.res ||---------------------------> || || QSIG DISCONNECT ||---------------------------> || || QSIG RELEASE ||<--------------------------- || || QSIG RELEASE COMPLETE ||---------------------------> || Figure 19 û Example of scenario C2 followed by B2 NOTE 1. The History-Info in the 302 response reflects that received in the INVITE request. Elwell et alia Expires - December 2003 [Page 33] Interworking between SIP and QSIG June 2003 11 Security considerations EDITOR'S NOTE. To be added 12 Author's Addresses John Elwell Siemens Communications Technology Drive Beeston Nottingham, UK, NG9 1LA email: john.elwell@siemens.com Joanne McMillen Avaya Inc. 1300 W. 120th Ave. Westminster, CO 80234-2726 email: joanne@avaya.com Olivier Rousseau Alcatel Business Systems 32,Avenue Kleber 92700 Colombes France email: olivier.rousseau@col.bsf.alcatel.fr Jean-Francois Rey Alcatel Business Systems 8,Rue de Kervezennec, BP 82 802 29228 Brest Cedex 2 France email: jean-francois.rey@bst.bsf.alcatel.fr 13 Normative References [1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261. [2] International Standard ISO/IEC 11572 "Private Integrated Services Network - Circuit-mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol" (also published by ECMA as Standard ECMA-143) [3] International Standard ISO/IEC 11582 "Private Integrated Services Network - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol" (also published by ECMA as Standard ECMA-165) Elwell et alia Expires - December 2003 [Page 34] Interworking between SIP and QSIG June 2003 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] International Standard ISO/IEC 13872 "Private Integrated Services Network û Specification, Functional Model and Information Flows û Call Diversion Supplementary Services" (also published by ECMA as Standard ECMA-173) [6] International Standard ISO/IEC 13873 "Private Integrated Services Network û Inter-Exchange Signalling Protocol û Call Diversion Supplementary Services" (also published by ECMA as Standard ECMA-174) [7] M. Barnes, M. Watson, C. Jennings, J. Peterson, "SIP Generic Request History Information - Requirements", draft-ietf-sipping-req- history-02 (work in progress) [8] M. Barnes, M. Watson, C. Jennings, "An Extension to the Session Initiation Protocol for Request History Information", draft-barnes- sipping-history-info-02 (work in progress) [9] F. Derks, J. Elwell, P. Mourot, O. Rousseau, "Interworking between SIP and QSIG", draft-ietf-sipping-qsig2sip-02 [10] J. Postel, "Internet Protocol", RFC 791. [11] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)", RFC 2460. [12] J. Elwell, "User Identification in a SIP/QSIG Environment", draft-elwell-sipping-identity-interworking-00 (work in progress) Annex A (temporary) - Change log Elwell et alia Expires - December 2003 [Page 35]