Network Working Group P. Kotar Internet-Draft Alcatel Expires: September 2003 March 24, 2003 Interworking between Digital Subscriber Signalling System No. one (DSS1) and Session Initiation Protocol (SIP) for basic call; draft-kotar-sipping-dss1-sip-iw-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on September 30, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies the interworking between the Digital Subscriber Signalling System No.one (DSS1) as specified in [1] and the Session Initiation Protocol (SIP) as specified in [2]. SIP is an Internet application-layer control protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. DSS1 is a signalling protocol for establishing, modifying and terminating circuit-switched calls, in particular telephone calls, within Public Integrated Services Digital Networks (ISDN)and between the Public network and Private Networks. DSS1 is specified in a number of ETSI Standards and published also as ITU-T standards. The interworking SHALL be described from DSS1 viewpoint for the basic call procedures. The interworking between the above signalling protocols occurs in a Media Gateway Controller (MGC), also called Softswitch which contains the protocol functionality for the ISDN subscribers and the SIP protocol functionality. In case of contradictions between the mapping described in the present document and the requirements specified in the corresponding DSS1 standards and SIP RFC , the procedures in the DSS1 standards and SIP RFC applies. Kotar Expires September 30, 2003 [Page 1] Internet-Draft DSS1-SIP Interworking March 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions.... . . . . . . . . . . . . . . . . . . . . . . 4 4. Acronyms. . . . . . . . .. . . . . . . . . . . . . . . . . . . 4 5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 Interworking of DSS1 and SIP for basic call procedure. . . . . 7 7.1 General requirements. . . . . . . . . . . . . . . . . . . . . 7 7.2 Incoming DSS1 call. . . . . . . . . . . . . . . . . . . . . . . 9 7.2.1 Call establishment using en-bloc sending . . . . . . . . . . 9 7.2.1.1 Exceptional procedure. . . . . . . . . . . . . . . . . . . 10 7.2.1.2 Receipt of a SIP 100 (Trying) response . . . . . . . . . . 10 7.2.1.3 Receipt of a SIP 18x provisional response. . . . . . . . . 10 7.2.1.4 Receipt of a SIP 2xx response . . . . . . . . . . . . . . 11 7.2.1.5 Receipt of SIP 3xx response . . . . . . . . . . . . . . . 11 7.2.2 Call estblishment using overlap sending. . . . . . . . . . . 12 7.2.2.1 Enbloc sending in SIP networks . . . . . . . . . . . . . . 12 7.2.2.1.1 Receipt of a DSS1 SETUP message. . . . . . . . . . . . . 12 7.2.2.1.2 Receipt of a DSS1 INFORMATION messages . . . . . . . . . 12 7.2.2.1.3 Receipt of SIP responses . . . . . . . . . . . . . . . . 13 7.2.2.2 Overlap sending in SIP network . . . . . . . . . . . . . . 13 7.2.2.2.1 Receipt of a DSS1 SETUP message . . . . . . . . . . . . 13 7.2.2.2.2 Receipt of DSS1 INFORMATION messages . . . . . . . . . . 13 7.2.2.2.3 Receipt of SIP 100 (Trying) response . . . . . . . . . . 14 7.2.2.2.4 Receipt of SIP 18x provisional response. . . . . . . . . 14 7.2.2.2.5 Receipt of SIP 2xx responses . . . . . . . . . . . . . . 14 7.2.2.2.6 Receipt of SIP 3xx responses . . . . . . . . . . . . . . 14 7.2.2.2.7 Receipt of SIP 484 response . . . . . . . . . . . . . . 14 7.2.2.2.8 Receipt of SIP 4xx, 5xx or 6xx responses . . . . . . . . 14 7.2.2.2.9 Receipt of multiple SIP responses . . . . . . . . . . . 15 7.2.2.2.10 Cancelling pending SIP INVITE transactions. . . . . . . 15 7.2.2.2.11 SIP INVITE requests routed differently . . . . . . . . 15 7.2.2.2.12 Timer T302 expired . . . . . . . . . . . . . . . . . . 15 7.3 Outgoing DSS1 call . . . . . . . . . . . . . . . . . . . . . . 16 7.3.1 Receipt of SIP INVITE request for a new call . . . . . . . . 16 7.3.2 Receipt of DSS1 CALL PROCEEDING message. . . . . . . . . . . 17 7.3.3 Receipt of DSS1 PROGRESS indicator . . . . . . . . . . . . . 18 7.3.4 Receipt of DSS1 ALERTING message . . . . . . . . . . . . . . 18 7.3.5 Inclusion of SDP information in a SIP 18x message. . . . . . 19 7.3.6 Receipt of DSS1 CONNECT message . . . . . . . . . . . . . . 19 7.3.7 Receipt of SIP PRACK . . . . . . . . . . . . . . . . . . . . 20 7.3.8 Receipt of SIP ACK . . . . . . . . . . . . . . . . . . . . 20 7.3.9 Receipt of multiple SIP INVITE - overlap sending . . . . . . 20 7.3.9.1 Exceptional procedure . . . . . . . . . . . . . . . . . . 21 7.4 Call clearing and call failure . . . . . . . . . . . . . . . . 21 7.4.1 Receipt of a DSS1 DISCONNECT, RELEASE or REL COMPL message. .21 7.4.2 Receipt of a SIP BYE request .. . . . . . . . . . . . . . . .22 7.4.3 Receipt of a SIP CANCEL request. . . . . . . . . . . . . . . 22 7.4.4 Receipt of a SIP 4xx - 6xx response. . . . . . . . . . . . . 22 7.4.5 MGC initiated call clearing . . . . . . . . . . . . . . . . 23 7.5 Request to change media characteristics. . . . . . . . . . . . 23 8 Mapping of E.164 numbers to URIs . . . . . . . . . . . . . . . . 23 9 Requirements to support DSS1 basic services. . . . . . . . . . . 24 9.1 Derivation of SDP from DSS1 Bearer Capability information. . . 24 Kotar Expires September 30, 2003 [Page 2] Internet-Draft DSS1-SIP Interworking March 2003 10 Security consideration . . . . . . . . . . . . . . . . . . . . 30 11 Author³s Addresses . . . . . . . . . . . . . . . . . . . . . . 31 12 Normative References . . . . . . . . . . . . . . . . . . . . . 31 Annex A Cause Mapping between DSS1 and SIP . . . . . . . . . . . . 33 Annex B Mapping of DSS1 to SIP messages . . . . . . . . . . . . . 35 1. Introduction This document specifies signalling interworking between DSS1 and the Session Initiation Protocol (SIP) for the basic call. The interworking for supplementary services is outside the scope of this specification. DSS1 is a signalling protocol that operates at the coincident S/T and T reference point between Public ISDN Local Exchange (LEX) within a Public Network. The S/T and T reference points are defined in ITU-T I.412. The ISDN provides circuit-switched basic services and supplementary services to its users. DSS1 is specified in ETSI ETS 300 403-1 for the basic call, in ETS 300 196-1 (generic functional protocol for the support of supplementary services) and a number of standards specifying individual supplementary services. SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over IP. Telephone calls are considered as a type of multimedia session where just audio is exchanged. SIP is defined in IETF RFC 3261. This document specifies signalling interworking for basic services that provide a bi-directional transfer capability for speech, DTMF, facsimile and modem media between a Media Gateway employing connectivity for DSS1 subscribers and DSS1 PABXs and UA at the IP network employing SIP. Call-related and call-independent signalling in support of supplementary services is outside the scope of this specification. DSS1 layer 3 signalling is transparently transported via SCTP and IUA from the MG to the MGC (Softswitch). The interworking between DSS1 and SIP is provided by the Softswitch. The aim is, that the basic call functionality are provided to the DSS1 user at the MG without service degradation when interworking with SIP for calls originating at a user at a MG that terminate at a user of an IP network, or a for calls originating at a user of an IP network that terminate at a user at a MG who is part of the public network. Interworking between a Private Networks employing DSS1 and SIP UA at IP networks 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.). 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 [2] and indicate requirement levels for compliant SIP implementations. Kotar Expires September 30, 2003 [Page 3] Internet-Draft DSS1-SIP Interworking March 2003 3 Definitions For the purposes of this specification, the following definitions apply. 3.1 External definitions This specification uses the following terms defined in other documents: -Call () -ISDN () -Public Network () Additionally the definitions in ETSI xxx and IETF RFC 3261 apply as appropriate. 3.2 Other definitions 3.2.1 Gateway An entity that performs interworking between a Public Network using DSS1 and an IP network using SIP. 3.2.2 IP network A network, offering connectionless packet-mode services based on the Internet Protocol (IP) as the network layer protocol. 3.2.3 Media stream Audio or other user information transmitted in UDP packets, typically containing RTP, in a single direction between the gateway and a peer entity participating in a session established using SIP. NOTE. Normally a SIP session establishes a pair of media streams, one in each direction. 4 Acronyms DSS1 Digital Subscriber Signalling System ISDN Integrated Services Digital Network IUA ISDN User Adaptation Protocol MG Media Gateway MGC Media Gateway Controller SCTP Stream Control Transmission Protocol SIP Session Initiation Protocol SDP Session Description Protocol UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol Kotar Expires - September 2003 [Page 4] Internet Draft SIP - DSS1 Interworking March 2003 5 Architecture This document specifies the signalling protocol interworking between DSS1 and SIP for the basic call. The Media Gateway provides connectivity for ISDN users (Terminals and PABXs) towards the IP network. The DSS1 signalling is transported transparently via SCTP/IUA to the Softswitch. For calls between DSS1 users and SIP UA the signalling interworking is provided by the interworking function within the softswitch. The interworking function SHALL be provided for basic call with the aim to not loose service information. In addition protocol interworking SHALL be provided for the DSS1 bearer and teleservice information and the adequate SDP information in the SIP body. Media Gateway Controller (MGC) +------------+ | | | | | | | SIP-DSS1 | |Interworking| | ^ ^ ^ | | | | | | | | | | | | | | | | +---+--+--+--+ | | | | | +-------------+ SCTP/IUA(DSS1)| | | SIP +------+ ISDN network | | | | | | | | |ISDN | | IP Network +---+---+ |Ter- | | | | | |minal | | | |SIP UA | +---+--+ *-----------+ | | | | | DSS1 | | | | +---+---+ +---------+--------| |-------+ | S/T | Media | +-------+ +-----+---------+--------+ Gateway + | SIP | T | | | | +---+----| | | | | | | +---+---+ | | | | | | +--+---+ +--+---+ *-----------+ |SIP UA | |ISDN | |ISDN | | | |Ter- | |PABX | +-------+ |minal | | | +------+ +------+ Figure 1 : Network structure Kotar Expires - September 2003 [Page 5] Internet Draft SIP-DSS1 Interworking March 2003 User at Media Gateways (either terminals or PABXs) are addressed by E.164 numbers [4]. In addition to the signalling interworking functionality specified in this specification, it is assumed that the Media Gateway also includes the following functionality: -one or more physical interfaces on the ISDN side for Basic Access and Primary Rate Access providing one or more constant bit rate channels for media information and a reliable layer 2 connection for transporting DSS1 signalling messages; and -one or more physical interfaces on the IP network side supporting, through layer 1 and layer 2 protocols, IP as the network layer protocol and UDP (RFC 768) and TCP (RFC 761) as transport layer protocols, these being used for the transport of SIP signalling messages and, in the case of UDP, also for media information; -optionally the support of TLS (RFC 2246) and/or SCTP (RFC 2960) as additional transport layer protocols on the IP network side, these being used for the transport of SIP signalling messages; and -a means of transferring media information in each direction between the ISDN and the IP network, including as a minimum packetization of media information sent to the IP network and de-packetization of media information received from the IP network. NOTE. RFC 3261 mandates support for both UDP and TCP for the transport of SIP messages and allows optional support for TLS and/or SCTP for this same purpose. +---------------------------------------------------------+ | Inter-working function | | | +-----------------------+---------+-----------------------+ | | | | | SIP | | | | | | | +-----------------------+ | | | | | DSS1 | | UDP/TCP/TLS/SCTP | | | | | | Basic Call | +-----------------------+ | | | | | Supplementary Services| | IP | | | | | | | +-----------------------+ | | | IP network | | | | lower layers | | | | | | | +-----------------------+ +-----------------------+ Figure 2 : Protocol model Kotar Expires - September 2003 [Page 6] Internet Draft SIP-DSS1 Interworking March 2003 The protocol model relevant to signalling interworking functionality of the Media Gateway Controller (MGC) is shown in figure 2. In figure 2, the SIP box represents SIP syntax and encoding, the SIP transport layer and the SIP transaction layer. The Interworking function includes SIP Transaction User (TU) functionality. 6 Overview The MGC maps the received DSS1 messages, where appropriate, to SIP messages and vice versa and keeps the protocol association between the DSS1 call and the SIP dialog. A SETUP message with address information (called party number containing a E.164 address) from a terminal or a PABX connected to the MG, addressing a SIP user agent, initiates a call request. After bearer channel selection between the user at the MG and the MGC, the MGC SHALL send a SIP INVITE request. The called party number with the E.164 address information SHALL be translated to a SIP URI, suitable for inclusion in a Request URI. The SIP 200 OK SHALL be mapped to the DSS1 CONNECT message. Bearer information in the DSS1 Bearer Capability and Low Layer Compatibility information elements SHALL be mapped to SIP SDP information. The resulting SIP dialog SHALL be assocaited with the DSS1 call. The media streams, established by SIP SHALL be "connected" to the circuit switched bearer channels A dialog from SIP to DSS1 SHALL be initiated, when a SIP INVITE request is received by the MGC. The MGC SHALL send a DSS1 SETUP message to the addressed user at the MG, after having translated the SIP Request-URI, containing the address information (called party number with E.164 address information) for addressing the destination DSS1 user. The bearer information in the SDP information in the SIP INVITE body SHALL be mapped to the Bearer capability and Low Layer Capability information elements. A received DSS1 CONNECT message SHALL be mapped to the SIP 200 OK message and establishes a association between a SIP dailog and a DSS1 call. Annex A gives examples for message sequences between SIP and DSS1. 7 Interworking of DSS1 and SIP for basic call procedures 7.1 General requirements The MGC SHALL comply to the DSS1 Basic Call Control [1], to the Generic functional protocol for support of supplementary services [3], to various DSS1 supplementary service specifications [x] - [y] and to SIP as a UA [2]. Note 1: A SIP entity supports UDP and TCP as transport layer protocols for SIP messages [2]. The MGC as a UA SHALL support SIP reliable provisional responses in accordance to [6]. Kotar Expires - September 2003 [Page 7] Internet Draft SIP-DSS1 Interworking March 2003 The MGC SHALL support SDP in accordance to [5] and its use in accordance to the offer/answer model in [7]. The MGC SHALL support both calls from DSS1 to SIP and calls from SIP to DSS1 users. The MGC SHALL evaluate the received DSS1 message according to [1] and SHALL act according to [1] to detect DSS1 protocol error. The requirements for mapping DSS1 to SIP apply only to DSS1 messages that have been successfully evaluated and comly to following conditions: - the DSS1 message is a SETUP message with a valid called party number information, or with a part of the called party number information, or whithout called party number information and a Bearer Capability information element and optionally a High Layer Compatibility information for which the MGC can provide interworking to a SIP dialog. - the DSS1 message is a INFORMATION message containing a valid Call Reference according to [1] and contains called party number information or called party number information in addition to the infromation in the SETUP message to allow the MGC to identify a SIP UA. - the DSS1 message is a message other than a SETUP or INFORMATION message and contains a Call Reference that identifies an existing call for which the MGC provides interworking bewteen DSS1 and SIP. If segmented DSS1 messages are received, the MGC SHALL wait for reception of all message segments and SHALL evaluate and process the complete reassembled message. The MGC SHALL evaluate received SIP messages (requests and responses) in accordance with the requirements in [2] and SHALL act on protocol errors in accordance with [2]. The requirements for mapping SIP to DSS1 apply only to SIP messages that have been successfully evaluated and comly to following conditions: - the SIP message is an INVITE request that contains no tag parameter in the To header field, does not match an ongoing transaction (i.e., is not a merged request, see 8.2.2.2 of [10]) and indicates a user in the PSTN for which the MGC is able to provide interworking; or - the SIP message is a request that relates to an existing dialog representing a call for which the MGC is providing interworking between DSS1 and SIP; or - the SIP message is a CANCEL request that relates to a received INVITE request for which the MGC is providing interworking with DSS1 but for which the only response sent is informational (1xx), no dialog having been confirmed; or - the SIP message is a response to a request sent by the MGC in accordance with this section. A SIP message in error SHALL not cause a protocol error at the DSS1 side but may lead to e.g. call clearing at the DSS1 side. Kotar Expires - September 2003 [Page 8] Internet Draft SIP-DSS1 Interworking March 2003 The MGC SHALL provide the DSS1 protocol timers as specified in [1] and SHALL act in accordance to [1] if a DSS1 protocol timer expires. If the expiry of the DSS1 protocol timer results in the DSS1 call clearing, the MGC SHALL also clear the SIP call in accordance to subsclause x.y.z of this specification. The MGC SHALL provide SIP protocol timers as specified in [2] and SHALL act in accordance to [2]. If the expiry of the SIP protocol timer results in clearing of the SIP dialog, the MGC SHALL also clear the DSS1 call in accordance with subclause x.y.z of this specification. 7.2 Incoming DSS1 call - call establishment at the originating interface A call request initiated form a DSS1 user SHALL be interworked by an interworking function within the MGC to a SIP dialog, after providing all required evaluations as described in subclause 7.1 Note: the interworking function provides, beside the protocol related functions, subscriber profile checks, address checks and mappings, bearer related information handling, resource checks etc. +----------------------------------------------------+ | MGC +---------------+ | | | Interworking | | | +-------------|-+ function +-|--------------+ | | | | | | | | | DSS1 call | | | | | | |SIP|dialog -----|--->| DSS1 protocol| | | SIP protocol |---|-----> | | | | | | | | | | | | | | | | | +-------------|-+ +-|--------------+ | | | | | | +---------------+ | +----------------------------------------------------+ Figure 3: Interworking function DSS1 - SIP 7.2.1 Call establishment using en-bloc sending The following procedure apply, when the MGC receives a SETUP message containing a bearer capability information element and contain all call information required by the MGC to process the call, i.e. the called party address information SHALL be contained in either the called party number information element, possible completed by the called party subaddress, or the keypad facility information element. The SETUP message may contain the sending complete information element or the "#" character within the called party number information element as indication for completeness of the called party number information, or the MGC determines the completeness of the called party number. If the B-channel selection procedure is successful, the MGC SHALL map the DSS1 SETUP message to a SIP INVITE message. The MGC SHALL send a DSS1 CALL PROCEEDING message. Kotar Expires - September 2003 [Page 9] Internet Draft SIP-DSS1 Interworking March 2003 During the call establishment, as the call leaves the ISDN environment, because of interworking with the packet network, the MGC SHALL send a progress indication to the calling DSS1 user in either a call control message when a call state change is required or a PROGRESS message when no state change is required, with a Progress indicator information elements, according to the procedures in 5.1.5 of [1]. The MGC SHALL generate the SIP the SIP Request-URI, To and From fields in the SIP INVITE request in accordance with section 9. The MGC SHALL include in the INVITE request a Supported header containing option tag 100rel, to indicate support for [6]. The MGC SHALL include SDP information in the SIP INVITE request as described in subclause 10. 7.2.1.1 Exceptional procedure The MGC receiving a DSS1 SETUP message, with a sending complete information element or a "#" character in the called party number information element or in the keypad facility information element, but with a called party number information which is wrong or incomplete, the MGC SHALL initiate DSS1 call clearing with a RELEASE COMPLETE message according to [1], using either cause #1, #3, #22 or #28. If information in the DSS1 SETUP message is unsuitable for generating any of the mandatory fields in a SIP INVITE request (e.g., if a Request-URI cannot be derived from the Called party number information element, or the B-channel selection procedure fails) or for generating SDP information, the MGC SHALL NOT issue a SIP INVITE request and SHALL initiate DSS1 call clearing procedures in accordance with [1]. 7.2.1.2 Receipt of a SIP 100 (Trying) response A received SIP 100 Trying SHALL not trigger a DSS1 message. It only serves the purpose of suppressing INVITE request retransmissions. 7.2.1.3 Receipt of a SIP 18x provisional response The MGC SHALL map a received SIP 18x response to a DSS1 PROGRESS or ALERTING message, based on the following conditions: - If a SIP 180 response is received and no DSS1 ALERTING message has been sent, the MGC SHALL generate a DSS1 ALERTING message according to 5.1.7 of [1]. - If a SIP 181/182/183 response is received, no DSS1 ALERTING message has been sent, no DSS1 PROGRESS message containing progress description number 8 has been sent and a media stream has been established towards the MGC, the MGC SHALL generate a DSS1 PROGRESS message. The DSS1 PROGRESS message SHALL contain progress description number 8 in a Progress indicator information element. The MGC SHALL also "connect" the media streams to the corresponding B-channel. - If a SIP 181/182/183 response is received, no DSS1 ALERTING message has been sent, no DSS1 PROGRESS message containing progress Kotar Expires - September 2003 [Page 10] Internet Draft SIP-DSS1 Interworking March 2003 description number 1 or 8 has been sent and no media stream has been established towards the MGC, the MGC SHALL generate a DSS1 PROGRESS message according to 5.1.6 of [1]. The DSS1 PROGRESS message SHALL contain progress description number 1 in a Progress indicator information element. NOTE 2. Media streams are established as a result of receiving SDP answer information in a reliable provisional response and can be modified by means of the SIP UPDATE method [10]. If a media stream is established towards the MGC, connecting the media stream to the corresponding B-channel will allow the caller to hear in-band tones or announcements. In all other scenarios the MGC SHALL NOT map the SIP 18x response to a DSS1 message. If the SIP 18x response contains a Require header with option tag 100rel, the MGC SHALL send back a SIP PRACK request in accordance with [6]. 7.2.1.4 Receipt of SIP 2xx response If the MGC receives a SIP 200 (OK) response as the first response to a SIP INVITE request, the MGC SHALL map the SIP 200 (OK) response to a DSS1 CONNECT message. The MGC SHALL also send a SIP ACK request to acknowledge the 200 (OK) response. The MGC SHALL NOT include any SDP information in the SIP ACK request. If the MGC receives further 200 (OK) responses, it SHALL respond to each in accordance with [2] and SHALL NOT generate any further DSS1 messages. Media streams will normally have been established in the IP network in each direction. If so, the MGC SHALL connect the media streams to the corresponding B-channel if it has not already done so and stop ringing. If the SIP 200 (OK) response is received in response to the SIP PRACK request, the MGC SHALL NOT map this message to a DSS1 message. If the MGC receives a SIP 2xx response other than 200 (OK), the MGC SHALL send a SIP ACK request. NOTE. A SIP 200 (OK) response can be received later as a result of a forking proxy. 7.2.1.5 Receipt of SIP 3xx response On receipt of a SIP 3xx response, the MGC SHALL act in accordance with [2]. NOTE. This will normally result in sending a new SIP INVITE request. The SIP 3xx response may lead to interworking procedures for supplementary services. DSS1 to SIP interworking for supplementary services is beyond the scope of this specification. Kotar Expires - September 2003 [Page 11] Internet Draft SIP-DSS1 Interworking March 2003 7.2.2 Call establishment using overlap sending SIP uses en-bloc signalling and it is strongly RECOMMENDED to avoid using overlap signalling in a SIP network. An MGC supporting overlap sending on the PSTN side, SHOULD perform a conversion from overlap sending on the PSTN side to en-bloc signalling method on the SIP side using one or more of the following mechanisms: -timers; -numbering plan information; -the presence of a Sending complete information element or a "#" character in the called party number or keypad facility information element a received DSS1 INFORMATION message. If the MGC performs a conversion from overlap to en-bloc signalling in the SIP network then the procedures defined in 8.2.2.1 SHALL apply. However, for some applications it might be impossible to avoid using overlap signalling in the SIP network. In this case the procedures defined in 7.2.1 SHALL apply. 7.2.2.1 Enbloc sending in SIP network 7.2.2.1.1 Receipt of a DSS1 SETUP message If the MGC receives a DSS1 SETUP message with either - no called number information, or - incomplete called party number information, or - called number information which the network cannot determine to be complete the MGC shall send a DSS1 SETUP ACKNOWLEDGE to the user and enter overlap sending state and shall start timer T302, according to 5.1.3 of [1]. The if no called number information is received, the MGC shall send in the SETUP ACKNOWLEDGE message a progress indicator #8 and return dial tone. 7.2.2.1.2 Receipt of DSS1 INFORMATION messages On receipt of each DSS1 INFORMATION message containing no Sending complete indication (either a sending complete information element or a "#" character) and containing a number that the MGC cannot determine to be complete, DSS1 timer T302 SHALL be restarted. When a DSS1 INFORMATION message containing - a Sending complete indication which the MGC understands, or - analysis by the MGC that all call information necessary to effect call establishment has been received, the MGC SHALL send a SIP INVITE request as described in 7.2.1. Kotar Expires - September 2003 [Page 12] Internet Draft SIP-DSS1 Interworking March 2003 The Request-URI and To fields (see section 9) SHALL be generated from the concatenation of information in the Called party number or keypad facility information element as in the received DSS1 SETUP and INFORMATION messages. The MGC SHALL also send a DSS1 CALL PROCEEDING message and stop timer T302, according to 5.1.5.2 of [1]. 7.2.2.1.3 Receipt of SIP responses SIP responses SHALL be mapped as described in 7.2.1. 7.2.2.2 Overlap sending in SIP network 7.2.2.2.1 Receipt of a DSS1 SETUP message On receipt of a DSS1 SETUP message containing no Sending complete indication and a number in the Called party number or the keypad facility information element that the MGC cannot determine to be complete, the MGC SHALL send back a DSS1 SETUP ACKNOWLEDGE message and start timer T302. If the DSS1 SETUP message contains the minimum number of digits required to route the call in the IP network, the MGC SHALL send a SIP INVITE request as specified in 7.2.1. Otherwise the MGC SHALL wait for more digits to arrive in DSS1 INFORMATION messages. 7.2.2.2.2 Receipt of DSS1 INFORMATION messages On receipt of a DSS1 INFORMATION message the MGC SHALL handle the timer T302 in accordance with [1]. NOTE 1. [1] requires the timer to be stopped if the INFORMATION message contains a Sending complete information element or to be restarted otherwise. Further behaviour of the MGC SHALL depend on whether or not it has already sent a SIP INVITE request. If the MGC has not sent a SIP INVITE request and it now has the minimum number of digits required to route the call, it SHALL send a SIP INVITE request as specified in 7.2.2.1.2 If the MGC still does not have the minimum number of digits required than it SHALL wait for more DSS1 INFORMATION messages to arrive. If the MGC has already sent one or more SIP INVITE requests, and whether or not final responses to those requests have been received, it SHALL send a new SIP INVITE request with the new digits. The new SIP INVITE request SHALL have the same Call-ID as the first SIP INVITE request sent but SHALL have updated Request-URI and To fields. The updated Request-URI and To fields (see section 9) SHALL be generated from the concatenation of information in the Called party number or keypad facility information element in the received DSS1 SETUP and INFORMATION messages. The CSeq header SHOULD contain a value higher than that in the previous SIP INVITE request. NOTE 2. The first SIP INVITE request and all subsequent SIP INVITE requests sent in this way belong to the same call but to different dialogs. Kotar Expires - September 2003 [Page 13] Internet Draft SIP-DSS1 Interworking March 2003 7.2.2.2.3 Receipt of SIP 100 (Trying) response The requirements of 7.2.1.2 SHALL apply. 7.2.2.2.4 Receipt of SIP 18x provisional response The requirements of 7.2.1.3 SHALL apply. 7.2.2.2.5 Receipt of SIP 2xx response The requirements of 7.2.1.4 SHALL apply. In addition the MGC SHALL send a SIP CANCEL request, either immediately or after a short delay, to cancel any SIP INVITE transactions for which no final response has been received. NOTE. Delaying the sending of a SIP CANCEL request allows time for final responses to be received on any outstanding transactions, thereby avoiding unnecessary signalling. 7.2.2.2.6 Receipt of SIP 3xx response The requirements of 7.2.1.5 SHALL apply. 7.2.2.2.7 Receipt of a SIP 484 (Address Incomplete) response The SIP 484 response indicates that more digits are required to complete the call. On receipt of a SIP 484 response the MGC SHALL send back a SIP ACK request. The MGC SHALL also send a DSS1 DISCONNECT message, if timer T302 has expired or a sending complete indication has been received and final responses have been received to all transmitted SIP INVITE requests. In all other cases the receipt of a SIP 484 response SHALL NOT trigger the sending of DSS1 message. 7.2.2.2.8 Receipt of a SIP 4xx (except 484), 5xx or 6xx response If a SIP 4xx (except 484), 5xx or 6xx final response arrives for a pending SIP INVITE transaction, the MGC SHALL send a SIP ACK request. If this occurs when no further DSS1 INFORMATION messages are expected and final responses have been received to all transmitted SIP INVITE requests, the MGC SHALL send a DSS1 DISCONNECT message (xxx8.4.4). NOTE. The MGC can take account of the SIP response code and other information to assess whether to wait for further responses before initiating clearing. Kotar Expires - September 2003 [Page 14] Internet Draft SIP-DSS1 Interworking March 2003 7.2.2.2.9 Receipt of multiple SIP responses The responses to all the SIP INVITE requests sent except for the last one are typically SIP 4xx responses (e.g. 484 (Address Incomplete)) that terminate the SIP INVITE transaction. However, the MGC can receive a SIP 183 (Session Progress) response with a media description. The MGC, receiving different SIP 183 (Session Progress) responses with media descriptions for different SIP INVITE transactions SHALL be evaluated by the MGC. The MGC SHALL decide which media stream (if any) shall be connected to the PSTN user. NOTE. It is up to the MGC to allow "early switch through" by connecting the B-channel with the media stream (if any), according to Annex K of [1]. NOTE. The MGC can receive multiple SIP 183 responses with media description not only as a result of sending multiple INVITE requests due to overlap sending but also as a result of a forking proxy. 7.2.2.2.10 Cancelling pending SIP INVITE transactions When a MGC sends a new SIP INVITE request containing new digits, it SHOULD NOT send a SIP CANCEL request to cancel a previous SIP INVITE transaction that has not had a final response. This SIP CANCEL request could arrive at the MGC before the new SIP INVITE request and trigger premature call clearing. NOTE. Previous SIP INVITE transactions can be expected to result in SIP 4xx class responses, which terminate the transaction. In 7.2.2.2.5 there is provision for cancelling any transactions still in progress after a SIP 2xx response has been received. 7.2.2.2.11 SIP INVITE requests routed differently To avoid the different routing of each SIP INVITE request (due to overlap sending of called party number information), it is RECOMMENDED that all the SIP INVITE requests should follow the same path as the first one. This would however restrict the number of services the SIP network can provide. This issue should be taken into consideration before using overlap signalling in SIP. If initiating multiple call establishments in the SIP network is not acceptable in a particular application, overlap signalling SHALL NOT be used. 7.2.2.2.12 Timer T302 expiry If DSS1 timer T302 expires and the MGC has received 4xx, 5xx or 6xx responses to all transmitted SIP INVITE requests, the MGC SHALL send a DSS1 DISCONNECT message. If T302 expires and the MGC has not received 4xx, 5xx or 6xx responses to all transmitted SIP INVITE requests, the MGC SHALL ignore any further DSS1 INFORMATION messages but SHALL NOT send a DSS1 DISCONNECT message at this stage. Kotar Expires - September 2003 [Page 15] Internet Draft SIP-DSS1 Interworking March 2003 NOTE. A DSS1 DISCONNECT message shall be sent when all outstanding SIP INVITE requests have received 4xx, 5xx or 6xx responses. 7.3 Outgoing DSS1 call - call establishment at the destination interface A call request initiated form a SIP UA SHALL be interworked by an interworking function within the MGC to a DSS1 call, after providing all required evaluations as described in subclause 7.1 Note: the interworking function provides, beside the protocol related functions, subscriber profile checks, address checks and mappings, bearer related information handling, resource checks etc. +----------------------------------------------------+ | MGC +---------------+ | | | Interworking | | | +-------------|-+ function +-|--------------+ | | | | | | | | | SIP dialog | | | | | | |DSS1 call ----|-->|SIP protocol | | | | DSS1 protocol|---|-----> | | | | | | | | | | | | | | | | | +-------------|-+ +-|--------------+ | | | | | | +---------------+ | +----------------------------------------------------+ Figure 4: Interworking function SIP - DSS1 7.3.1 Receipt of SIP INVITE request for a new call The assumption is that all called party information is sent to the MGC within one SIP INVITE message, i.e. at in the SIP network overlap sending is not applicable. Therefor, in this case all the called party information will be sent within the DSS1 SETUP message. If overlap sending in the SIP network is supported, i.e. the called party information is received by the MGC in multiple SIP INVITE that belong to the same call, subclause 7.3.9 shall apply. On receipt of a SIP INVITE request for a new call, the MGC SHALL generate a DSS1 SETUP message from the received SIP INVITE request, if it can select an idle B-channel, according to the procedure in 5.2.3 of [1]. The MGC SHALL generate the Called party number and Calling party number information in accordance with section 9 and SHALL generate the Bearer capability information element in accordance with section 10. If the MGC can determine that the called party number placed in the Called party number or keypad facility information element is complete, the MGC MAY include the Sending complete information element, if en-bloc receiving is used. Kotar Expires - September 2003 [Page 16] Internet Draft SIP-DSS1 Interworking March 2003 NOTE 1. The means by which the MGC determines the number to be complete is an implementation matter. As the call enters from the SIP network the PSTN network, the MGC shall include in the DSS1 SETUP message a Progress Indicator information element with either progress description #1 or #3, according to 5.2.6 of [1]. The MGC SHALL send a SIP 100 (Trying) response. If information in the SIP INVITE request is unsuitable for generating any of the mandatory information elements in a DSS1 SETUP message (e.g., if a Called party number information cannot be derived from SIP Request-URI field) or if no idle B-channel is available, the MGC SHALL NOT send a DSS1 SETUP message and SHALL send a SIP 4xx, 5xx or 6xx response. If an idle B-channel is not available, the MGC shall use response code 503 (Service Unavailable). If the SIP INVITE request does not contain SDP information and does not contain either a Required header or a Supported header with option tag 100rel, the MGC SHALL NOT issue a DSS1 SETUP message and SHALL send a SIP 488 (Not Acceptable Here) response. If the SIP INVITE contains an SDP information, for which a Bearer Capability cannot be derived by the MGC, the MGC MAY send either a SIP 488 (Not Acceptable Here) response or a SIP 415 response. NOTE 2. In case the MGC sends a SIP 415 response, it MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accepting- Language header field, according to 21.4.13 in [4]. NOTE 3. The absence of SDP offer information in the SIP INVITE request means that the MGC might need to send SDP offer information in a provisional response and receive SDP answer information in a SIP PRACK request (in accordance with [6]) in order to ensure that tones and announcements from the PSTN are transmitted. SDP offer information cannot be sent in an unreliable provisional response because SDP answer information would need to be returned in a SIP PRACK request. NOTE 4. If SDP offer information is present in the INVITE request, the issuing of a DSS1 SETUP message is not dependent on the presence of a Required header or a Supported header with option tag 100rel. On receipt of a SIP INVITE request relating to a call that has already been established from SIP to DSS1, the procedures of 7.3.9 SHALL apply. 7.3.2 Receipt of DSS1 CALL PROCEEDING message The receipt of a DSS1 CALL PROCEEDING message SHALL NOT result in any SIP message being sent. Kotar Expires - September 2003 [Page 17] Internet Draft SIP-DSS1 Interworking March 2003 7.3.3 Receipt of DSS1 PROGRESS indicator The MGC SHALL map a DSS1 Progress indicator information with progress description #1, #2, or #4 received either in a SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or PROGRESS message to a SIP 183 (Session Progress) response. If the SIP INVITE request contained either a Require header or a Supported header with option tag 100rel, the MGC SHALL include in the SIP 183 response a Require header with option tag 100rel. NOTE. In accordance with [6], inclusion of option tag 100rel in a provisional response instructs the UAC to acknowledge the provisional response by sending a PRACK request. [6] also specifies procedures for repeating a provisional response with option tag 100rel if no PRACK is received. If the DSS1 PROGRESS message contained a Progress indicator information element with Progress description number 1 or 8, the MGC MAY connect the media streams to the corresponding B-channel, if ANNEX K of [1] is supported, provided SDP answer information is included in the transmitted SIP response or has already been sent or received. Inclusion of SDP offer or answer information in the 183 provisional response SHALL be in accordance with 7.3.5. If call clearing is initiated, the cause value in the DSS1 PROGRESS message SHALL be used to derive the response to the SIP INVITE request in accordance with table 1. 7.3.4 Receipt of DSS1 ALERTING message The MGC SHALL map a DSS1 ALERTING message to a SIP 180 (Ringing) response. If the SIP INVITE request contained either a Require header or a Supported header with option tag 100rel, the MGC SHALL include in the SIP 180 response a Require header with option tag 100rel. The MGC shall stop timer T304, T303 or T310 (if running) and start timer T301, according to subclause 5.2.5.2 of [1] NOTE. In accordance with [6], inclusion of option tag 100rel in a provisional response instructs the UAC to acknowledge the provisional response by sending a PRACK request. [6] also specifies procedures for repeating a provisional response with option tag 100rel if no PRACK is received. If the DSS1 ALERTING message contained a Progress indicator information element with Progress description number 1 or 8, the MGC MAY connect the media streams to the B-channel if Annex K of [1] is supported, provided SDP answer information is included in the transmitted SIP response or has already been sent or received. Inclusion of SDP offer or answer information in the 180 provisional response SHALL be in accordance with 7.3.5. Kotar Expires - September 2003 [Page 18] Internet Draft SIP-DSS1 Interworking March 2003 7.3.5 Inclusion of SDP information in a SIP 18x provisional response When sending a SIP 18x provisional response, the MGC SHALL include SDP information in accordance with the following rules: If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 18x provisional response. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer information was received in the SIP INVITE request but no SDP answer information has been sent, SDP answer information SHALL be included in the SIP 18x provisional response. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if no SDP offer information was received in the SIP INVITE request and no SDP offer information has already been sent, SDP offer information SHALL be included in the SIP 18x provisional response. NOTE 1. In this case, SDP answer information can be expected in the SIP PRACK. If the SIP INVITE request contained neither a Required nor a Supported header with option tag 100rel, SDP answer information SHALL be included in the SIP 18x provisional response. NOTE 2. Because the provisional response is unreliable, SDP answer information needs to be repeated in each provisional response and in the final SIP 2xx response. NOTE 3. If the SIP INVITE request contained no SDP offer information and neither a Required nor a Supported header with option tag 100rel, it should have been rejected in accordance with 7.3.1. 7.3.6 Receipt of DSS1 CONNECT message The MGC SHALL map a DSS1 CONNECT message to a SIP 200 (OK) final response for the SIP INVITE request and shall connect the media streams to the selected B-channel, according to 5.2.8 of [1], if not already connected. The MGC SHALL also send a DSS1 CONNECT ACKNOWLEDGE message according to 5.2.7 and 5.2.8 of [1]. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 200 response. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer information was received in the SIP INVITE request but no SDP answer information has been sent, SDP answer information SHALL be included in the SIP 200 response. Kotar Expires - September 2003 [Page 19] Internet Draft SIP-DSS1 Interworking March 2003 If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if no SDP offer information was received in the SIP INVITE request and no SDP offer information has already been sent, SDP offer information SHALL be included in the SIP 200 response. NOTE 1. In this case, SDP answer information can be expected in the SIP ACK. If the SIP INVITE request contained neither a Required nor a Supported header with option tag 100rel, SDP answer information SHALL be included in the SIP 200 response. NOTE 2. Because the provisional response is unreliable, SDP answer information needs to be repeated in each provisional response and in the final 2xx response. NOTE 3. If the SIP INVITE request contained no SDP offer information and neither a Required nor a Supported header with option tag 100rel, it should have been rejected in accordance with 7.3.1. 7.3.7 Receipt of SIP PRACK request The receipt of a SIP PRACK request acknowledging a reliable provisional response SHALL NOT result in any DSS1 message being sent. The MGC SHALL send back a SIP 200 (OK) response to the SIP PRACK request. If the SIP PRACK contains SDP answer information and a DSS1 message containing a Progress indicator information element with progress description number 1 or 8 has been received, the MGC MAY connect the media streams to the B-channel, if Annex K in [1] is supported. 7.3.8 Receipt of SIP ACK request The receipt of a SIP ACK request SHALL NOT result in any DSS1 message being sent. If the SIP ACK contains SDP answer information, the MGC MAY connect the media streams to the B-channel, if Annex K in [1] is supported. 7.3.9 Receipt of multiple SIP INVITE- overlap sending in SIP network For a call from SIP using overlap sending procedures, the MGC will receive multiple SIP INVITE requests that belong to the same call but have different Request-URI and To fields. Each SIP INVITE request belongs to a different dialog. If a MGC receives a SIP INVITE request with the same Call-ID as an existing call for which the MGC is is in overlap sending state and with updated Request-URI and To fields from which a called party number with a superset of digits can be derived, it MGC SHALL generate a DSS1 INFORMATION message containing the called party number information in Kotar Expires - September 2003 [Page 20] Internet Draft SIP-DSS1 Interworking March 2003 either a called party number or keypad facility information element according to subclause 5.2.4 of [1]. The MGC SHALL also respond to the SIP INVITE request received previously with a SIP 484 Address Incomplete response. 7.3.9.1 Exceptional procedures If a MGC receives a SIP INVITE request with the same Call-ID as an existing SIP INVITE request for which the MGC has not yet sent a final response and failing to meet the other conditions above concerning overlap sending, the MGC SHALL clear the call by sending back a SIP 485 (Ambiguous) response and a DSS1 DISCONNECT message with Cause Value #16 (Normal call clearing) or #31 (Normal, unspecified). 7.4 Call clearing and call failure 7.4.1 Receipt of a DSS1 DISCONNECT, RELEASE or RELEASE COMPLETE message On receipt of DSS1 DISCONNECT, RELEASE or RELEASE COMPLETE message according to 5.2.5.3 or 5.3 of [1], depending on the state of SIP dialog, the MGC SHALL behave in the following way: 1)If the MGC has sent a SIP 200 (OK) response and received a SIP ACK request or has received a SIP 200 (OK) response and sent a SIP ACK request, the MGC SHALL send a SIP BYE request to clear the call. 2)If the MGC has sent a SIP 200 (OK) response (indicating that call establishment is complete) but has not received a SIP ACK request, the MGC SHALL wait until a SIP ACK is received and then send a SIP BYE request to clear the call. 3)If the MGC has sent a SIP INVITE request and received a SIP provisional response but not a SIP final response, the MGC SHALL send a SIP CANCEL request to clear the call. NOTE 1. In accordance with [4], if after sending a SIP CANCEL request a SIP 2xx response is received to the SIP INVITE request, the MGC will need to send a SIP BYE request. 4)If the MGC has sent a SIP INVITE request but received no SIP response, the MGC SHALL NOT send a SIP message. If a SIP final or provisional response is subsequently received, the MGC SHALL then act in accordance with 1, 2 or 3 above respectively. 5)If the MGC has received a SIP INVITE request but not sent a SIP final response, the MGC SHALL send a SIP final response chosen according to the cause value in the received DSS1 message as specified in table 1. SIP response 500 (Server internal error) SHALL be used as the default for cause values not shown in table 1. Kotar Expires - September 2003 [Page 21] Internet Draft SIP-DSS1 Interworking March 2003 NOTE 2. It is not necessarily appropriate to map some DSS1 cause values to SIP messages. If this is not possible, the MGC should treat it either as a congestion situation (no channels available, see 7.3.1) or as a MGC failure situation (in which case the default SIP response code applies). In all cases the MGC SHALL also disconnect media streams, if established, and allow DSS1 and SIP signalling to complete in accordance with [1] and [4], respectively. The MGC may connect the B-channel to the called user, if not already connceted when clearing with tones and announcements are provided according to 5.3.4.1 of [1] 7.4.2 Receipt of a SIP BYE request On receipt of a SIP BYE request, the MGC SHALL send a DISCONNECT message with cause value 16 (normal call clearing). The MGC SHALL also disconnect media streams, if established, and allow DSS1 and SIP signalling to complete in accordance with [1] and [4], respectively. NOTE 1. When responding to a SIP BYE request, in accordance with [10] the MGC is also required to respond to any other outstanding transactions, e.g., with a SIP 487 (Request Terminated) response. This applies in particular if the MGC has not yet returned a final response to the SIP INVITE request. NOTE 2. When providing tones/announcements during call clearing, the MGC may connect, if not already connected to the B-channel, according to 5.3.4.1 of [1]. 7.4.3 Receipt of a SIP CANCEL request On receipt of a SIP CANCEL request to clear a call for which the MGC has not sent a SIP final response to the received SIP INVITE request, the MGC SHALL send a DSS1 DISCONNECT message with cause value 16 (normal call clearing). The MGC SHALL also disconnect media streams, if established, and allow DSS1 and SIP signalling to complete in accordance with [1] and [4], respectively. NOTE. When providing tones/announcements during call clearing, the MGC may connect, if not already connected to the B-channel, according to 5.3.4.1 of [1]. 7.4.4 Receipt of a SIP 4xx - 6xx response Except where otherwise specified in the context of overlap sending (7.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP INVITE request, the MGC SHALL send a DSS1 DISCONNECT message. The cause value in the DSS1 DISCONNECT message SHALL be derived from the SIP 4xx-6xx response according to table 2. Cause value 31 (Normal, unspecified) SHALL be used as the default for SIP responses not shown in table 2. The MGC SHALL also disconnect media streams, if established, and allow DSS1 and SIP signalling to complete in accordance with [1] and [4], respectively. Kotar Expires - September 2003 [Page 22] Internet Draft SIP-DSS1 Interworking March 2003 NOTE. When providing tones/announcements during call clearing, the MGC may connect, if not already connected to the B-channel, according to 5.3.4.1 of [1]. When generating a DSS1 Cause information element, the location field SHOULD contain a value related to the call configuration. 7.4.5 MGC-initiated call clearing If the MGC initiates clearing of the DSS1 call because of timer expiry, DSS1 protocol error according to subclause 5.8, or initiation DSS1 RESTART procedure according to subclause 5.5 of [1], the MGC SHALL also initiate clearing of the SIP call in accordance with 7.4.1. If this involves the sending of a final response to a SIP INVITE request, the MGC SHALL use response code 480 (Temporarily Unavailable), response code 408 (Request timeout) or 500 (Server internal error) as appropriate. If the MGC initiates clearing of the SIP call because of timer expiry or SIP protocol error in accordance with [4], the MGC SHALL also initiate clearing of the DSS1 call in accordance with subclause 5.3 of [1], using cause value 102 (Recovery on timer expiry) or 41 (Temporary failure) as appropriate. 7.5 Request to change media characteristics If after a call has been successfully established the MGC receives a SIP INVITE request to change the media characteristics of the call in a way that would be incompatible with the bearer capability in use within the ISDN, the MGC SHALL send back a SIP 503 (Service unavailable) response and SHALL NOT change the media characteristics of the existing call. 8 Mapping of E.164 numbers to URIs In DSS1, the address of the called user is conveyed in the called party number information element, the address of the calling user in the calling party number information element. The Calling party number information element contains a presentation indicator which can indicate that privacy is required and a screening indicator that indicates the source and authentication status of the number. The privacy is a matter of the Calling Line Identification Presentation and Calling Line Identification Restriction supplementary service and shall be outside the scope of this specification. NOTE. For interworking of DSS1 supplementary services with SIP a separate specification is required. In SIP, users are identified by Universal Resource Identifiers (URIs) conveyed within the Request-URI and various headers, including the From and To headers specified in [10] and the P-Asserted-Identity header specified in [14]. In addition, privacy is indicated by the Privacy header specified in [13]. As indicated above, privacy considerations are part of supplementary service specifications (e.g. CLIP, CLIR, COLP, COLR) and are outside the scope of this specification. This clause specifies the mapping between DSS1 Called party number, and corresponding elements in SIP. Kotar Expires - September 2003 [Page 23] Internet Draft SIP-DSS1 Interworking March 2003 8.1 Mapping DSS1 number information to SIP URI The method used to convert a called party number to a URI is outside the scope of this specification. However, the MGC SHOULD take account of the Numbering Plan (NPI) and Type Of Number (TON) fields in the DSS1 called party number information element concerned when interpreting a number. 8.1.1 Using information from the DSS1 Called party number information element The MGC SHALL convert the number in the DSS1 Called party number information to a URI and include that URI in the SIP Request-URI and in the To header. 8.2 Mapping SIP URI to DSS1 number information The method used to convert a URI to a number is outside the scope of this specification. However, NPI and TON fields in the DSS1 called party information element concerned SHALL be set to appropriate values in accordance with [1]. 8.2.1 Generating the DSS1 Called party number information element The MGC SHALL convert the URI in the SIP Request-URI to a called party number information and include that number in the DSS1 Called party number information element. 9 Requirements for support fo DSS1 basic services This document specifies signalling interworking for basic services (bearer and teleservices) that provide a bi-directional transfer capability between the two networks. 9.1 Derivation of DSS1 Bearer capability information element The MGC SHALL generate the Bearer Capability (BC) and High Layer Compatibility (HLC) information element and Low Layer Compatibility (LLC) information element based on SDP information. The LLC information element is required to assure end-to-end terminal compatibility. Only the interworking relevant fields of BC/HLC and LLC are listed to derive the SDP lines. Table 3 Bearer capability and High Layer Compatibility encoding for speech (A-law) ------------------ Bearer Capability information: Information transfer "speech" (00000) capability Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User Information Layer 1 "G.711, A-law" High Layer Compatibility information: not required Kotar Expires - September 2003 [Page 24] Internet Draft SIP-DSS1 Interworking March 2003 Low Layer Compatibility: not required SDP lines m=audio RTP/AVT 8 a= - b= 64kbit/s for 3.1kHz audio (A-law) ------------------------ Bearer Capability information: Information transfer "3,1 kHz audio" (10000) capability Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User Information Layer 1 "G.711, A-law" High Layer Compatibility information: not required Low Layer Compatibility: not required SDP lines m=audio RTP/AVT 8 a= - b= 64kbit/s for 3.1kHz audio (“-law) ------------------------ Bearer Capability information: Information transfer "3,1 kHz audio" (10000) capability Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User Information Layer 1 "G.711, “-law" High Layer Compatibility information: not required Low Layer Compatibility: not required SDP lines m=audio RTP/AVT 0 a= - b= 64kbit/s Kotar Expires - September 2003 [Page 25] Internet Draft SIP-DSS1 Interworking March 2003 for unrestricted digital information ------------------------------------ Bearer Capability information: Information transfer "unrestricted digital information" capability (01000) Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) High Layer Compatibility information: not required Low Layer Compatibility: not required SDP lines m=audio RTP/AVT DynamicPT a=rtpmap:xxxx -- Clearmode codepoint not yet -- standardized b=AS:64kbit/s for telephony 3.1kHz (A-law) ---------------------------- Bearer Capability information: Information transfer "speech" (10000) capability Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User Information Layer 1 "G.711, A-law" High Layer Compatibility information: High Layer characteristic "telephony" identification Low Layer Compatibility: not required SDP lines m=audio RTP/AVT 8 a= - b= 64kbit/s Kotar Expires - September 2003 [Page 26] Internet Draft SIP-DSS1 Interworking March 2003 for telephony 7 kHz -------------------- Bearer Capability information: Information transfer "unrestricted digital information capability with tones/announcements" (01000) Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User Information Layer 1 "Recommendation H.221 and H.242" High Layer Compatibility information: High Layer characteristic "telephony" identification Low Layer Compatibility: not required SDP lines m=audio RTP/AVT 9 a=rtpmap:9 G.722/8000 b=AS:64kbit/s for Facsimile Gr 2-3 -------------------- Bearer Capability information: Information transfer "3,1 kHz audio" (10000) capability Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User Information Layer 1 "G.711, A-law" High Layer Compatibility information: High Layer characteristic "facsimile group 2/3 identification (Recommendation F.182)" Low Layer Compatibility: not required SDP lines m=image udptl t38 a=based on T.38 b= 64kbit/s Kotar Expires - September 2003 [Page 27] Internet Draft SIP-DSS1 Interworking March 2003 for telefax G4 -------------- Bearer Capability information: Information transfer "unrestricted digital information" capability (01000) Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) High Layer Compatibility information: High Layer characteristic "group 4 class 1 facsimile" identification Low Layer Compatibility: Information transfer "unrestricted digital information" capability (01000) Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User Information layer 2 "ISO/IEC 7776 DTE-DTE operation" Optional layer 2 protocol "--set according to the capability information of the terminal--" User information layer 3 "ISO/IEC 8208" Optional layer 3 protocol "--set according to the capability of the terminal" SDP lines m=audio RTP/AVT DynamicPT a=rtpmap:xxxx -- Clearmode codepoint not yet -- standardized b=AS:64kbit/s NOTE. The HLC and LLC information is required by the terminal applications and transported in ISDN in ISUP ATP. This information cannot be mapped to SDP, therefor this information should be transported in the SIP INVITE body as MIME type. This is still open and need to be discussed. for videotelephony ------------------ for the first connection: Bearer Capability information: Information transfer "unrestricted digital information capability with tones and announcements" (01000)" Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User information layer 1 "Recommendations H.221 and H.242" Kotar Expires - September 2003 [Page 28] Internet Draft SIP-DSS1 Interworking March 2003 High Layer Compatibility information: High Layer characteristic "videotelephony (Recommendation identification F.721" Extended High Layer "capability set of initial channel characteristics identification of Recommendation H.221" Low Layer Compatibility: not required for second connection Bearer Capability information: Information transfer "unrestricted digital information" capability (01000) Transfer mode "circuit mode" (00) Information transfer rate "64 Kbits/s" (10000) User information layer 1 "Recommendations H.221 and H.242" High Layer Compatibility information: High Layer characteristic "videotelephony (Recommendation identification F.721" Extended High Layer "capability set of initial channel characteristics identification of Recommendation H.221" Low Layer Compatibility: not required SDP lines m=audio RTP/AVT 9 a=rtpmap:9 G.722/8000 b=AS:64kbit/s m=video RTP/AVP a=rtpmap:9 xxxx b=AS:64bbit/s NOTE. Shall audio and video be coded as two different RTP streams or multiplexed within one stream; how is the option with only one connection for both audio and video described in SDP. for mulltirate -------------- to be provided. 9.2 Derivation of media type in SDP to be provided. Kotar Expires - September 2003 [Page 29] Internet Draft SIP-DSS1 Interworking March 2003 10 Security consideration In most respects, the information that is translated from DSS1 to SIP has no special security requirements. In order for translated information elements to be used to route requests, they shall be legible to intermediaries; end-to-end confidentiality of this data would be unnecessary and most likely detrimental. There are also numerous circumstances under which intermediaries can legitimately overwrite the values that have been provided by translation, and hence integrity over these headers is similarly not desirable. There are some concerns, however, that arise from the other direction of mapping, the mapping of SIP headers to DSS1 information elements, which are enumerated in the following paragraphs. When end users dial numbers in a ISDN/PSTN, their selections populate the Called party number information element in the DSS1 SETUP message. Similarly, the SIP URI or tel URL and its optional parameters in the Request-URI of a SIP INVITE request, which can be created directly by end users of a SIP device, map to that information element at the MGC. However, in an ISDN/PSTN, policy can prevent the user from dialing certain (invalid or restricted) numbers. Thus, policies my be applied to restrict the use of certain SIP URIs or tel URLs, or SIP URI or tel URL parameters, when authorizing a call from SIP to DSS1. Some additional risks may result from the SIP response code to DSS1 cause value mapping. SIP user agents could conceivably respond to an INVITE request from a gateway with any arbitrary SIP response code, and thus they can dictate (within the boundaries of the mappings supported by the MGC) the Q.850 cause code that will be sent by the MGC in the resulting DSS1 call clearing message. Generally speaking, the manner in which a call is rejected is unlikely to provide any avenue for fraud or denial of service (e.g., by signalling that a call should not be billed, or that the network should take critical resources off-line). This specification requires the MGC to map the Request-URI rather than the To header in a SIP INVITE request to the Called party number information element in a DSS1 SETUP message. Although a SIP UA is expected to put the same URI in the To header and in the Request-URI, this is not policed by other SIP entities. Therefore a To header URI that differs from the Request-URI received at the MGC cannot be used as a reliable indication that the call has been retargeted in the SIP network or as a reliable indication of the original target. The arbitrary population of the From header of requests by SIP user agents has some well-understood security implications for devices that rely on the From header as an accurate representation of the identity of the originator. There is another class of potential risk that is related to the cut- through of the backwards media path before the call is answered. Several practices described in this document involve the connection of media streams to B-channels and the sending of progress description number 1 or 8 in a DSS1 message. This can result in media being cut through end-to-end, and it is possible for the called user agent then to play arbitrary audio to the caller for an indefinite period of time before transmitting a final response (in the form of a 2xx or higher response code). Kotar Expires - September 2003 [Page 30] Internet Draft SIP-DSS1 Interworking March 2003 Also early cut-through can help to prevent clipping of the initial media when the call is answered. There are conceivable respects in which this capability could be used fraudulently by the called user agent for transmitting arbitrary information without answering the call or before answering the call. Unlike a traditional ISDN/PSTN phone, a SIP user agent can launch multiple simultaneous requests in order to reach a particular resource. It would be trivial for a SIP user agent to launch 100 SIP INVITE requests at a 100 port MGC, thereby tying up all of its ports. A malicious user could choose to launch requests to telephone numbers that are known never to answer, or, where overlap signalling is used, to incomplete addresses. This could saturate resources at the MGC indefinitely, potentially without incurring any charges. Networks may therefore wish to provide means of restricting according to policy the number of simultaneous requests originating from the same authenticated source, or similar mechanisms to address this possible denial-of-service attack. 11 Author's Addresses Peter Kotar Alcatel SEL AG Lorenzstrasse 10 70435 Stuttgart Germany Tel.: + 49 711 821 41170 Fax: + 49 711 821 40211 email: P.Kotar@alcatel.de 12 Normative References [1] ITU-T Recommendation Q.931: "Digital Subscriber Signalling System No. one (DSS1) - ISDN User Network Interface Layer 3 Specification for Basic Call Control [2] ETS 300 196-1: "Integrated Services Digital Network (ISDN); Generic functional protocol for the support of supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification". [3] ITU-T Recommendation E.164: The International Public Telecommunication Numbering Plan, 1997-05 [4] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261, April 2002. [5] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327. [6] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional Responses in SIP", RFC 3262. [7] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264. Kotar Expires - September 2003 [Page 31] Internet Draft SIP-DSS1 Interworking March 2003 [8] J. Peterson, "Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323 [9] C. Jennings, J. Peterson, M. Watson, ŸPrivate Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks÷, RFC 3325 [10] J. Rosenberg, "The Session Initiation Protocol UPDATE Method", RFC 3311. Full Copyright Statement Copyright (C) The Internet Society (2002). 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 implementation 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kotar Expires - September 2003 [Page 32] Internet Draft SIP-DSS1 Interworking March 2003 Annex A Cause Mapping between DSS1 and SIP A.1 Mapping between DSS1 causes and SIP 4xx-6xx response DSS1 Cause value SIP response ---------------------------------------------------------- 1 Unallocated number 404 Not found 2 No route to specified 404 Not found transit network 3 No route to destination 404 Not found 16 Normal call clearing (NOTE 3) 17 User busy 486 Busy here 18 No user responding 408 Request timeout 19 No answer from the user 480 Temporarily unavailable 20 Subscriber absent 480 Temporarily unavailable 21 Call rejected 603 Decline, if location field in Cause information element indicates user. Otherwise: 403 Forbidden 22 Number changed 301 Moved permanently, if information in diagnostic field of Cause information element is suitable for generating a SIP Contact header. Otherwise: 410 Gone 23 Redirection to new 410 Gone destination 27 Destination out of order 502 Bad gateway 28 Address incomplete 484 Address incomplete 29 Facility rejected 501 Not implemented 31 Normal, unspecified 480 Temporarily unavailable 34 No circuit/channel 503 Service unavailable available 38 Network out of order 503 Service unavailable 41 Temporary failure 503 Service unavailable 42 Switching equipment 503 Service unavailable congestion 47 Resource unavailable, 503 Service unavailable unspecified 55 Incoming calls barred 403 Forbidden within CUG 57 Bearer capability not 403 Forbidden authorized 58 Bearer capability not 503 Service unavailable presently available 65 Bearer capability not 488 Not acceptable here (NOTE implemented 4) 69 Requested facility not 501 Not implemented implemented 70 Only restricted digital 488 Not acceptable here (NOTE information available 4) 79 Service or option not 501 Not implemented implemented, unspecified 87 User not member of CUG 403 Forbidden 88 Incompatible destination 503 Service unavailable 102 Recovery on timer expiry 504 Server time-out Kotar Expires - September 2003 [Page 33] Internet Draft SIP-DSS1 Interworking March 2003 A.1 Mapping between SIP 4xx-6xx response and DSS1 causes SIP response DSS1 Cause value --------------------------------------------------------------- 400 Bad request 41 Temporary failure 401 Unauthorized 21 Call rejected (NOTE 1) 402 Payment required 21 Call rejected 403 Forbidden 21 (Call rejected) 404 Not found 1 (Unallocated number) 405 Method not allowed 63 Service or option unavailable, unspecified 406 Not acceptable 79 Service or option not implemented, unspecified 407 Proxy Authentication required 21 Call rejected (NOTE 1) 408 Request timeout 102 Recovery on timer expiry 410 Gone 22 Number changed 413 Request entity too large 127 Interworking, unspecified (NOTE 2) 414 Request-URI too long 127 Interworking, unspecified (NOTE 2) 415 Unsupported media type 79 Service or option not implemented, unspecified (NOTE 2) 416 Unsupported URI scheme 127 Interworking, unspecified (NOTE 2) 420 Bad extension 127 Interworking, unspecified (NOTE 2) 421 Extension required 127 Interworking, unspecified (NOTE 2) 423 Interval too brief 127 Interworking, unspecified (NOTE 2) 480 Temporarily unavailable 18 No user responding 481 Call/transaction does not exist 41 Temporary failure 482 Loop detected 25 Exchange routing error 483 Too many hops 25 Exchange routing error 484 Address incomplete 28 Invalid number format (NOTE 2) 485 Ambiguous 1 Unallocated Number 486 Busy here 17 User busy 487 Request terminated (NOTE 3) 488 Not Acceptable Here 65 Bearer capability not implemented or 31 Normal, unspecified(NOTE 4) 500 Server internal error 41 Temporary failure 501 Not implemented 79 Service or option not implemented, unspecified 502 Bad gateway 38 Network out of order 503 Service unavailable 41 Temporary failure 504 Gateway time-out 102 Recovery on timer expiry 505 Version not supported 127 Interworking, unspecified (NOTE 2) 513 Message too large 127 Interworking, unspecified (NOTE 2) 600 Busy everywhere 17 User busy 603 Decline 21 Call rejected 604 Does not exist anywhere 1 Unallocated number Kotar Expires - September 2003 [Page 34] Internet Draft SIP-DSS1 Interworking March 2003 606 Not acceptable 65 Bearer capability not implemented or 31 Normal, unspecified(NOTE 4) Annex B Mapping of DSS1 to SIP messages Following table provide an overview of DSS1 messages to SIP message mapping. +--------------------+--------------------+---------------------------+ | DSS1 | to SIP | Remark | +--------------------+--------------------+---------------------------+ | SETUP | INVITE | called party number | | | | complete, or sufficient | | | | digits to route the call | +--------------------+--------------------+---------------------------+ | | | | | CALL PROCEEDING | - | Local message at the DSS1| | | | side | +--------------------+--------------------+---------------------------+ | | | | | CONNECT | 200 OK | | | | | | +--------------------+--------------------+---------------------------+ | | | | | CONNECT ACK | - | Local message at the DSS1| | | | side | +--------------------+--------------------+---------------------------+ | DISCONNECT, | BYE | SIP ACK send or received | | RELEASE, RELEASE | | | | COMPLETE | | | +--------------------+--------------------+---------------------------+ | DISCONNECT, | CANCEL | no final SIP response | | RELEASE, RELEASE | | (ACK) received | | COMPLETE | | | +--------------------+--------------------+---------------------------+ | INFORMATION | INVITE | SETUP received; T302 | | | | expired; sending complete| | | | i.e. received | +--------------------+--------------------+---------------------------+ | | | | | PROGRESS |183 Session Progress| | | | | | +--------------------+--------------------+---------------------------+ + | | | | ALERTING | 180 Ringing | | | | | | +--------------------+--------------------+---------------------------+ Table 1: DSS1 to SIP message mapping Kotar Expires - September 2003 [Page 35] Internet Draft SIP-DSS1 Interworking March 2003 Following table provide an overview of SIP messages to DSS1 message mapping. +--------------------+--------------------+---------------------------+ | SIP message | to DSS1 message | Remark | +--------------------+--------------------+---------------------------+ | 100 Trying | - | | | | | | | | | | +--------------------+--------------------+---------------------------+ | | | | | ACK | - | | | | | | +--------------------+--------------------+---------------------------+ | | | | | PRACK | - | | | | | | +--------------------+--------------------+---------------------------+ | | | | | INVITE | SETUP | | | | | | +--------------------+--------------------+---------------------------+ | DISCONNECT, | BYE | SIP ACK send or received | | RELEASE, RELEASE | | | | COMPLETE | | | +--------------------+--------------------+---------------------------+ | DISCONNECT, | CANCEL | no final SIP response | | RELEASE, RELEASE | | (ACK) received | | COMPLETE | | | +--------------------+--------------------+---------------------------+ | INFORMATION | INVITE | SETUP received; T302 | | | | expired; sending complete| | | | i.e. received | +--------------------+--------------------+---------------------------+ | | | | | PROGRESS |183 Session Progress| | | | | | +--------------------+--------------------+---------------------------+ + | | | | ALERTING | 180 Ringing | | | | | | +--------------------+--------------------+---------------------------+ Table 2: SIP to DSS1 message mapping Annex C Mapping of DSS1 information elements to SIP Headers to be provided. Mapping of SIP headers to DSS1 information elements to be provided Kotar Expires - September 2003 [Page 36]