idnits 2.17.1 draft-elwell-sipping-qsig2sip-03.txt: -(149): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(150): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(850): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1305): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1683): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1875): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1914): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1917): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1926): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1993): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2052): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2134): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2270): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2340): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2410): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2438): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2471): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2512): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2541): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2575): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 35 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 1030 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 18 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 443: '...specification, a gateway SHALL support...' RFC 2119 keyword, line 444: '...143 as a gateway and SHALL support SIP...' RFC 2119 keyword, line 445: '... a UA. In particular the gateway SHALL...' RFC 2119 keyword, line 448: '... gateway SHALL support SIP TU b...' RFC 2119 keyword, line 455: '... The gateway SHALL also support SI...' (207 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 468 has weird spacing: '...dentity heade...' == Line 646 has weird spacing: '... stream to th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1875, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1883, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1888, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1893, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1895, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1897, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1899, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1902, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1908, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1911, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 793 (ref. '5') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2246 (ref. '7') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (ref. '8') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2960 (ref. '9') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 2460 (ref. '17') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Elwell 3 Internet Draft Siemens 4 F. Derks 5 Philips 6 P. Mourot/O. Rousseau 7 draft-elwell-sipping-qsig2sip-03.txt Alcatel 8 Expires: April 2003 October 2002 10 Interworking between SIP and QSIG 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026 except that the right to produce derivative 16 works is not granted. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document specifies interworking between the Session Initiation 35 Protocol (SIP) and QSIG within corporate telecommunication networks 36 (also known as enterprise networks). SIP is an Internet application- 37 layer control (signalling) protocol for creating, modifying, and 38 terminating sessions with one or more participants. These sessions 39 include, in particular, telephone calls. QSIG is a signalling 40 protocol for creating, modifying and terminating circuit-switched 41 calls, in particular telephone calls, within Private Integrated 42 Services Networks (PISNs). QSIG is specified in a number of ECMA 43 Standards and published also as ISO/IEC standards. 45 As the support of telephony within corporate networks evolves from 46 circuit-switched technology to Internet technology, the two 47 technologies will co-exist in many networks for a period, perhaps 48 several years. Therefore there is a need to be able to establish, 49 modify and terminate sessions involving a participant in the SIP 50 network and a participant in the QSIG network. Such calls are 51 supported by gateways that perform interworking between SIP and QSIG. 53 This document is a product of the authors' activities in ECMA 54 (www.ecma.ch) on interoperability of QSIG with IP networks. 56 1 Introduction....................................................4 57 2 Terminology.....................................................5 58 3 Definitions.....................................................5 59 3.1 External definitions..........................................5 60 3.2 Other definitions.............................................5 61 3.2.1 Gateway.....................................................5 62 3.2.2 IP network..................................................5 63 3.2.3 Media stream................................................5 64 4 Acronyms........................................................6 65 5 Background and architecture.....................................6 66 6 Overview........................................................9 67 7 General requirements...........................................10 68 8 Message mapping requirements...................................11 69 8.1 Message validation and handling of protocol errors...........11 70 8.2 Call establishment from QSIG to SIP..........................12 71 8.2.1 Call establishment from QSIG to SIP using enbloc procedures12 72 8.2.1.1 Receipt of QSIG SETUP message............................12 73 8.2.1.2 Receipt of SIP 100 (Trying) response.....................13 74 8.2.1.3 Receipt of SIP 18x provisional response..................13 75 8.2.1.4 Receipt of SIP 2xx response..............................14 76 8.2.1.5 Receipt of SIP 3xx response..............................15 77 8.2.2 Call establishment from QSIG to SIP using overlap procedures15 78 8.2.2.1 Enbloc signalling in SIP network.........................15 79 8.2.2.1.1 Receipt of QSIG SETUP message..........................15 80 8.2.2.1.2 Receipt of QSIG INFORMATION message....................16 81 8.2.2.1.3 Receipt of SIP responses...............................16 82 8.2.2.2 Overlap signalling in SIP network........................16 83 8.2.2.2.1 Receipt of QSIG SETUP message..........................16 84 8.2.2.2.2 Receipt of QSIG INFORMATION message....................16 85 8.2.2.2.3 Receipt of SIP 100 (Trying) response...................17 86 8.2.2.2.4 Receipt of SIP 18x provisional response................17 87 8.2.2.2.5 Receipt of SIP 2xx response............................17 88 8.2.2.2.6 Receipt of SIP 3xx response............................17 89 8.2.2.2.7 Receipt of a SIP 484 (Address Incomplete) response.....17 90 8.2.2.2.8 Receipt of a SIP 4xx (except 484), 5xx or 6xx response.18 91 8.2.2.2.9 Receipt of multiple SIP responses......................18 92 8.2.2.2.10 Cancelling pending SIP INVITE transactions............18 93 8.2.2.2.11 SIP INVITE requests reaching multiple gateways........19 94 8.2.2.2.12 QSIG timer T302 expiry................................19 95 8.3 Call Establishment from SIP to QSIG..........................19 96 8.3.1 Receipt of SIP INVITE request for a new call...............19 97 8.3.2 Receipt of QSIG CALL PROCEEDING message....................20 98 8.3.3 Receipt of QSIG PROGRESS message...........................20 99 8.3.4 Receipt of QSIG ALERTING message...........................21 100 8.3.5 Inclusion of SDP information in a SIP 18x provisional response 101 .................................................................22 102 8.3.6 Receipt of QSIG CONNECT message............................22 103 8.3.7 Receipt of SIP PRACK request...............................23 104 8.3.8 Receipt of SIP ACK request.................................24 105 8.3.9 Receipt of a SIP INVITE request for a call already being 106 established......................................................24 107 8.4 Call clearing and call failure...............................24 108 8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE 109 message..........................................................24 110 8.4.2 Receipt of a SIP BYE request...............................27 111 8.4.3 Receipt of a SIP CANCEL request............................27 112 8.4.4 Receipt of a SIP 4xx - 6xx response........................27 113 8.4.5 Gateway-initiated call clearing............................29 114 8.5 Request to change media characteristics......................30 115 9 Number mapping.................................................30 116 9.1 Mapping from QSIG to SIP.....................................30 117 9.1.1 Using information from the QSIG Called party number information 118 element..........................................................31 119 9.1.2 Using information from the QSIG Calling party number 120 information element..............................................31 121 9.1.2.1 No URI derived and presentation indicator does not have value 122 "presentation restricted"........................................31 123 9.1.2.2 No URI derived and presentation indicator has value 124 "presentation restricted"........................................31 125 9.1.2.3 URI derived and presentation indicator has value 126 "presentation restricted"........................................31 127 9.1.2.4 URI derived and presentation indicator does not have value 128 "presentation restricted"........................................32 129 9.1.3 Using information from the QSIG Connected number information 130 element..........................................................32 131 9.1.3.1 No URI derived and presentation indicator does not have value 132 "presentation restricted"........................................32 133 9.1.3.2 No URI derived and presentation indicator has value 134 "presentation restricted"........................................32 135 9.1.3.3 URI derived and presentation indicator has value 136 "presentation restricted"........................................32 137 9.1.3.4 URI derived and presentation indicator does not have value 138 "presentation restricted"........................................33 139 9.2 Mapping from SIP to QSIG.....................................33 140 9.2.1 Generating the QSIG Called party number information element33 141 9.2.2 Generating the QSIG Calling party number information element34 142 9.2.3 Generating the QSIG Connected number information element...34 143 10 Requirements for support of basic services....................35 144 10.1 Derivation of QSIG Bearer capability information element....35 145 10.2 Derivation of media type in SDP.............................36 146 11 Security considerations.......................................36 147 12 Author's Addresses............................................39 148 13 Normative References..........................................39 149 Annex A � Example message sequences..............................41 150 Annex B � Change log.............................................54 152 1 Introduction 154 This document specifies signalling interworking between "QSIG" and 155 the Session Initiation Protocol (SIP) in support of basic services 156 within a corporate telecommunication network (CN). 158 "QSIG" is a signalling protocol that operates between Private 159 Integrated Services eXchanges (PINX) within a Private Integrated 160 Services Network (PISN). A PISN provides circuit-switched basic 161 services and supplementary services to its users. QSIG is specified 162 in ECMA Standards, in particular ECMA-143 (call control in support of 163 basic services), ECMA-165 (generic functional protocol for the 164 support of supplementary services) and a number of Standards 165 specifying individual supplementary services. 167 SIP is an application layer protocol for establishing, terminating 168 and modifying multimedia sessions. It is typically carried over IP 169 [16], [17]. Telephone calls are considered as a type of multimedia 170 session where just audio is exchanged. SIP is defined in RFC 3261 171 [10]. 173 This document specifies signalling interworking for basic services 174 that provide a bi-directional transfer capability for speech, DTMF, 175 facsimile and modem media between a PISN employing QSIG and a 176 corporate IP network employing SIP. Call-related and call-independent 177 signalling in support of supplementary services is outside the scope 178 of this specification, but support for certain supplementary services 179 (e.g., call transfer, call diversion) could be the subject of future 180 work. 182 Interworking between QSIG and SIP permits a call originating at a 183 user of a PISN to terminate at a user of a corporate IP network, or a 184 call originating at a user of a corporate IP network to terminate at 185 a user of a PISN. 187 Interworking between a PISN employing QSIG and a public IP network 188 employing SIP is outside the scope of this specification. However, 189 the functionality specified in this specification is in principle 190 applicable to such a scenario when deployed in conjunction with other 191 relevant functionality (e.g., number translation, security functions, 192 etc.). 194 This specification is applicable to any interworking unit that can 195 act as a gateway between a PISN employing QSIG and a corporate IP 196 network employing SIP. 198 2 Terminology 200 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 201 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 202 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 203 indicate requirement levels for compliant SIP implementations. 205 3 Definitions 207 For the purposes of this specification, the following definitions 208 apply. 210 3.1 External definitions 212 This specification uses the following terms defined in other 213 documents: 215 -Call (ECMA-307) 216 -Corporate telecommunication network (CN) (ECMA-307) 217 -Private Integrated Services Network (PISN) (ECMA-307) 218 -Private Integrated services Network eXchange (PINX) (ECMA-133) 220 Additionally the definitions in ECMA-143 and RFC 3261 apply as 221 appropriate. 223 3.2 Other definitions 225 3.2.1 Gateway 227 An entity that performs interworking between a PISN using QSIG and an 228 IP network using SIP. 230 3.2.2 IP network 232 A network, unless otherwise stated a corporate network, offering 233 connectionless packet-mode services based on the Internet Protocol 234 (IP) as the network layer protocol. 236 3.2.3 Media stream 238 Audio or other user information transmitted in UDP packets, typically 239 containing RTP, in a single direction between the gateway and a peer 240 entity participating in a session established using SIP. 242 NOTE. Normally a SIP session establishes a pair of media streams, one 243 in each direction. 245 4 Acronyms 247 DNS Domain Name Service 248 IP Internet Protocol 249 PINX Private Integrated services Network eXchange 250 PISN Private Integrated Services Network 251 RTP Real-time Transport Protocol 252 SCTP Stream Control Transmission Protocol 253 SDP Session Description Protocol 254 SIP Session Initiation Protocol 255 TCP Transmission Control Protocol 256 TLS Transport Layer Security 257 TU Transaction User 258 UA User Agent 259 UAC User Agent Client 260 UAS User Agent Server 261 UDP User Datagram Protocol 263 5 Background and architecture 265 During the 1980s, corporate voice telecommunications adopted 266 technology similar in principle to Integrated Services Digital 267 Networks (ISDN). Digital circuit switches, commonly known as Private 268 Branch eXchanges (PBX) or more formally as Private Integrated 269 services Network eXchanges (PINX) have been interconnected by digital 270 transmission systems to form Private Integrated Services Networks 271 (PISN). These digital transmission systems carry voice or other 272 payload in fixed rate channels, typically 64 Kbit/s, and signalling 273 in a separate channel. A technique known as common channel signalling 274 is employed, whereby a single signalling channel potentially controls 275 a number of payload channels or bearer channels. A typical 276 arrangement is a point-to-point transmission facility at T1 or E1 277 rate providing a 64 Kbit/s signalling channel and 24 or 30 bearer 278 channels respectively. Other arrangements are possible and have been 279 deployed, including the use of multiple transmission facilities for a 280 signalling channel and its logically associated bearer channels. Also 281 arrangements involving bearer channels at sub-64 Kbit/s have been 282 deployed, where voice payload requires the use of codecs that perform 283 compression. 285 QSIG is the internationally-standardized message-based signalling 286 protocol for use in networks as described above. It runs in a 287 signalling channel between two PINXs and controls calls on a number 288 of logically associated bearer channels between the same two PINXs. 289 The signalling channel and its logically associated bearer channels 290 are collectively known as an inter-PINX link. QSIG is independent of 291 the type of transmission capabilities over which the signalling 292 channel and bearer channels are provided. QSIG is also independent of 293 the transport protocol used to transport QSIG messages reliably over 294 the signalling channel. 296 QSIG provides a means for establishing and clearing calls that 297 originate and terminate on different PINXs. A call can be routed over 298 a single inter-PINX link connecting the originating and terminating 299 PINX, or over several inter-PINX links in series with switching at 300 intermediate PINXs known as transit PINXs. A call can originate or 301 terminate in another network, in which case it enters or leaves the 302 PISN environment through a gateway PINX. Parties are identified by 303 numbers, in accordance with either ITU-T recommendation E.164 [18] or 304 a private numbering plan. This basic call capability is specified in 305 ECMA-143. In addition to basic call capability, QSIG specifies a 306 number of further capabilities supporting the use of supplementary 307 services in PISNs. 309 More recently corporate telecommunications networks have started to 310 exploit IP in various ways. One way is to migrate part of the network 311 to IP using SIP. This might, for example, be a new branch office with 312 a SIP proxy and SIP endpoints instead of a PINX. Alternatively, SIP 313 equipment might be used to replace an existing PINX or PINXs. The new 314 SIP environment needs to interwork with the QSIG-based PISN in order 315 to support calls originating in one environment and terminating in 316 the other. Interworking is achieved through a gateway. 318 Another way of migrating is to use a SIP network to interconnect two 319 parts of a PISN and encapsulate QSIG signalling in SIP messages for 320 calls between the two parts of the PISN. This is outside the scope of 321 this specification but could be the subject of future work. 323 This document specifies signalling protocol interworking aspects of a 324 gateway between a PISN employing QSIG signalling and an IP network 325 employing SIP signalling. The gateway appears as a PINX to other 326 PINXs in the PISN. The gateway appears as a SIP endpoint to other SIP 327 entities in the IP network. The environment is shown in figure 1. 329 +------+ IP network PISN 330 | | 331 |SIP | +------+ 332 |Proxy | /| | 333 | | / |PINX | 334 +---+--+ *-----------+ / | | 335 | | | +-----+/ +------+ 336 | | | | | 337 | | | |PINX | 338 ---+-----+-------+--------+ Gateway +--------| | 339 | | | | | |\ 340 | | | | +-----+ \ 341 | | | | \ +------+ 342 | | | | \| | 343 +--+---+ +--+---+ *-----------+ |PINX | 344 |SIP | |SIP | | | 345 |End- | |End- | +------+ 346 |point | |point | 347 +------+ +------+ 349 Figure 1 � Environment 351 In addition to the signalling interworking functionality specified in 352 this specification, it is assumed that the gateway also includes the 353 following functionality: 355 -one or more physical interfaces on the PISN side supporting one or 356 more inter-PINX links, each link providing one or more constant bit 357 rate channels for media information and a reliable layer 2 connection 358 (e.g., over a fixed rate physical channel) for transporting QSIG 359 signalling messages; and 361 -one or more physical interfaces on the IP network side supporting, 362 through layer 1 and layer 2 protocols, IP as the network layer 363 protocol and UDP (RFC 768) and TCP (RFC 761) as transport layer 364 protocols, these being used for the transport of SIP signalling 365 messages and, in the case of UDP, also for media information; 367 -optionally the support of TLS (RFC 2246) and/or SCTP (RFC 2960) as 368 additional transport layer protocols on the IP network side, these 369 being used for the transport of SIP signalling messages; and 371 -a means of transferring media information in each direction between 372 the PISN and the IP network, including as a minimum packetization of 373 media information sent to the IP network and de-packetization of 374 media information received from the IP network. 376 NOTE. RFC 3261 mandates support for both UDP and TCP for the 377 transport of SIP messages and allows optional support for TLS and/or 378 SCTP for this same purpose. 380 The protocol model relevant to signalling interworking functionality 381 of a gateway is shown in figure 2. 383 +---------------------------------------------------------+ 384 | Inter-working function | 385 | | 386 +-----------------------+---------+-----------------------+ 387 | | | | 388 | SIP | | | 389 | | | | 390 +-----------------------+ | | 391 | | | | 392 | UDP/TCP/TLS/SCTP | | QSIG | 393 | | | | 394 +-----------------------+ | | 395 | | | | 396 | IP | | | 397 | | | | 398 +-----------------------+ +-----------------------+ 399 | IP network | | PISN | 400 | lower layers | | lower layers | 401 | | | | 402 +-----------------------+ +-----------------------+ 404 Figure 2 � Protocol model 406 In figure 2, the SIP box represents SIP syntax and encoding, the SIP 407 transport layer and the SIP transaction layer. The Interworking 408 function includes SIP Transaction User (TU) functionality. 410 6 Overview 412 The gateway maps received QSIG messages, where appropriate, to SIP 413 messages and vice versa and maintains an association between a QSIG 414 call and a SIP dialog. 416 A call from QSIG to SIP is initiated when a QSIG SETUP message 417 arrives at the gateway. The QSIG SETUP message initiates QSIG call 418 establishment and an initial response message completes negotiation 419 of the bearer channel to be used for that call. The gateway then 420 sends a SIP INVITE request, having translated the QSIG called party 421 number to a URI suitable for inclusion in the Request-URI. The SIP 422 INVITE request and the resulting SIP dialog, if successfully 423 established, are associated with the QSIG call. The SIP 200 OK 424 response is mapped to a QSIG CONNECT message, signifying answer of 425 the call. During establishment, media streams established by SIP and 426 SDP are connected to the bearer channel. 428 A call from SIP to QSIG is initiated when a SIP INVITE request 429 arrives at the gateway. The gateway sends a QSIG SETUP message to 430 initiate QSIG call establishment, having translated the SIP 431 Request-URI to a number suitable for use as the QSIG called party 432 number. The resulting QSIG call is associated with the SIP INVITE 433 request and with the eventual SIP dialog. Receipt of an initial QSIG 434 response message completes negotiation of the bearer channel to be 435 used, allowing media streams established by SIP and SDP to be 436 connected to that bearer channel. The QSIG CONNECT message is mapped 437 to a SIP 200 OK response. 439 Annex A gives examples of typical message sequences that can arise. 441 7 General requirements 443 In order to conform to this specification, a gateway SHALL support 444 QSIG in accordance with ECMA-143 as a gateway and SHALL support SIP 445 in accordance with RFC 3261 as a UA. In particular the gateway SHALL 446 support SIP syntax and encoding, the SIP transport layer and the SIP 447 transaction layer in accordance with RFC 3261. In addition, the 448 gateway SHALL support SIP TU behaviour for a UA in accordance with 449 RFC 3261 except where stated otherwise in this specification. 451 NOTE 1. RFC 3261 mandates that a SIP entity support both UDP and TCP 452 as transport layer protocols for SIP messages. Other transport layer 453 protocols can also be supported. 455 The gateway SHALL also support SIP reliable provisional responses in 456 accordance with RFC 3262 as a UA. 458 NOTE 2. RFC 3262 makes provision for recovering from loss of 459 provisional responses (other than 100) to INVITE requests when using 460 unreliable transport services in the IP network. This is important 461 for ensuring delivery of responses that map to essential QSIG 462 messages. 464 The gateway SHALL support SDP in accordance with RFC 2327 and its use 465 in accordance with the offer / answer model in RFC 3264. 467 Section 9 also specifies optional use of the Privacy header in 468 accordance with RFC AAAA and the P-Asserted-Identity header in 469 accordance with RFC BBBB. 471 The gateway SHALL support calls from QSIG to SIP and calls from SIP 472 to QSIG. 474 SIP methods not defined in RFC 3261, RFC 3262, RFC AAAA or RFC BBBB 475 are outside the scope of this specification but could be the subject 476 of other specifications for interworking with QSIG, e.g., for 477 interworking in support of supplementary services. 479 As a result of DNS look-up by the gateway in order to determine where 480 to send a SIP INVITE request, a number of candidate destinations can 481 be attempted in sequence. The way in which this is handled by the 482 gateway is outside the scope of this specification. However, any 483 behaviour specified in this document on receipt of a SIP final 484 response SHOULD apply only when there are no more candidate 485 destinations to try. 487 8 Message mapping requirements 489 8.1 Message validation and handling of protocol errors 491 The gateway SHALL validate received QSIG messages in accordance with 492 the requirements of ECMA-143 and SHALL act in accordance with 493 ECMA-143 on detection of a QSIG protocol error. The requirements of 494 this section for acting on a received QSIG message apply only to a 495 received QSIG message that has been successfully validated and that 496 satisfies one of the following conditions: 498 -the QSIG message is a SETUP message and indicates a destination in 499 the IP network and a bearer capability for which the gateway is able 500 to provide interworking; or 502 -the QSIG message is a message other than SETUP and contains a call 503 reference that identifies an existing call for which the gateway is 504 providing interworking between QSIG and SIP. 506 The processing of any valid QSIG message that does not satisfy any of 507 these conditions is outside the scope of this specification. 509 If segmented QSIG messages are received, the gateway SHALL await 510 receipt of all segments of a message and SHALL validate and act on 511 the complete reassembled message. 513 The gateway SHALL validate received SIP messages (requests and 514 responses) in accordance with the requirements of RFC 3261 and SHALL 515 act in accordance with RFC 3261 on detection of a SIP protocol error. 516 Requirements of this section for acting on a received SIP message 517 apply only to a received message that has been successfully validated 518 and that satisfies one of the following conditions: 520 -the SIP message is an INVITE request that contains no tag parameter 521 in the To header field, does not match an ongoing transaction (i.e., 522 is not a merged request, see 8.2.2.2 of RFC 3261) and indicates a 523 destination in the PISN for which the gateway is able to provide 524 interworking; or 526 -the SIP message is a request that relates to an existing dialog 527 representing a call for which the gateway is providing interworking 528 between QSIG and SIP; or 530 -the SIP message is a CANCEL request that relates to a received 531 INVITE request for which the gateway is providing interworking with 532 QSIG but for which the only response sent is informational (1xx), no 533 dialog having been confirmed; or 534 -the SIP message is a response to a request sent by the gateway in 535 accordance with this section. 537 The processing of any valid SIP message that does not satisfy any of 538 these conditions is outside the scope of this specification. 540 NOTE. These rules mean that an error detected in a received message 541 will not be propagated to the other side of the gateway. However, 542 there can be an indirect impact on the other side of the gateway, 543 e.g., the initiation of call clearing procedures. 545 The gateway SHALL run QSIG protocol timers as specified in ECMA-143 546 and SHALL act in accordance with ECMA-143 if a QSIG protocol timer 547 expires. Any other action on expiry of a QSIG protocol timer is 548 outside the scope of this specification, except that if it results in 549 the clearing of the QSIG call, the gateway SHALL also clear the SIP 550 call in accordance with 8.4.5. 552 The gateway SHALL run SIP protocol timers as specified in RFC 3261 553 and SHALL act in accordance with RFC 3261 if a SIP protocol timer 554 expires. Any other action on expiry of a SIP protocol timer is 555 outside the scope of this specification, except that if it results in 556 the clearing of the SIP call, the gateway SHALL also clear the QSIG 557 call in accordance with 8.4.5. 559 8.2 Call establishment from QSIG to SIP 560 8.2.1 Call establishment from QSIG to SIP using enbloc procedures 562 The following procedures apply when the gateway receives a QSIG SETUP 563 message containing a Sending Complete information element or the 564 gateway receives a QSIG SETUP message and is able to determine that 565 the number in the Called party number information element is 566 complete. 568 NOTE. The means by which the gateway determines the number to be 569 complete is an implementation matter. It can involve knowledge of the 570 numbering plan and/or use of inter-digit timer expiry. 572 8.2.1.1 Receipt of QSIG SETUP message 574 On receipt of a QSIG SETUP message containing a number that the 575 gateway determines to be complete in the Called party number 576 information element, or containing a Sending complete information 577 element and a number that the gateway cannot determine to be 578 complete, the gateway SHALL map the QSIG SETUP message to a SIP 579 INVITE request. The gateway SHALL also send a QSIG CALL PROCEEDING 580 message. 582 The gateway SHALL generate the SIP Request-URI, To and From fields in 583 the SIP INVITE request in accordance with section 9. The gateway 584 SHALL include in the INVITE request a Supported header containing 585 option tag 100rel, to indicate support for RFC 3262. 587 The gateway SHALL include SDP information in the SIP INVITE request 588 as described in section 10. 590 On receipt of a QSIG SETUP message containing a Sending complete 591 information element and a number that the gateway determines to be 592 incomplete in the Called party number information element, the 593 gateway SHALL initiate QSIG call clearing procedures using cause 594 value 28 �invalid number format (address incomplete)�. 596 If information in the QSIG SETUP message is unsuitable for generating 597 any of the mandatory fields in a SIP INVITE request (e.g., if a 598 Request-URI cannot be derived from the QSIG Called party number 599 information element) or for generating SDP information, the gateway 600 SHALL NOT issue a SIP INVITE request and SHALL initiate QSIG call 601 clearing procedures in accordance with ECMA-143. 603 8.2.1.2 Receipt of SIP 100 (Trying) response 605 A SIP 100 response SHALL NOT trigger any QSIG messages. It only 606 serves the purpose of suppressing INVITE request retransmissions. 608 8.2.1.3 Receipt of SIP 18x provisional response 610 The gateway SHALL map a received SIP 18x response to a QSIG PROGRESS 611 or ALERTING message based on the following conditions. 613 -If a SIP 180 response is received and no QSIG ALERTING message has 614 been sent, the gateway SHALL generate a QSIG ALERTING message. The 615 QSIG ALERTING message SHALL contain a Progress indicator information 616 element containing progress description number 8. If a media stream 617 has been established towards the gateway, the gateway SHALL connect 618 the media stream to the corresponding user information channel of the 619 inter-PINX link. If no media stream has been established towards the 620 gateway, the gateway SHALL supply ring-back tone on the user 621 information channel of the inter-PINX link. 623 -If a SIP 181/182/183 response is received, no QSIG ALERTING message 624 has been sent, no QSIG PROGRESS message containing progress 625 description number 8 has been sent and a media stream has been 626 established towards the gateway, the gateway SHALL generate a QSIG 627 PROGRESS message. The QSIG PROGRESS message SHALL contain progress 628 description number 8 in a Progress indicator information element. The 629 gateway SHALL also connect the media streams to the corresponding 630 user information channel of the inter-PINX link. 632 -If a SIP 181/182/183 response is received, no QSIG ALERTING message 633 has been sent, no QSIG PROGRESS message containing progress 634 description number 1 or 8 has been sent and no media stream has been 635 established towards the gateway, the gateway SHALL generate a QSIG 636 PROGRESS message. The QSIG PROGRESS message SHALL contain progress 637 description number 1 in a Progress indicator information element. 639 NOTE 1. This will ensure that QSIG timer T310 is stopped if running 640 at the Originating PINX. 642 NOTE 2. Media streams are established as a result of receiving SDP 643 answer information in a reliable provisional response and can be 644 modified by means of the SIP UPDATE method (RFC 3311, [15]). If a 645 media stream is established towards the gateway, connecting the media 646 stream to the corresponding user information channel on the inter- 647 PINX link will allow the caller to hear in-band tones or 648 announcements. 650 In all other scenarios the gateway SHALL NOT map the SIP 18x response 651 to a QSIG message. 653 If the SIP 18x response contains a Require header with option tag 654 100rel, the gateway SHALL send back a SIP PRACK request in accordance 655 with RFC 3262. 657 8.2.1.4 Receipt of SIP 2xx response 659 If the gateway receives a SIP 200 (OK) response as the first SIP 200 660 response to a SIP INVITE request, the gateway SHALL map the SIP 200 661 (OK) response to a QSIG CONNECT message. The gateway SHALL also send 662 a SIP ACK request to acknowledge the 200 (OK) response. The gateway 663 SHALL NOT include any SDP information in the SIP ACK request. If the 664 gateway receives further 200 (OK) responses, it SHALL respond to each 665 in accordance with RFC 3261 and SHALL NOT generate any further QSIG 666 messages. 668 Media streams will normally have been established in the IP network 669 in each direction. If so, the gateway SHALL connect the media streams 670 to the corresponding user-information channel on the inter-PINX link 671 if it has not already done so and stop any local ring-back tone. 673 If the SIP 200 (OK) response is received in response to the SIP PRACK 674 request, the gateway SHALL NOT map this message to any QSIG message. 676 If the gateway receives a SIP 2xx response other than 200 (OK), the 677 gateway SHALL send a SIP ACK request. 679 NOTE. A SIP 200 (OK) response can be received later as a result of a 680 forking proxy. 682 8.2.1.5 Receipt of SIP 3xx response 684 On receipt of a SIP 3xx response, the gateway SHALL act in accordance 685 with RFC 3261. 687 NOTE. This will normally result in sending a new SIP INVITE request. 689 Unless the gateway supports the QSIG Call Diversion Supplementary 690 Service, no QSIG message SHALL be sent. The definition of Call 691 Diversion Supplementary Service for QSIG to SIP interworking is 692 beyond the scope of this specification. 694 8.2.2 Call establishment from QSIG to SIP using overlap procedures 696 SIP uses en-bloc signalling and it is strongly RECOMMENDED to avoid 697 using overlap signalling in a SIP network. A SIP/QSIG gateway dealing 698 with overlap signalling, SHOULD perform a conversion from overlap to 699 en-bloc signalling method using one or more of the following 700 mechanisms: 702 -timers; 704 -numbering plan information; 706 -the presence of a Sending complete information element in a received 707 QSIG INFORMATION message. 709 If the gateway performs a conversion from overlap to en-bloc 710 signalling in the SIP network then the procedures defined in 8.2.2.1 711 SHALL apply. 713 However, for some applications it might be impossible to avoid using 714 overlap signalling in the SIP network. In this case the procedures 715 defined in 8.2.2.2 SHALL apply. 717 8.2.2.1 Enbloc signalling in SIP network 719 8.2.2.1.1 Receipt of QSIG SETUP message 721 On receipt of a QSIG SETUP message containing no Sending complete 722 information element and a number in the Called party number 723 information element that the gateway cannot determine to be complete, 724 the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start 725 QSIG timer T302 and await further number digits. 727 8.2.2.1.2 Receipt of QSIG INFORMATION message 729 On receipt of each QSIG INFORMATION message containing no Sending 730 complete information element and containing a number that the gateway 731 cannot determine to be complete, QSIG timer T302 SHALL be restarted. 732 When QSIG timer T302 expires or a QSIG INFORMATION message containing 733 a Sending complete information element is received the gateway SHALL 734 send a SIP INVITE request as described in 8.2.1.1. The Request-URI 735 and To fields (see section 9) SHALL be generated from the 736 concatenation of information in the Called party number information 737 element in the received QSIG SETUP and INFORMATION messages. The 738 gateway SHALL also send a QSIG CALL PROCEEDING message. 740 8.2.2.1.3 Receipt of SIP responses 742 SIP responses SHALL be mapped as described in 8.2.1. 744 8.2.2.2 Overlap signalling in SIP network 746 8.2.2.2.1 Receipt of QSIG SETUP message 748 On receipt of a QSIG SETUP message containing no Sending complete 749 information element and a number in the Called party number 750 information element that the gateway cannot determine to be complete, 751 the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message and 752 start QSIG timer T302. If the QSIG SETUP message contains the minimum 753 number of digits required to route the call in the IP network, the 754 gateway SHALL send a SIP INVITE request as specified in 8.2.1.1. 755 Otherwise the gateway SHALL wait for more digits to arrive in QSIG 756 INFORMATION messages. 758 8.2.2.2.2 Receipt of QSIG INFORMATION message 760 On receipt of a QSIG INFORMATION message the gateway SHALL handle the 761 QSIG timer T302 in accordance with ECMA-143. 763 NOTE 1. ECMA-143 requires the QSIG timer to be stopped if the 764 INFORMATION message contains a Sending complete information element 765 or to be restarted otherwise. 767 Further behaviour of the gateway SHALL depend on whether or not it 768 has already sent a SIP INVITE request. If the gateway has not sent a 769 SIP INVITE request and it now has the minimum number of digits 770 required to route the call, it SHALL send a SIP INVITE request as 771 specified in 8.2.2.1.2. If the gateway still does not have the 772 minimum number of digits required than it SHALL wait for more QSIG 773 INFORMATION messages to arrive. 775 If the gateway has already sent one or more SIP INVITE requests, and 776 whether or not final responses to those requests have been received, 777 it SHALL send a new SIP INVITE request with the new digits. The new 778 SIP INVITE request SHALL have the same Call-ID as the first SIP 779 INVITE request sent but SHALL have updated Request-URI and To fields. 780 The updated Request-URI and To fields (see section 9) SHALL be 781 generated from the concatenation of information in the Called party 782 number information element in the received QSIG SETUP and INFORMATION 783 messages. The CSeq header SHOULD contain a value higher than that in 784 the previous SIP INVITE request. 786 NOTE 2. The first SIP INVITE request and all subsequent SIP INVITE 787 requests sent in this way belong to the same call but to different 788 dialogs. 790 8.2.2.2.3 Receipt of SIP 100 (Trying) response 792 The requirements of 8.2.1.2 SHALL apply. 794 8.2.2.2.4 Receipt of SIP 18x provisional response 796 The requirements of 8.2.1.3 SHALL apply. 798 8.2.2.2.5 Receipt of SIP 2xx response 800 The requirements of 8.2.1.4 SHALL apply. In addition the gateway 801 SHALL send a SIP CANCEL request, either immediately or after a short 802 delay, to cancel any SIP INVITE transactions for which no final 803 response has been received. 805 NOTE. Delaying the sending of a SIP CANCEL request allows time for 806 final responses to be received on any outstanding transactions, 807 thereby avoiding unnecessary signalling. 809 8.2.2.2.6 Receipt of SIP 3xx response 811 The requirements of 8.2.1.5 SHALL apply. 813 8.2.2.2.7 Receipt of a SIP 484 (Address Incomplete) response 815 The SIP 484 response indicates that more digits are required to 816 complete the call. On receipt of a SIP 484 response the gateway SHALL 817 send back a SIP ACK request. The gateway SHALL also send a QSIG 818 DISCONNECT message (8.4.4) if no further QSIG INFORMATION messages 819 are expected and final responses have been received to all 820 transmitted SIP INVITE requests. 822 NOTE. Further QSIG INFORMATION messages will not be expected after 823 QSIG timer T302 has expired or after a Sending complete information 824 element has been received. 826 In all other cases the receipt of a SIP 484 response SHALL NOT 827 trigger the sending of any QSIG message. 829 8.2.2.2.8 Receipt of a SIP 4xx (except 484), 5xx or 6xx response 831 If a SIP 4xx (except 484), 5xx or 6xx final response arrives for a 832 pending SIP INVITE transaction, the gateway SHALL send a SIP ACK 833 request. If this occurs when no further QSIG INFORMATION messages are 834 expected and final responses have been received to all transmitted 835 SIP INVITE requests, the gateway SHALL send a QSIG DISCONNECT message 836 (8.4.4). Otherwise the gateway MAY send a QSIG DISCONNECT message. 838 NOTE. The gateway can take account of the SIP response code and other 839 information to assess whether to wait for further responses before 840 initiating clearing. 842 8.2.2.2.9 Receipt of multiple SIP responses 844 The responses to all the SIP INVITE requests sent except for the last 845 one are typically SIP 4xx responses (e.g. 484 (Address Incomplete)) 846 that terminate the SIP INVITE transaction. 848 However, the gateway can receive a SIP 183 (Session Progress) 849 response with a media description. The media stream will typically 850 contain a message such as "�We are trying to connect you� ". The 851 issue of receiving different SIP 183 (Session Progress) responses 852 with media descriptions for different SIP INVITE transactions is a 853 gateway concern. The gateway SHOULD decide which media stream (if 854 any) is to be played to the user. 856 NOTE. The gateway can receive multiple SIP 183 responses with media 857 description not only as a result of sending multiple INVITE requests 858 due to overlap sending but also as a result of a forking proxy. 860 8.2.2.2.10 Cancelling pending SIP INVITE transactions 862 When a gateway sends a new SIP INVITE request containing new digits, 863 it SHOULD NOT send a SIP CANCEL request to cancel a previous SIP 864 INVITE transaction that has not had a final response. This SIP CANCEL 865 request could arrive at an egress gateway before the new SIP INVITE 866 request and trigger premature call clearing. 868 NOTE. Previous SIP INVITE transactions can be expected to result in 869 SIP 4xx class responses, which terminate the transaction. In 870 8.2.2.2.5 there is provision for cancelling any transactions still in 871 progress after a SIP 2xx response has been received. 873 8.2.2.2.11 SIP INVITE requests reaching multiple gateways 875 Each SIP INVITE request sent by a gateway represents a new 876 transaction and hence can be routed differently. For instance, the 877 first SIP INVITE request might be routed to a particular egress 878 gateway and a subsequent SIP INVITE request to another gateway. The 879 result is that both gateways initiate call establishment in the 880 remote network. Since one of the call establishments has an 881 incomplete destination number, it can be expected to fail, having 882 already consumed resources in the remote network. 884 To avoid this problem it is RECOMMENDED that all the SIP INVITE 885 requests should follow the same path as the first one. This would 886 however restrict the number of services the SIP network can provide. 887 It would not be possible to route a subsequent SIP INVITE request to 888 an application server just because the previous one was routed in a 889 different way. 891 This issue should be taken into consideration before using overlap 892 signalling in SIP. If initiating multiple call establishments in the 893 remote network is not acceptable in a particular application, overlap 894 signalling SHOULD NOT be used. 896 8.2.2.2.12 QSIG timer T302 expiry 898 If QSIG timer T302 expires and the gateway has received 4xx, 5xx or 899 6xx responses to all transmitted SIP INVITE requests, the gateway 900 SHALL send a QSIG DISCONNECT message. If T302 expires and the gateway 901 has not received 4xx, 5xx or 6xx responses to all transmitted SIP 902 INVITE requests, the gateway SHALL ignore any further QSIG 903 INFORMATION messages but SHALL NOT send a QSIG DISCONNECT message at 904 this stage. 906 NOTE. A QSIG DISCONNECT request will be sent when all outstanding SIP 907 INVITE requests have received 4xx, 5xx or 6xx responses. 909 8.3 Call Establishment from SIP to QSIG 911 8.3.1 Receipt of SIP INVITE request for a new call 913 On receipt of a SIP INVITE request for a new call, and if a suitable 914 channel is available on the inter-PINX link, the gateway SHALL 915 generate a QSIG SETUP message from the received SIP INVITE request. 916 The gateway SHALL generate the Called party number and Calling party 917 number information elements in accordance with section 9 and SHALL 918 generate the Bearer capability information element in accordance with 919 section 10. If the gateway can determine that the number placed in 920 the Called party number information element is complete, the gateway 921 MAY include the Sending complete information element. 923 NOTE 1. The means by which the gateway determines the number to be 924 complete is an implementation matter. It can involve knowledge of the 925 numbering plan and/or use of the inter-digit timer. 927 The gateway SHOULD send a SIP 100 (Trying) response. 929 If information in the SIP INVITE request is unsuitable for generating 930 any of the mandatory information elements in a QSIG SETUP message 931 (e.g., if a QSIG Called party number information element cannot be 932 derived from SIP Request-URI field) or if no suitable channel is 933 available on the inter-PINX link, the gateway SHALL NOT issue a QSIG 934 SETUP message and SHALL send a SIP 4xx, 5xx or 6xx response. If no 935 suitable channel is available the gateway should use response code 936 503 (Service Unavailable). 938 If the SIP INVITE request does not contain SDP information and does 939 not contain either a Required header or a Supported header with 940 option tag 100rel, the gateway SHALL NOT issue a QSIG SETUP message 941 and SHALL send a SIP 488 (Not Acceptable Here) response. 943 NOTE 2. The absence of SDP offer information in the SIP INVITE 944 request means that the gateway might need to send SDP offer 945 information in a provisional response and receive SDP answer 946 information in a SIP PRACK request (in accordance with RFC 3262) in 947 order to ensure that tones and announcements from the PISN are 948 transmitted. SDP offer information cannot be sent in an unreliable 949 provisional response because SDP answer information would need to be 950 returned in a SIP PRACK request. 952 NOTE 3. If SDP offer information is present in the INVITE request, 953 the issuing of a QSIG SETUP message is not dependent on the presence 954 of a Required header or a Supported header with option tag 100rel. 956 On receipt of a SIP INVITE request relating to a call that has 957 already been established from SIP to QSIG, the procedures of 8.3.9 958 SHALL apply. 960 8.3.2 Receipt of QSIG CALL PROCEEDING message 962 The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any 963 SIP message being sent. 965 8.3.3 Receipt of QSIG PROGRESS message 966 A QSIG PROGRESS message can be received in the event of interworking 967 on the remote side of the PISN or if the PISN is unable to complete 968 the call and generates an in-band tone or announcement. In the latter 969 case a Cause information element is included in the QSIG PROGRESS 970 message. 972 The gateway SHALL map a received QSIG PROGRESS message to a SIP 183 973 (Session Progress) response. If the SIP INVITE request contained 974 either a Require header or a Supported header with option tag 100rel, 975 the gateway SHALL include in the SIP 183 response a Require header 976 with option tag 100rel. 978 NOTE. In accordance with RFC 3262, inclusion of option tag 100rel in 979 a provisional response instructs the UAC to acknowledge the 980 provisional response by sending a PRACK request. RFC 3262 also 981 specifies procedures for repeating a provisional response with option 982 tag 100rel if no PRACK is received. 984 If the QSIG PROGRESS message contained a Progress indicator 985 information element with Progress description number 1 or 8, the 986 gateway SHALL connect the media streams to the corresponding user 987 information channel of the inter-PINX link if it has not already done 988 so, provided SDP answer information is included in the transmitted 989 SIP response or has already been sent or received. Inclusion of SDP 990 offer or answer information in the 183 provisional response SHALL be 991 in accordance with 8.3.5. 993 If the QSIG PROGRESS message is received with a Cause information 994 element, the gateway SHALL either wait until the tone/announcement is 995 complete or has been applied for sufficient time before initiating 996 call clearing, or wait for a SIP CANCEL request. If call clearing is 997 initiated, the cause value in the QSIG PROGRESS message SHALL be used 998 to derive the response to the SIP INVITE request in accordance with 999 table 1. 1001 8.3.4 Receipt of QSIG ALERTING message 1003 The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing) 1004 response. If the SIP INVITE request contained either a Require header 1005 or a Supported header with option tag 100rel, the gateway SHALL 1006 include in the SIP 180 response a Require header with option tag 1007 100rel. 1009 NOTE. In accordance with RFC 3262, inclusion of option tag 100rel in 1010 a provisional response instructs the UAC to acknowledge the 1011 provisional response by sending a PRACK request. RFC 3262 also 1012 specifies procedures for repeating a provisional response with option 1013 tag 100rel if no PRACK is received. 1015 If the QSIG ALERTING message contained a Progress indicator 1016 information element with Progress description number 1 or 8, the 1017 gateway SHALL connect the media streams to the corresponding user 1018 information channel of the inter-PINX link if it has not already done 1019 so, provided SDP answer information is included in the transmitted 1020 SIP response or has already been sent or received. Inclusion of SDP 1021 offer or answer information in the 180 provisional response SHALL be 1022 in accordance with 8.3.5. 1024 8.3.5 Inclusion of SDP information in a SIP 18x provisional response 1026 When sending a SIP 18x provisional response, the gateway SHALL 1027 include SDP information in accordance with the following rules. 1029 If the SIP INVITE request contained a Required or Supported header 1030 with option tag 100rel, and if SDP offer and answer information has 1031 already been exchanged, no SDP information SHALL be included in the 1032 SIP 18x provisional response. 1034 If the SIP INVITE request contained a Required or Supported header 1035 with option tag 100rel, and if SDP offer information was received in 1036 the SIP INVITE request but no SDP answer information has been sent, 1037 SDP answer information SHALL be included in the SIP 18x provisional 1038 response. 1040 If the SIP INVITE request contained a Required or Supported header 1041 with option tag 100rel, and if no SDP offer information was received 1042 in the SIP INVITE request and no SDP offer information has already 1043 been sent, SDP offer information SHALL be included in the SIP 18x 1044 provisional response. 1046 NOTE 1. In this case, SDP answer information can be expected in the 1047 SIP PRACK. 1049 If the SIP INVITE request contained neither a Required nor a 1050 Supported header with option tag 100rel, SDP answer information SHALL 1051 be included in the SIP 18x provisional response. 1053 NOTE 2. Because the provisional response is unreliable, SDP answer 1054 information needs to be repeated in each provisional response and in 1055 the final SIP 2xx response. 1057 NOTE 3. If the SIP INVITE request contained no SDP offer information 1058 and neither a Required nor a Supported header with option tag 100rel, 1059 it should have been rejected in accordance with 8.3.1. 1061 8.3.6 Receipt of QSIG CONNECT message 1062 The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final 1063 response for the SIP INVITE request. The gateway SHALL also send a 1064 QSIG CONNECT ACKNOWLEDGE message. 1066 If the SIP INVITE request contained a Required or Supported header 1067 with option tag 100rel, and if SDP offer and answer information has 1068 already been exchanged, no SDP information SHALL be included in the 1069 SIP 200 response. 1071 If the SIP INVITE request contained a Required or Supported header 1072 with option tag 100rel, and if SDP offer information was received in 1073 the SIP INVITE request but no SDP answer information has been sent, 1074 SDP answer information SHALL be included in the SIP 200 response. 1076 If the SIP INVITE request contained a Required or Supported header 1077 with option tag 100rel, and if no SDP offer information was received 1078 in the SIP INVITE request and no SDP offer information has already 1079 been sent, SDP offer information SHALL be included in the SIP 200 1080 response. 1082 NOTE 1. In this case, SDP answer information can be expected in the 1083 SIP ACK. 1085 If the SIP INVITE request contained neither a Required nor a 1086 Supported header with option tag 100rel, SDP answer information SHALL 1087 be included in the SIP 200 response. 1089 NOTE 2. Because the provisional response is unreliable, SDP answer 1090 information needs to be repeated in each provisional response and in 1091 the final 2xx response. 1093 NOTE 3. If the SIP INVITE request contained no SDP offer information 1094 and neither a Required nor a Supported header with option tag 100rel, 1095 it should have been rejected in accordance with 8.3.1. 1097 The gateway SHALL connect the media streams to the corresponding user 1098 information channel of the inter-PINX link if it has not already done 1099 so, provided SDP answer information is included in the transmitted 1100 SIP response or has already been sent or received. 1102 8.3.7 Receipt of SIP PRACK request 1104 The receipt of a SIP PRACK request acknowledging a reliable 1105 provisional response SHALL NOT result in any QSIG message being sent. 1106 The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK 1107 request. 1109 If the SIP PRACK contains SDP answer information and a QSIG message 1110 containing a Progress indicator information element with progress 1111 description number 1 or 8 has been received, the gateway SHALL 1112 connect the media streams to the corresponding user information 1113 channel of the inter-PINX link. 1115 8.3.8 Receipt of SIP ACK request 1117 The receipt of a SIP ACK request SHALL NOT result in any QSIG message 1118 being sent. 1120 If the SIP ACK contains SDP answer information, the gateway SHALL 1121 connect the media streams to the corresponding user information 1122 channel of the inter-PINX link if it has not already done so. 1124 8.3.9 Receipt of a SIP INVITE request for a call already being 1125 established 1127 For a call from SIP using overlap procedures, the gateway will 1128 receive multiple SIP INVITE requests that belong to the same call but 1129 have different Request-URI and To fields. Each SIP INVITE request 1130 belongs to a different dialog. 1132 If a gateway receives a SIP INVITE request with the same Call-ID as 1133 an existing call for which the QSIG state is overlap sending and with 1134 updated Request-URI and To fields from which a called party number 1135 with a superset of digits can be derived, it SHALL generate a QSIG 1136 INFORMATION message using the call reference of the existing QSIG 1137 call instead of a new QSIG SETUP message. It SHALL also respond to 1138 the SIP INVITE request received previously with a SIP 484 Address 1139 Incomplete response. 1141 If a gateway receives a SIP INVITE request with the same Call-ID as 1142 an existing SIP INVITE request for which the gateway has not yet sent 1143 a final response and failing to meet the other conditions above 1144 concerning overlap sending, the gateway SHALL clear the call by 1145 sending back a SIP 485 (Ambiguous) response and a QSIG DISCONNECT 1146 message with Cause Value 16 (Normal call clearing). 1148 8.4 Call clearing and call failure 1150 8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message 1152 On receipt of QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message as 1153 the first QSIG call clearing message, gateway behaviour SHALL depend 1154 on the state of call establishment. 1156 1)If the gateway has sent a SIP 200 (OK) response and received a SIP 1157 ACK request or has received a SIP 200 (OK) response and sent a SIP 1158 ACK request, the gateway SHALL send a SIP BYE request to clear the 1159 call. 1161 2)If the gateway has sent a SIP 200 (OK) response (indicating that 1162 call establishment is complete) but has not received a SIP ACK 1163 request, the gateway SHALL wait until a SIP ACK is received and then 1164 send a SIP BYE request to clear the call. 1166 3)If the gateway has sent a SIP INVITE request and received a SIP 1167 provisional response but not a SIP final response, the gateway SHALL 1168 send a SIP CANCEL request to clear the call. 1170 NOTE 1. In accordance with RFC 3261, if after sending a SIP CANCEL 1171 request a SIP 2xx response is received to the SIP INVITE request, the 1172 gateway will need to send a SIP BYE request. 1174 4)If the gateway has sent a SIP INVITE request but received no SIP 1175 response, the gateway SHALL NOT send a SIP message. If a SIP final or 1176 provisional response is subsequently received, the gateway SHALL then 1177 act in accordance with 1, 2 or 3 above respectively. 1179 5)If the gateway has received a SIP INVITE request but not sent a SIP 1180 final response, the gateway SHALL send a SIP final response chosen 1181 according to the cause value in the received QSIG message as 1182 specified in table 1. SIP response 500 (Server internal error) SHALL 1183 be used as the default for cause values not shown in table 1. 1185 NOTE 2. It is not necessarily appropriate to map some QSIG cause 1186 values to SIP messages because these cause values are meaningful only 1187 at the gateway. A good example of this is cause value 44 "Requested 1188 circuit or channel not available.", which signifies that the channel 1189 number in the transmitted QSIG SETUP message was not acceptable to 1190 the peer PINX. The appropriate behavior in this case is for the 1191 gateway to send another SETUP message indicating a different channel 1192 number. If this is not possible, the gateway should treat it either 1193 as a congestion situation (no channels available, see 8.3.1) or as a 1194 gateway failure situation (in which case the default SIP response 1195 code applies). 1197 In all cases the gateway SHALL also disconnect media streams, if 1198 established, and allow QSIG and SIP signalling to complete in 1199 accordance with ECMA-143 and RFC-3261 respectively. 1201 Table 1 � Mapping of QSIG Cause Value to SIP 4xx-6xx responses 1203 QSIG Cause value SIP response 1204 1 Unallocated number 404 Not found 1205 2 No route to specified 404 Not found 1206 transit network 1207 3 No route to destination 404 Not found 1208 16 Normal call clearing (NOTE 3) 1209 17 User busy 486 Busy here 1210 18 No user responding 408 Request timeout 1211 19 No answer from the user 480 Temporarily unavailable 1212 20 Subscriber absent 480 Temporarily unavailable 1213 21 Call rejected 603 Decline, if location field 1214 in Cause information element 1215 indicates user. Otherwise: 1216 403 Forbidden 1217 22 Number changed 301 Moved permanently, if 1218 information in diagnostic field 1219 of Cause information element is 1220 suitable for generating a SIP 1221 Contact header. Otherwise: 1222 410 Gone 1223 23 Redirection to new 410 Gone 1224 destination 1225 27 Destination out of order 502 Bad gateway 1226 28 Address incomplete 484 Address incomplete 1227 29 Facility rejected 501 Not implemented 1228 31 Normal, unspecified 480 Temporarily unavailable 1229 34 No circuit/channel 503 Service unavailable 1230 available 1231 38 Network out of order 503 Service unavailable 1232 41 Temporary failure 503 Service unavailable 1233 42 Switching equipment 503 Service unavailable 1234 congestion 1235 47 Resource unavailable, 503 Service unavailable 1236 unspecified 1237 55 Incoming calls barred 403 Forbidden 1238 within CUG 1239 57 Bearer capability not 403 Forbidden 1240 authorized 1241 58 Bearer capability not 503 Service unavailable 1242 presently available 1243 65 Bearer capability not 488 Not acceptable here (NOTE 1244 implemented 4) 1245 69 Requested facility not 501 Not implemented 1246 implemented 1247 70 Only restricted digital 488 Not acceptable here (NOTE 1248 information available 4) 1249 79 Service or option not 501 Not implemented 1250 implemented, unspecified 1251 87 User not member of CUG 403 Forbidden 1252 88 Incompatible destination 503 Service unavailable 1253 102 Recovery on timer expiry 504 Server time-out 1255 NOTE 3. A QSIG call clearing message containing cause value 16 will 1256 normally result in the sending of a SIP BYE or CANCEL request. 1258 However, if a SIP response is to be sent, the default response code 1259 should be used. 1261 NOTE 4. The gateway may include a SIP Warning header if diagnostic 1262 information in the QSIG Cause information element allows a suitable 1263 warning code to be selected. 1265 8.4.2 Receipt of a SIP BYE request 1267 On receipt of a SIP BYE request, the gateway SHALL send a QSIG 1268 DISCONNECT message with cause value 16 (normal call clearing). The 1269 gateway SHALL also disconnect media streams, if established, and 1270 allow QSIG and SIP signalling to complete in accordance with ECMA-143 1271 and RFC-3261 respectively. 1273 NOTE. When responding to a SIP BYE request, in accordance with 1274 RFC 3261 the gateway is also required to respond to any other 1275 outstanding transactions, e.g., with a SIP 487 (Request Terminated) 1276 response. This applies in particular if the gateway has not yet 1277 returned a final response to the SIP INVITE request. 1279 8.4.3 Receipt of a SIP CANCEL request 1281 On receipt of a SIP CANCEL request to clear a call for which the 1282 gateway has not sent a SIP final response to the received SIP INVITE 1283 request, the gateway SHALL send a QSIG DISCONNECT message with cause 1284 value 16 (normal call clearing). The gateway SHALL also disconnect 1285 media streams, if established, and allow QSIG and SIP signalling to 1286 complete in accordance with ECMA-143 and RFC-3261 respectively. 1288 8.4.4 Receipt of a SIP 4xx - 6xx response 1290 Except where otherwise specified in the context of overlap sending 1291 (8.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP 1292 INVITE request, the gateway SHALL transmit a QSIG DISCONNECT message. 1293 The cause value in the QSIG DISCONNECT message SHALL be derived from 1294 the SIP 4xx-6xx response according to table 2. Cause value 31 1295 (Normal, unspecified) SHALL be used as the default for SIP responses 1296 not shown in table 2. The gateway SHALL also disconnect media 1297 streams, if established, and allow QSIG and SIP signalling to 1298 complete in accordance with ECMA-143 and RFC-3261 respectively. 1300 When generating a QSIG Cause information element, the location field 1301 SHOULD contain the value "user" if generated as a result of a SIP 1302 response code 6xx or the value "Private network serving the remote 1303 user" in other circumstances. 1305 Table 2 � Mapping of SIP 4xx-6xx responses to QSIG Cause values 1307 SIP response QSIG Cause value 1308 400 Bad request 41 Temporary failure 1309 401 Unauthorized 21 Call rejected (NOTE 1) 1310 402 Payment required 21 Call rejected 1311 403 Forbidden 21 (Call rejected) 1312 404 Not found 1 (Unallocated number) 1313 405 Method not allowed 63 Service or option 1314 unavailable, unspecified 1315 406 Not acceptable 79 Service or option not 1316 implemented, unspecified 1317 407 Proxy Authentication required 21 Call rejected (NOTE 1) 1318 408 Request timeout 102 Recovery on timer expiry 1319 410 Gone 22 Number changed 1320 413 Request entity too large 127 Interworking, unspecified 1321 (NOTE 2) 1322 414 Request-URI too long 127 Interworking, unspecified 1323 (NOTE 2) 1324 415 Unsupported media type 79 Service or option not 1325 implemented, unspecified (NOTE 1326 2) 1327 416 Unsupported URI scheme 127 Interworking, unspecified 1328 (NOTE 2) 1329 420 Bad extension 127 Interworking, unspecified 1330 (NOTE 2) 1331 421 Extension required 127 Interworking, unspecified 1332 (NOTE 2) 1333 423 Interval too brief 127 Interworking, unspecified 1334 (NOTE 2) 1335 480 Temporarily unavailable 18 No user responding 1336 481 Call/transaction does not exist 41 Temporary failure 1337 482 Loop detected 25 Exchange routing error 1338 483 Too many hops 25 Exchange routing error 1339 484 Address incomplete 28 Invalid number format (NOTE 1340 2) 1341 485 Ambiguous 1 Unallocated Number 1342 486 Busy here 17 User busy 1343 487 Request terminated (NOTE 3) 1344 488 Not Acceptable Here 65 Bearer capability not 1345 implemented or 31 Normal, 1346 unspecified(NOTE 4) 1347 500 Server internal error 41 Temporary failure 1348 501 Not implemented 79 Service or option not 1349 implemented, unspecified 1350 502 Bad gateway 38 Network out of order 1351 503 Service unavailable 41 Temporary failure 1352 504 Gateway time-out 102 Recovery on timer expiry 1353 505 Version not supported 127 Interworking, unspecified 1354 (NOTE 2) 1355 513 Message too large 127 Interworking, unspecified 1356 (NOTE 2) 1357 600 Busy everywhere 17 User busy 1358 603 Decline 21 Call rejected 1359 604 Does not exist anywhere 1 Unallocated number 1360 606 Not acceptable 65 Bearer capability not 1361 implemented or 1362 31 Normal, unspecified(NOTE 4) 1364 NOTE 1. In some cases, it may be possible for the gateway to provide 1365 credentials to the SIP UAS that is rejecting an INVITE due to 1366 authorization failure. If the gateway can authenticate itself, then 1367 obviously it should do so and proceed with the call. Only if the 1368 gateway cannot authorize itself should the gateway clear the call in 1369 the QSIG network with this cause value. 1371 NOTE 2. If at all possible, the gateway should respond to these 1372 protocol errors by remedying unacceptable behavior and attempting to 1373 re-originate the session. Only if this proves impossible should the 1374 gateway clear the call in the QSIG network with this cause value. 1376 NOTE 3. The circumstances in which SIP response code 487 can be 1377 expected to arise do not require it to be mapped to a QSIG cause 1378 code, since the QSIG call will normally already be cleared or in the 1379 process of clearing. If QSIG call clearing does, however, need to be 1380 initiated, the default cause value should be used. 1382 NOTE 4. When the Warning header is present in a SIP 606 or 488 1383 message, the warning code should be examined to determine whether it 1384 is reasonable to generate cause value 65. This cause value should be 1385 generated only if there is a chance that a new call attempt with 1386 different content in the Bearer capability information element will 1387 avoid the problem. In other circumstances the default cause value 1388 should be used. 1390 8.4.5 Gateway-initiated call clearing 1392 If the gateway initiates clearing of the QSIG call owing to QSIG 1393 timer expiry, QSIG protocol error or use of the QSIG RESTART message 1394 in accordance with ECMA-143, the gateway SHALL also initiate clearing 1395 of the SIP call in accordance with 8.4.1. If this involves the 1396 sending of a final response to a SIP INVITE request, the gateway 1397 SHALL use response code 480 (Temporarily Unavailable) if optional 1398 QSIG timer T301 has expired or otherwise response code 408 (Request 1399 timeout) or 500 (Server internal error) as appropriate. 1401 If the gateway initiates clearing of the SIP call owing to SIP timer 1402 expiry or SIP protocol error in accordance with RFC 3261, the gateway 1403 SHALL also initiate clearing of the QSIG call in accordance with 1404 ECMA-143 using cause value 102 (Recovery on timer expiry) or 41 1405 (Temporary failure) as appropriate. 1407 8.5 Request to change media characteristics 1409 If after a call has been successfully established the gateway 1410 receives a SIP INVITE request to change the media characteristics of 1411 the call in a way that would be incompatible with the bearer 1412 capability in use within the PISN, the gateway SHALL send back a SIP 1413 503 (Service unavailable) response and SHALL NOT change the media 1414 characteristics of the existing call. 1416 9 Number mapping 1418 In QSIG, users are identified by numbers, as defined in ECMA-155 1419 [19]. Numbers are conveyed within the Called party number, Calling 1420 party number and Connected number information elements. The Calling 1421 party number and Connected number information elements also contain a 1422 presentation indicator, which can indicate that privacy is required 1423 (presentation restricted) and a screening indicator that indicates 1424 the source and authentication status of the number. 1426 In SIP, users are identified by Universal Resource Identifiers (URIs) 1427 conveyed within the Request-URI and various headers, including the 1428 From and To headers specified in RFC 3261 and the P-Asserted-Identity 1429 header specified in RFC BBBB [14]. In addition, privacy is indicated 1430 by the Privacy header specified in RFC AAAA [13]. 1432 This clause specifies the mapping between QSIG Called party number, 1433 Calling party number and Connected number information elements and 1434 corresponding elements in SIP. 1436 A gateway MAY implement the P-Asserted-Identity header in accordance 1437 with RFC BBBB [14]. If a gateway implements the P-Asserted-Identity 1438 header it SHALL also implement the Privacy header in accordance with 1439 RFC AAAA [13]. If a gateway does not implement the 1440 P-Asserted-Identity header it MAY implement the Privacy header. 1442 9.1 Mapping from QSIG to SIP 1444 The method used to convert a number to a URI is outside the scope of 1445 this specification. However, the gateway SHOULD take account of the 1446 Numbering Plan (NPI) and Type Of Number (TON) fields in the QSIG 1447 information element concerned when interpreting a number. 1449 Some aspects of mapping depend on whether the gateway trusts the 1450 adjacent proxy (i.e., the proxy to which the INVITE request is sent 1451 or from which INVITE request is received) to honour requests for 1452 identity privacy in the Privacy header. This will be network- 1453 dependent and it is RECOMMENDED that gateways supporting the 1454 P-Asserted-Identity header be configurable to either trust or not 1455 trust the proxy in this respect. 1457 9.1.1 Using information from the QSIG Called party number information 1458 element 1460 When mapping a QSIG SETUP message to a SIP INVITE request, the 1461 gateway SHALL convert the number in the QSIG Called party number 1462 information to a URI and include that URI in the SIP Request-URI and 1463 in the To header. 1465 9.1.2 Using information from the QSIG Calling party number information 1466 element 1468 When mapping a QSIG SETUP message to a SIP INVITE request, the 1469 gateway SHALL use the Calling party number information element, if 1470 present, as follows. 1472 If the information element contains a number, the gateway SHALL 1473 attempt to derive a URI from that number. Further behaviour depends 1474 on whether a URI has been derived and the value of the presentation 1475 indication. 1477 9.1.2.1 No URI derived and presentation indicator does not have value 1478 "presentation restricted" 1480 In this case (including the case where the Calling party number 1481 information element is absent) the gateway SHALL NOT generate a 1482 P-Asserted-Identity header, SHALL NOT generate a Privacy header and 1483 SHALL include a URI identifying the gateway in the From header. 1485 9.1.2.2 No URI derived and presentation indicator has value 1486 "presentation restricted" 1488 In this case the gateway SHALL NOT generate a P-Asserted-Identity 1489 header, SHALL generate a Privacy header with parameter priv-value = 1490 "id" if the gateway supports this header, and SHALL generate an 1491 anonymous From header. The inclusion of additional values of the 1492 priv-value parameter in the Privacy header is outside the scope of 1493 this specification. 1495 9.1.2.3 URI derived and presentation indicator has value "presentation 1496 restricted" 1498 If the gateway supports the P-Asserted-Identity header and trusts the 1499 proxy to honour the Privacy header, the gateway SHALL generate a 1500 P-Asserted-Identity header containing the derived URI, SHALL generate 1501 a Privacy header with parameter priv-value = "id" and SHALL generate 1502 an anonymous From header. The inclusion of additional values of the 1503 priv-value parameter in the Privacy header is outside the scope of 1504 this specification. 1506 If the gateway does not support the P-Asserted-Identity header or 1507 does not trust the proxy to honour the Privacy header, the gateway 1508 SHALL behave as in 9.1.2.2. 1510 9.1.2.4 URI derived and presentation indicator does not have value 1511 "presentation restricted" 1513 In this case the gateway SHALL generate a P-Asserted-Identity header 1514 containing the derived URI if the gateway supports this header, SHALL 1515 NOT generate a Privacy header and SHALL include the derived URI in 1516 the From header. 1518 9.1.3 Using information from the QSIG Connected number information 1519 element 1521 When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an 1522 INVITE request, the gateway SHALL use the Connected number 1523 information element, if present, as follows. 1525 If the information element contains a number, the gateway SHALL 1526 attempt to derive a URI from that number. Further behaviour depends 1527 on whether a URI has been derived and the value of the presentation 1528 indication. 1530 9.1.3.1 No URI derived and presentation indicator does not have value 1531 "presentation restricted" 1533 In this case (including the case where the Connected number 1534 information element is absent) the gateway SHALL NOT generate a 1535 P-Asserted-Identity header and SHALL NOT generate a Privacy header. 1537 9.1.3.2 No URI derived and presentation indicator has value 1538 "presentation restricted" 1540 In this case the gateway SHALL NOT generate a P-Asserted-Identity 1541 header and SHALL generate a Privacy header with parameter priv-value 1542 = "id" if the gateway supports this header. The inclusion of 1543 additional values of the priv-value parameter in the Privacy header 1544 is outside the scope of this specification. 1546 9.1.3.3 URI derived and presentation indicator has value "presentation 1547 restricted" 1549 If the gateway supports the P-Asserted-Identity header and trusts the 1550 proxy to honour the Privacy header, the gateway SHALL generate a 1551 P-Asserted-Identity header containing the derived URI and SHALL 1552 generate a Privacy header with parameter priv-value = "id". The 1553 inclusion of additional values of the priv-value parameter in the 1554 Privacy header is outside the scope of this specification. 1556 If the gateway does not support the P-Asserted-Identity header or 1557 does not trust the proxy to honour the Privacy header, the gateway 1558 SHALL behave as in 9.1.3.2. 1560 9.1.3.4 URI derived and presentation indicator does not have value 1561 "presentation restricted" 1563 In this case the gateway SHALL generate a P-Asserted-Identity header 1564 containing the derived URI if the gateway supports this header and 1565 SHALL NOT generate a Privacy header. 1567 9.2 Mapping from SIP to QSIG 1569 The method used to convert a URI to a number is outside the scope of 1570 this specification. However, NPI and TON fields in the QSIG 1571 information element concerned SHALL be set to appropriate values in 1572 accordance with ECMA-155. 1574 Some aspects of mapping depend on whether the gateway trusts the 1575 adjacent proxy (i.e., the proxy to which the INVITE request is sent 1576 or from which INVITE request is received) to provide accurate 1577 information in the P-Asserted-Identity header. This will be network- 1578 dependent and it is RECOMMENDED that gateways be configurable to 1579 either trust or not trust the proxy in this respect. 1581 Some aspects of mapping depend on whether the gateway is prepared to 1582 use a URI in the From header to derive a number for the Calling party 1583 number information element. The default behaviour SHOULD be not to 1584 use the From header for this purpose, since in principle the 1585 information comes from an untrusted source (the remote UA). However, 1586 it is recognised that some network administrations may consider that 1587 the benefits to be derived from supplying a calling party number 1588 outweigh any risks of supplying false information. Therefore a 1589 gateway MAY be configurable to use the From header for this purpose. 1591 9.2.1 Generating the QSIG Called party number information element 1593 When mapping a SIP INVITE request to a QSIG SETUP message, the 1594 gateway SHALL convert the URI in the SIP Request-URI to a number and 1595 include that number in the QSIG Called party number information 1596 element. 1598 NOTE. The To header should not be used for this purpose. This is 1599 because re-targeting of the request in the SIP network can change the 1600 Request-URI but leave the To header unchanged. It is important that 1601 routing in the QSIG network be based on the final target from the SIP 1602 network. 1604 9.2.2 Generating the QSIG Calling party number information element 1606 When mapping a SIP INVITE request to a QSIG SETUP message, the 1607 gateway SHALL generate a Calling party number information element as 1608 follows. 1610 If the SIP INVITE request contains a P-Asserted-Identity header and 1611 the gateway supports that header and trusts the information therein, 1612 the gateway SHALL attempt to derive a number from the URI in that 1613 header. If a number is derived from the P-Asserted-Identity header, 1614 the gateway SHALL include it in the Calling party number information 1615 element and include value "network provided" in the screening 1616 indicator. 1618 If no number is derivable from a P-Asserted-Identity header 1619 (including the case where there is no P-Asserted-Identity header) and 1620 if the gateway is prepared to use the From header, the gateway SHALL 1621 attempt to derive a number from the URI in the From header. If a 1622 number is derived from the From header, the gateway SHALL include it 1623 in the Calling party number information element and include value 1624 "user provided, not screened" in the screening indicator. 1626 If no number is derivable, the gateway SHALL NOT include a number in 1627 the Calling party number information element. 1629 If the SIP INVITE request contains a Privacy header with value "id" 1630 in parameter priv-value and the gateway supports this header, the 1631 gateway SHALL include value "presentation restricted" in the 1632 presentation indicator. Otherwise the gateway SHALL include value 1633 "presentation allowed" if a number is present or "not available due 1634 to interworking" if no number is present. 1636 If the resulting Calling party number information element contains no 1637 number and value "not available due to interworking" in the 1638 presentation indicator, the gateway MAY omit the information element 1639 from the QSIG SETUP message. 1641 9.2.3 Generating the QSIG Connected number information element 1643 When mapping a SIP 200 (OK) response to an INVITE request to a QSIG 1644 CONNECT message, the gateway SHALL generate a Connected number 1645 information element as follows. 1647 If the SIP 200 (OK) response contains a P-Asserted-Identity header 1648 and the gateway supports that header and trusts the information 1649 therein, the gateway SHALL attempt to derive a number from the URI in 1650 that header. If a number is derived from the P-Asserted-Identity 1651 header, the gateway SHALL include it in the Connected number 1652 information element and include value "network provided" in the 1653 screening indicator. 1655 If no number is derivable (including the case where there is no 1656 P-Asserted-Identity header), the gateway SHALL NOT include a number 1657 in the Connected number information element. 1659 If the SIP 200 (OK) response contains a Privacy header with value 1660 "id" in parameter priv-value and the gateway supports this header, 1661 the gateway SHALL include value "presentation restricted" in the 1662 presentation indicator. Otherwise the gateway SHALL include value 1663 "presentation allowed" if a number is present or "not available due 1664 to interworking" if no number is present. 1666 If the resulting Connected number information element contains no 1667 number and value "not available due to interworking" in the 1668 presentation indicator, the gateway MAY omit the information element 1669 from the QSIG CONNECT message. 1671 10 Requirements for support of basic services 1673 This document specifies signalling interworking for basic services 1674 that provide a bi-directional transfer capability for speech, 1675 facsimile and modem media between the two networks. 1677 10.1 Derivation of QSIG Bearer capability information element 1679 The gateway SHALL generate the Bearer Capability Information Element 1680 in the QSIG SETUP message based on SDP information received along 1681 with the SIP INVITE request. If the SIP INVITE request does not 1682 contain SDP information or the media type in the SDP information is 1683 only �audio� then the Bearer capability information element SHALL BE 1684 generated according to table 3. Coding of the Bearer capability 1685 information element for other media types is outside the scope of 1686 this specification. 1688 Table 3 � Bearer capability encoding for �audio� transfer 1690 Field Value 1691 Coding Standard "CCITT standardized coding" (00) 1692 Information transfer "3,1 kHz audio" (10000) 1693 capability 1694 Transfer mode "circuit mode" (00) 1695 Information transfer rate "64 Kbits/s" (10000) 1696 Multiplier Octet omitted 1697 User information layer 1 Generated by gateway based on 1698 protocol information of the PISN. Supported 1699 values are 1700 "CCITT recommendation G.711 @-law" 1701 (00010) 1702 "CCITT recommendation G.711 A-law" 1703 (00011) 1705 10.2 Derivation of media type in SDP 1707 The gateway SHALL generate SDP information to include in the SIP 1708 INVITE request based on the Bearer capability information element 1709 received in the QSIG SETUP message. The media type included in the 1710 SDP information SHALL be according to table 4. 1712 Table 4 � Media type setting in SDP based on Bearer capability 1713 information element 1715 Information transfer capability in Media type in SDP 1716 Bearer capability information element 1718 "speech" (00000) audio 1719 "3,1 kHz audio" (10000) audio 1720 "unrestricted digital information" (01000) data 1722 11 Security considerations 1724 The translation of QSIG information elements into SIP headers can 1725 introduce some privacy and security concerns. For example, care needs 1726 to be taken to provide adequate privacy for a user requesting 1727 presentation restriction if the Calling party number information 1728 element is openly mapped to the From header. Procedures for dealing 1729 with this particular situation are specified in 9.1.2. However, 1730 since the mapping specified in this document is mainly concerned with 1731 translating information elements into the headers and fields used to 1732 route SIP requests, gateways consequently reveal (through this 1733 translation process) the minimum possible amount of information. 1735 In most respects, the information that is translated from QSIG to SIP 1736 has no special security requirements. In order for translated 1737 information elements to be used to route requests, they should be 1738 legible to intermediaries; end-to-end confidentiality of this data 1739 would be unnecessary and most likely detrimental. There are also 1740 numerous circumstances under which intermediaries can legitimately 1741 overwrite the values that have been provided by translation, and 1742 hence integrity over these headers is similarly not desirable. 1744 There are some concerns, however, that arise from the other direction 1745 of mapping, the mapping of SIP headers to QSIG information elements, 1746 which are enumerated in the following paragraphs. When end users 1747 dial numbers in a PISN, their selections populate the Called party 1748 number information element in the QSIG SETUP message. Similarly, the 1749 SIP URI or tel URL and its optional parameters in the Request-URI of 1750 a SIP INVITE request, which can be created directly by end users of a 1751 SIP device, map to that information element at a gateway. However, 1752 in a PISN, policy can prevent the user from dialing certain (invalid 1753 or restricted) numbers. Thus, gateway implementers may wish to 1754 provide a means for gateway administrators to apply policies 1755 restricting the use of certain SIP URIs or tel URLs, or SIP URI or 1756 tel URL parameters, when authorizing a call from SIP to QSIG. 1758 Some additional risks may result from the SIP response code to QSIG 1759 cause value mapping. SIP user agents could conceivably respond to an 1760 INVITE request from a gateway with any arbitrary SIP response code, 1761 and thus they can dictate (within the boundaries of the mappings 1762 supported by the gateway) the Q.850 cause code that will be sent by 1763 the gateway in the resulting QSIG call clearing message. Generally 1764 speaking, the manner in which a call is rejected is unlikely to 1765 provide any avenue for fraud or denial of service (e.g., by 1766 signalling that a call should not be billed, or that the network 1767 should take critical resources off-line). However, gateway 1768 implementers may wish to make provision for gateway administrators to 1769 modify the response code to cause value mappings to avoid any 1770 undesirable network-specific behaviour resulting from the mappings 1771 recommended in 8.4.4. 1773 This specification requires the gateway to map the Request-URI rather 1774 than the To header in a SIP INVITE request to the Called party number 1775 information element in a QSIG SETUP message. Although a SIP UA is 1776 expected to put the same URI in the To header and in the Request-URI, 1777 this is not policed by other SIP entities. Therefore a To header URI 1778 that differs from the Request-URI received at the gateway cannot be 1779 used as a reliable indication that the call has been retargeted in 1780 the SIP network or as a reliable indication of the original target. 1781 Gateway implementers making use of the To header for mapping to QSIG 1782 elements (e.g., as part of QSIG call diversion signalling) may wish 1783 to make provision for disabling this mapping when deployed in 1784 situations where the reliability of the QSIG elements concerned is 1785 important. 1787 The arbitrary population of the From header of requests by SIP user 1788 agents has some well-understood security implications for devices 1789 that rely on the From header as an accurate representation of the 1790 identity of the originator. Any gateway that intends to use the From 1791 header to populate the Calling party number information element of a 1792 QSIG SETUP message should authenticate the originator of the request 1793 and make sure that it is authorized to assert that calling number (or 1794 make use of some more secure method to ascertain the identity of the 1795 caller). Note that gateways, like all other SIP user agents, MUST 1796 support Digest authentication as described in [10]. Similar 1797 considerations apply to the use of the SIP P-Asserted-Identity header 1798 for mapping to the QSIG Calling party number or Connected number 1799 information element. 1801 There is another class of potential risk that is related to the cut- 1802 through of the backwards media path before the call is answered. 1803 Several practices described in this document involve the connection 1804 of media streams to user information channels on inter-PINX links and 1805 the sending of progress description number 1 or 8 in a backward QSIG 1806 message. This can result in media being cut through end-to-end, and 1807 it is possible for the called user agent then to play arbitrary audio 1808 to the caller for an indefinite period of time before transmitting a 1809 final response (in the form of a 2xx or higher response code). This 1810 is useful since it also permits network entities (particularly legacy 1811 networks that are incapable of transmitting Q.850 cause values) to 1812 play tones and announcements to indicate call failure or call 1813 progress, without triggering charging by transmitting a 2xx response. 1814 Also early cut-through can help to prevent clipping of the initial 1815 media when the call is answered. There are conceivable respects in 1816 which this capability could be used fraudulently by the called user 1817 agent for transmitting arbitrary information without answering the 1818 call or before answering the call. However, in corporate networks 1819 charging is often not an issue, and for calls arriving at a corporate 1820 network from a carrier network the carrier network normally takes 1821 steps to prevent fraud. 1823 The usefulness of this capability appears to outweigh any risks 1824 involved, which may in practice be no greater than in existing 1825 PISN/ISDN environments. However, gateway implementers may wish to 1826 make provision for gateway administrators to turn off cut-through or 1827 minimise its impact (e.g., by imposing a time limit) when deployed in 1828 situations where problems can arise. 1830 Unlike a traditional PISN phone, a SIP user agent can launch multiple 1831 simultaneous requests in order to reach a particular resource. It 1832 would be trivial for a SIP user agent to launch 100 SIP INVITE 1833 requests at a 100 port gateway, thereby tying up all of its ports. A 1834 malicious user could choose to launch requests to telephone numbers 1835 that are known never to answer, or, where overlap signalling is used, 1836 to incomplete addresses. This could saturate resources at the gateway 1837 indefinitely, potentially without incurring any charges. Gateways 1838 implementers may therefore wish to provide means of restricting 1839 according to policy the number of simultaneous requests originating 1840 from the same authenticated source, or similar mechanisms to address 1841 this possible denial-of-service attack. 1843 12 Author's Addresses 1845 John Elwell 1846 Siemens Communications 1847 Technology Drive 1848 Beeston 1849 Nottingham, UK, NG9 1LA 1850 email: john.elwell@siemens.com 1852 Frank Derks 1853 Philips Business Communications 1854 P.O. Box 32 1855 1200 JD, Hilversum 1856 The Netherlands 1857 email: frank.derks@philips.com 1859 Olivier Rousseau 1860 Alcatel Business Systems 1861 32,Avenue Kleber 1862 92700 Colombes 1863 France 1864 email: olivier.rousseau@col.bsf.alcatel.fr 1866 Patrick Mourot 1867 Alcatel Business Systems 1868 1,Rue Dr A. Schweitzer 1869 67400 Illkirch 1870 France 1871 email: patrick.mourot@sxb.bsf.alcatel.fr 1873 13 Normative References 1875 [1] ECMA-133 "Private Integrated Services Network (PISN � Reference 1876 configuration for PISN exchanges (PINX)" (International Standard 1877 ISO/IEC 11579-1) 1879 [2] ECMA-143 "Private Integrated Services Network - Circuit-mode 1880 Bearer Services - Inter-Exchange Signalling Procedures and Protocol" 1881 (International Standard ISO/IEC 11572) 1883 [3] ECMA-165 "Private Integrated Services Network - Generic 1884 Functional Protocol for the Support of Supplementary Services - 1885 Inter-Exchange Signalling Procedures and Protocol" (International 1886 Standard ISO/IEC 11582) 1888 [4] ECMA-307 "Corporate Telecommunication Networks - Signalling 1889 Interworking between QSIG and H.323 - Generic Functional Protocol for 1890 the Support of Supplementary Services" (International Standard 1891 ISO/IEC 21409) 1893 [5] J. Postel, "Transmission Control Protocol", RFC 793. 1895 [6] J. Postel, "User Datagram Protocol", RFC 768. 1897 [7] T. Dierks, C.Allen, "The TLS protocol version 1.0", RFC 2246. 1899 [8] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 1900 2327. 1902 [9] R. Stewart et al., "Stream Control Transmission Protocol" RFC 1903 2960. 1905 [10] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 1906 protocol", RFC 3261. 1908 [11] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional 1909 Responses in SIP", RFC 3262. 1911 [12] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with SDP", 1912 RFC 3264. 1914 [13] J. Peterson, �A Privacy Mechanism for the Session Initiation 1915 Protocol (SIP)�, RFC AAAA 1917 [14] C. Jennings, J. Peterson, M. Watson, �Private Extensions to the 1918 Session Initiation Protocol (SIP) for Asserted Identity within 1919 Trusted Networks�, RFC BBBB 1921 [15] J. Rosenberg, "The Session Initiation Protocol UPDATE Method", 1922 RFC 3311. 1924 [16] J. Postel, "Internet Protocol", RFC 791. 1926 [17] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)�, 1927 RFC 2460. 1929 [18] ITU-T Recommendation E.164, �The International Public 1930 Telecommunication Numbering Plan�, (1997-05). 1932 [19] ECMA-155 "Private Integrated Services Networks (PISN) � 1933 Addressing� (International Standard ISO/IEC 11571) 1935 Annex A (informative) � Example message sequences 1937 A.1 Introduction 1939 This annex shows some typical message sequences that can occur for an 1940 interworking between QSIG and SIP. 1942 NOTE 1. For all message sequence diagrams, there is no message 1943 mapping between QSIG and SIP unless explicitly indicated by dotted 1944 lines. Also, if there are no dotted lines connecting two messages, 1945 this means that these are independent of each other in terms of the 1946 time when they occur. 1948 NOTE 2. Numbers prefixing SIP method names and response codes in the 1949 diagrams represent sequence numbers. Messages bearing the same 1950 number will have the same value in the CSeq header. 1952 NOTE 3. In these examples SIP provisional responses (other than 100) 1953 are shown as being sent reliably, using the PRACK method for 1954 acknowledgement. 1956 A.2 Message sequences for call establishment from QSIG to SIP 1958 Below are typical message sequences for successful call establishment 1959 from QSIG to SIP 1961 .-------------------. 1962 | | 1963 | GATEWAY | 1964 PISN | | IP NETWORK 1965 | `-----+------+------' | 1966 | | | | 1967 | | | | 1968 | QSIG SETUP | | 1-INVITE | 1969 1|----------------------->|......|----------------------->| 2 1970 | | | | 1971 | | | | 1972 | QSIG CALL PROCEEDING | | 1-100 TRYING | 1973 3|<-----------------------| |<-----------------------+ 4 1974 | | | | 1975 | | | | 1976 | QSIG ALERTING | | 1-180 RINGING | 1977 8|<-----------------------|......|<-----------------------+ 5 1978 | | | | 1979 | | | 2-PRACK | 1980 | | |----------------------->| 6 1981 | | | 2-200 OK | 1982 | | |<-----------------------+ 7 1983 | | | | 1984 | QSIG CONNECT | | 1-200 OK | 1985 11|<-----------------------|......|<-----------------------+ 9 1986 | | | | 1987 | QSIG CONNECT ACK | | 1-ACK | 1988 12|----------------------->| |----------------------->| 10 1989 | | | | 1990 |<======================>| |<======================>| 1991 | AUDIO | | AUDIO | 1993 Figure 3 � Typical message sequence for successful call establishment 1994 from QSIG to SIP using enbloc procedures on both QSIG and SIP 1996 1 The PISN sends a QSIG SETUP message to the gateway to begin a 1997 session with a SIP UA 1998 2 On receipt of the QSIG SETUP message, the gateway generates a SIP 1999 INVITE request and sends it to an appropriate SIP entity in the IP 2000 network based on the called number 2001 3 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no 2002 more QSIG INFORMATION messages will be accepted 2003 4 The IP network sends a SIP 100 (Trying) response to the gateway 2004 5 The IP network sends a SIP 180 (Ringing) response. 2005 6 The gateway may send back a SIP PRACK request to the IP network 2006 based on the inclusion of a Require header or a Supported header with 2007 option tag 100rel in the initial SIP INVITE request 2008 7 The IP network sends a SIP 200 (OK) response to the gateway to 2009 acknowledge the SIP PRACK request 2010 8 The gateway maps this SIP 180 (Ringing) response to a QSIG 2011 ALERTING message and sends it to the PISN. 2012 9 The IP network sends a SIP 200 (OK) response when the call is 2013 answered. 2014 10 The gateway sends a SIP ACK request to acknowledge the SIP 200 2015 (OK)response. 2016 11 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 2017 message and sends it to the PISN. 2018 12 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 2019 the QSIG CONNECT message. 2021 +------------------------+ 2022 PISN | GATEWAY | IP NETWORK 2023 | | 2024 | QSIG SETUP +--------+-------+-------+ | 2025 1|-------------------------->| | | 2026 | | | | 2027 | QSIG SETUP ACK | | | 2028 2|<--------------------------| | | 2029 | | | | 2030 | QSIG INFORMATION | | | 2031 3|-------------------------->| | | 2032 | | | | 2033 | QSIG INFORMATION | | 1-INVITE | 2034 3a|-------------------------->|.......|----------------------->|4 2035 | QSIG CALL PROCEEDING | | 1-100 TRYING | 2036 5|<--------------------------| |<-----------------------|6 2037 | | | | 2038 | QSIG ALERTING | | 1-180 RINGING | 2039 10|<--------------------------|.......|<-----------------------|7 2040 | | | 2-PRACK | 2041 | | |----------------------->|8 2042 | | | 2-200 OK | 2043 | | |<-----------------------|9 2044 | QSIG CONNECT | | 1-200 OK | 2045 13|<--------------------------|.......|<-----------------------|11 2046 | | | | 2047 | QSIG CONNECT ACK | | 1-ACK | 2048 14|-------------------------->| |----------------------->|12 2049 | AUDIO | | AUDIO | 2050 |<=========================>| |<======================>| 2052 Figure 4 � Typical message sequence for successful call establishment 2053 from QSIG to SIP using overlap receiving on QSIG and enbloc sending 2054 on SIP 2056 1 The PISN sends a QSIG SETUP message to the gateway to begin a 2057 session with a SIP UA. The QSIG SETUP message does not contain a 2058 Sending Complete information element. 2059 2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. 2060 More digits are expected. 2061 3 More digits are sent from the PISN within a QSIG INFORMATION 2062 message. 2063 3a More digits are sent from the PISN within a QSIG INFORMATION 2064 message. The QSIG INFORMATION message contains a Sending Complete 2065 information element 2066 4 The Gateway generates a SIP INVITE request and sends it to an 2067 appropriate SIP entity in the IP network, based on the called number 2068 5 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no 2069 more QSIG INFORMATION messages will be accepted 2070 6 The IP network sends a SIP 100 (Trying) response to the gateway 2071 7 The IP network sends a SIP 180 (Ringing) response. 2072 8 The gateway may send back a SIP PRACK request to the IP network 2073 based on the inclusion of a Require header or a Supported header with 2074 option tag 100rel in the initial SIP INVITE request 2075 9 The IP network sends a SIP 200 (OK) response to the gateway to 2076 acknowledge the SIP PRACK request 2077 10 The gateway maps this SIP 180 (Ringing) response to a QSIG 2078 ALERTING message and sends it to the PINX. 2079 11 The IP network sends a SIP 200 (OK) response when the call is 2080 answered. 2082 12 The gateway sends an SIP ACK request to acknowledge the SIP 200 2083 (OK) response. 2084 13 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 2085 message and sends it to the PINX. 2086 14 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 2087 the QSIG CONNECT message. 2089 +----------------------+ 2090 PISN | GATEWAY | IP NETWORK 2091 | | 2092 | QSIG SETUP +-------+-------+------+ | 2093 1 |------------------------->| | | 2094 | | | | 2095 | QSIG SETUP ACK | | | 2096 2 |<-------------------------| | | 2097 | | | | 2098 | QSIG INFORMATION | | | 2099 3 |------------------------->| | | 2100 | QSIG INFORMATION | | 1-INVITE | 2101 3 |------------------------->|.......|------------------------>|4 2102 | | | 1-484 | 2103 | | |<------------------------|5 2104 | | | 1-ACK | 2105 | | |------------------------>|6 2106 | QSIG INFORMATION | | 2-INVITE | 2107 7 |------------------------->|.......|------------------------>|4 2108 | | | 2-484 | 2109 | | |<------------------------|5 2110 | | | 2-ACK | 2111 | | |------------------------>|6 2112 | | | | 2113 | QSIG INFORMATION | | | 2114 | Sending Complete IE | | 3-INVITE | 2115 8 |------------------------->|.......|------------------------>|10 2116 | QSIG CALL PROCEEDING | | 3-100 TRYING | 2117 9 |<-------------------------| |<------------------------|11 2118 | | | | 2119 | QSIG ALERTING | | 3-180 RINGING | 2120 15|<-------------------------|.......|<------------------------|12 2121 | | | 4-PRACK | 2122 | | |------------------------>|13 2123 | | | 4-200 OK | 2124 | | |<------------------------|14 2125 | QSIG CONNECT | | 3-200 OK | 2126 18|<-------------------------|.......|<------------------------|16 2127 | | | | 2128 | QSIG CONNECT ACK | | 3-ACK | 2129 19|------------------------->| |------------------------>|17 2130 | AUDIO | | AUDIO | 2131 |<========================>| |<=======================>| 2132 | | | | 2134 Figure 5 � Typical message sequence for successful call establishment 2135 from QSIG to SIP using overlap procedures on both QSIG and SIP 2137 1 The PISN sends a QSIG SETUP message to the gateway to begin a 2138 session with a SIP UA. The QSIG SETUP message does not contain a 2139 Sending complete information element. 2140 2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. 2141 More digits are expected. 2142 3 More digits are sent from the PISN within a QSIG INFORMATION 2143 message. 2144 4 When the gateway receives the minimum number of digits required to 2145 route the call it generates a SIP INVITE request and sends it to an 2146 appropriate SIP entity in the IP network based on the called number 2147 5 Due to an insufficient number of digits the IP network will return 2148 a SIP 484 (Address Incomplete) response. 2149 6 The SIP 484 (Address Incomplete) response is acknowledged. 2150 7 More digits are received from the PISN in a QSIG INFORMATION 2151 message. A new INVITE is sent with the same Call-ID but an updated 2152 Request-URI. 2153 8 More digits are received from the PISN in a QSIG INFORMATION 2154 message. The QSIG INFORMATION message contains a Sending Complete 2155 information element 2156 9 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no 2157 more information will be accepted 2158 10 The gateway sends a new SIP INVITE request with an updated 2159 Request-URI field. 2160 11 The IP network sends a SIP 100 (Trying) response to the gateway 2161 12 The IP network sends a SIP 180 (Ringing) response. 2162 13 The gateway may send back a SIP PRACK request to the IP network 2163 based on the inclusion of a Require header or a Supported header with 2164 option tag 100rel in the initial SIP INVITE request 2165 14 The IP network sends a SIP 200 (OK) response to the gateway to 2166 acknowledge the SIP PRACK request 2167 15 The gateway maps this SIP 180 (Ringing) response to a QSIG 2168 ALERTING message and sends it to the PISN. 2169 16 The IP network sends a SIP 200 (OK) response when the call is 2170 answered. 2171 17 The gateway sends a SIP ACK request to acknowledge the SIP 200 2172 (OK) response. 2173 18 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 2174 message. 2175 19 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 2176 the QSIG CONNECT message. 2178 A.3 Message sequences for call establishment from SIP to QSIG 2179 Below are typical message sequences for successful call establishment 2180 from SIP to QSIG 2182 +----------------------+ 2183 IP NETWORK | GATEWAY | PISN 2184 | | 2185 | +-------+-------+------+ | 2186 | | | | 2187 | | | | 2188 | 1-INVITE | | QSIG SETUP | 2189 1 |------------------------->|.......|------------------------>|3 2190 | 1-100 TRYING | | QSIG CALL PROCEEDING | 2191 2 |<-------------------------| |<------------------------|4 2192 | 1-180 RINGING | | QSIG ALERTING | 2193 6 |<-------------------------|.......|<------------------------|5 2194 | | | | 2195 | | | | 2196 | 2-PRACK | | | 2197 7 |------------------------->| | | 2198 | 2-200 OK | | | 2199 8 |<-------------------------| | | 2200 | 1-200 OK | | QSIG CONNECT | 2201 11|<-------------------------|.......|<------------------------|9 2202 | | | | 2203 | 1-ACK | | QSIG CONNECT ACK | 2204 12|------------------------->| |------------------------>|10 2205 | AUDIO | | AUDIO | 2206 |<========================>| |<=======================>| 2207 | | | | 2209 Figure 6 � Typical message sequence for successful call establishment 2210 from SIP to QSIG using enbloc procedures 2212 1 The IP network sends a SIP INVITE request to the gateway 2213 2 The gateway sends a SIP 100 (Trying) response to the IP network 2214 3 On receipt of the SIP INVITE request, the gateway sends a QSIG 2215 SETUP message 2216 4 The PISN sends a QSIG CALL PROCEEDING message to the gateway 2217 5 A QSIG ALERTING message is returned to indicate that the end user 2218 in the PISN is being alerted 2219 6 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) 2220 response 2221 7 The IP network can send back a SIP PRACK request to the IP network 2222 based on the inclusion of a Require header or a Supported header with 2223 option tag 100rel in the initial SIP INVITE request 2224 8 The gateway sends a SIP 200 (OK) response to acknowledge the SIP 2225 PRACK request 2226 9 The PISN sends a QSIG CONNECT message to the gateway when the call 2227 is answered 2228 10 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 2229 acknowledge the QSIG CONNECT message 2230 11 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 2231 12 The IP network, upon receiving a SIP INVITE final response (200), 2232 will send a SIP ACK request to acknowledge receipt 2234 +----------------------+ 2235 IP NETWORK | GATEWAY | PISN 2236 | | 2237 | 1-INVITE +-------+-------+------+ | 2238 1 |------------------------->| | | 2239 | 1-484 | | | 2240 2 |<-------------------------| | | 2241 | 1-ACK | | | 2242 3 |------------------------->| | | 2243 | 2-INVITE | | | 2244 1 |------------------------->| | | 2245 | 2-484 | | | 2246 2 |<-------------------------| | | 2247 | 2- ACK | | | 2248 3 |------------------------->| | | 2249 | 3-INVITE | | QSIG SETUP | 2250 4 |------------------------->|.......|------------------------>|6 2251 | 3-100 TRYING | | QSIG CALL PROCEEDING | 2252 5 |<-------------------------| |<------------------------|7 2253 | 3-180 RINGING | | QSIG ALERTING | 2254 9 |<-------------------------|.......|<------------------------|8 2255 | | | | 2256 | | | | 2257 | 4-PRACK | | | 2258 10|------------------------->| | | 2259 | 5-200 OK | | | 2260 11|<-------------------------| | | 2261 | 3-200 OK | | QSIG CONNECT | 2262 14|<-------------------------|.......|<------------------------|12 2263 | | | | 2264 | 3-ACK | | QSIG CONNECT ACK | 2265 15|------------------------->| |------------------------>|13 2266 | AUDIO | | AUDIO | 2267 |<========================>| |<=======================>| 2268 | | | | 2270 Figure 7 � Typical message sequence for successful call establishment 2271 from SIP to QSIG using overlap receiving on SIP and enbloc sending on 2272 QSIG 2274 1 The IP network sends a SIP INVITE request to the gateway 2275 2 Due to an insufficient number of digits the gateway returns a SIP 2276 484(Address Incomplete) response. 2278 3 The IP network acknowledge the SIP 484 (Address Incomplete) 2279 response. 2280 4 The IP network sends a new SIP INVITE request with the same Call- 2281 ID and updated Request-URI. 2282 5 The gateway now has all the digits required to route the call to 2283 the PISN. The gateway sends back a SIP 100 (Trying) response 2284 6 The gateway sends a QSIG SETUP message 2285 7 The PISN sends a QSIG CALL PROCEEDING message to the gateway 2286 8 A QSIG ALERTING message is returned to indicate that the end user 2287 in the PISN is being alerted 2288 9 The gateway maps the QSIG ALERTING message to a SIP 180 2289 (Ringing)response 2290 10 The IP network can send back a SIP PRACK request to the IP network 2291 based on the inclusion of a Require header or a Supported header with 2292 option tag 100rel in the initial SIP INVITE request 2293 11 The gateway sends a SIP 200 (OK) response to acknowledge the SIP 2294 PRACK request 2295 12 The PISN sends a QSIG CONNECT message to the gateway when the call 2296 is answered 2297 13 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 2298 acknowledge the CONNECT message 2299 14 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 2300 15 The IP network, upon receiving a SIP INVITE final response (200), 2301 will send a SIP ACK request to acknowledge receipt 2303 +----------------------+ 2304 IP NETWORK | GATEWAY | PISN 2305 | | 2306 | 1-INVITE +-------+-------+------+ | 2307 1 |------------------------->| | | 2308 | 1-484 | | | 2309 2 |<-------------------------| | | 2310 | 1-ACK | | | 2311 3 |------------------------->| | | 2312 | 2-INVITE | | QSIG SETUP | 2313 4 |------------------------->|.......|------------------------>|6 2314 | 2-100 TRYING | | QSIG SETUP AC | 2315 5 |<-------------------------| |<------------------------|7 2316 | 3- INVITE | | QSIG INFORMATION | 2317 8 |------------------------->|.......|------------------------>|10 2318 | 3-100 TRYING | | | 2319 9 |<-------------------------| | QSIG CALL PROCEEDING | 2320 | | |<------------------------|11 2321 13| 3-180 RINGING | | QSIG ALERTING | 2322 |<-------------------------|.......|<------------------------|12 2323 | 2-484 | | | 2324 14|<-------------------------| | | 2325 | 2-ACK | | | 2326 15|------------------------->| | | 2327 | 4-PRACK | | | 2328 16|------------------------->| | | 2329 | 4-200 OK | | | 2330 17|<-------------------------| | | 2331 | 3-200 OK | | QSIG CONNECT | 2332 20|<-------------------------|.......|<------------------------|18 2333 | | | | 2334 | 3-ACK | | QSIG CONNECT ACK | 2335 21|------------------------->| |------------------------>|19 2336 | AUDIO | | AUDIO | 2337 |<========================>| |<=======================>| 2338 | | | | 2340 Figure 8 � Typical message sequence for successful call establishment 2341 from SIP to QSIG using overlap procedures on both SIP and QSIG 2343 1 The IP network sends a SIP INVITE request to the gateway 2344 2 Due to an insufficient number of digits the gateway returns a SIP 2345 484(Address Incomplete) response. 2346 3 The IP network acknowledge the SIP 484 (Address Incomplete) 2347 response. 2348 4 The IP network sends a new SIP INVITE request with the same Call- 2349 ID and updated Request-URI. 2350 5 The gateway now has all the digits required to route the call to 2351 the PISN. The gateway sends back a SIP 100 (Trying) response to the 2352 IP network 2353 6 The gateway sends a QSIG SETUP message 2354 7 The PISN needs more digits to route the call and sends a QSIG 2355 SETUP ACKNOWLEDGE message to the gateway 2356 8 The IP network sends a new SIP INVITE request with the same Call- 2357 ID and updated Request-URI. 2358 9 The gateway sends back a SIP 100 (Trying) response to the IP 2359 network 2360 10 The gateway maps the new SIP INVITE request to a QSIG INFORMATION 2361 message 2362 11 The PISN has all the digits required and sends back a QSIG CALL 2363 PROCEEDING message to the gateway 2364 12 A QSIG ALERTING message is returned to indicate that the end user 2365 in the PISN is being alerted 2366 13 The gateway maps the QSIG ALERTING message to a SIP 180 2367 (Ringing)response 2368 14 The gateway sends a SIP 484 (Address Incomplete) response for the 2369 previous SIP INVITE request 2370 15 The IP network acknowledges the SIP 484 (Address Incomplete) 2371 response 2372 16 The IP network can send back a SIP PRACK request to the IP network 2373 based on the inclusion of a Require header or a Supported header with 2374 option tag 100rel in the initial SIP INVITE request 2375 17 The gateway sends a SIP 200 (OK) response to acknowledge the SIP 2376 PRACK request 2377 18 The PISN sends a QSIG CONNECT message to the gateway when the call 2378 is answered 2379 19 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 2380 acknowledge the QSIG CONNECT message 2381 20 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 2382 21 The IP network, upon receiving a SIP INVITE final response (200), 2383 will send a SIP ACK request to acknowledge receipt 2385 A.4 Message sequence for call clearing from QSIG to SIP 2387 Below are typical message sequences for Call Clearing from QSIG to 2388 SIP 2390 .-------------------. 2391 | | 2392 | GATEWAY | 2393 PISN | | IP 2394 NETWORK 2395 | `-----+------+------' | 2396 | | | | 2397 | | | | 2398 | QSIG DISCONNECT | | 2- BYE | 2399 1|----------------------->|......|----------------------- 2400 >|4 2401 | QSIG RELEASE | | 2-200 OK | 2402 2|<-----------------------| |<----------------------- 2403 |5 2404 | QSIG RELEASE COMP | | | 2405 3|----------------------->| | | 2406 | | | | 2407 | | | | 2408 | | | | 2410 Figure 9 � Typical message sequence for call clearing from QSIG to 2411 SIP subsequent to call establishment 2413 1 The PISN sends a QSIG DISCONNECT message to the gateway 2414 2 The gateway sends back a QSIG RELEASE message to the PISN in 2415 response to the QSIG DISCONNECT message 2416 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All 2417 PISN resources are now released. 2418 4 The gateway maps the QSIG DISCONNECT message to a SIP BYE request 2419 5 The IP network sends back a SIP 200 (OK) response to the SIP BYE 2420 request. All IP resources are now released 2422 .-------------------. 2423 | | 2424 | GATEWAY | 2425 PISN | | IP NETWORK 2426 | `-----+------+------' | 2427 | | | | 2428 | | | | 2429 | QSIG DISCONNECT | | 1- 4XX / 6XX | 2430 1|----------------------->|......|---------------------->|4 2431 | QSIG RELEASE | | 1- ACK | 2432 2|<-----------------------| |<----------------------|5 2433 | QSIG RELEASE COMP | | | 2434 3|----------------------->| | | 2435 | | | | 2436 | | | | 2438 Figure 10 � Typical message sequence for call clearing from QSIG to 2439 SIP during establishment of a call from SIP to QSIG (gateway has not 2440 sent a final response to the SIP INVITE request) 2442 1 The PISN sends a QSIG DISCONNECT message to the gateway 2443 2 The gateway sends back a QSIG RELEASE message to the PISN in 2444 response to the QSIG DISCONNECT message 2445 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All 2446 PISN resources are now released. 2447 4 The gateway maps the QSIG DISCONNECT message to a SIP 4xx-6xx 2448 response 2449 5 The IP network sends back a SIP ACK request in response to the SIP 2450 4xx-6xx response. All IP resources are now released 2452 .-------------------. 2453 | | 2454 | GATEWAY | 2455 PISN | | IP NETWORK 2456 | `-----+------+------' | 2457 | | | | 2458 | | | | 2459 | QSIG DISCONNECT | | 1- CANCEL | 2460 1|----------------------->|......|----------------------->|4 2461 | QSIG RELEASE | |1-487 Request Terminated| 2462 2|<-----------------------| |<-----------------------|5 2463 | QSIG RELEASE COMP | | | 2464 3|----------------------->| | 1- ACK | 2465 | | |----------------------->|6 2466 | | | | 2467 | | | 1- 200 OK | 2468 | | |<-----------------------|7 2469 | | | | 2471 Figure 11 � Typical message sequence for call clearing from QSIG to 2472 SIP during establishment of a call from QSIG to SIP (gateway has 2473 received a provisional response to the SIP INVITE request but not a 2474 final response) 2476 1 The PISN sends a QSIG DISCONNECT message to the gateway 2477 2 The gateway sends back a QSIG RELEASE message to the PISN in 2478 response to the QSIG DISCONNECT message 2479 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All 2480 PISN resources are now released. 2481 4 The gateway maps the QSIG DISCONNECT message to a SIP CANCEL 2482 request(subject to a provisional response but no final response 2483 having been received) 2484 5 The IP network sends back a SIP 487 (Request Terminated) response 2485 to the SIP INVITE request. 2486 6 The gateway, on receiving a SIP final response (487) to the SIP 2487 INVITE request, sends back a SIP ACK request to acknowledge receipt 2488 7 The IP network sends back a SIP 200 (OK) response to the SIP 2489 CANCEL request. All IP resources are now released 2491 A.5 Message sequence for call clearing from SIP to QSIG 2493 Below are typical message sequences for Call Clearing from SIP to 2494 QSIG 2496 .-------------------. 2497 | | 2498 | GATEWAY | 2499 IP NETWORK | | PISN 2500 | `-----+------+------' | 2501 | | | | 2502 | | | | 2503 | 2- BYE | | QSIG DISCONNECT | 2504 1|----------------------->|......|----------------------->|3 2505 | | | QSIG RELEASE | 2506 | | |<-----------------------|4 2507 | 2-200 OK | | QSIG RELEASE COMP | 2508 2|<-----------------------| |----------------------->|5 2509 | | | | 2510 | | | | 2512 Figure 12 � Typical message sequence for call clearing from SIP to 2513 QSIG subsequent to call establishment 2515 1 The IP network sends a SIP BYE request to the gateway 2516 2 The gateway sends back a SIP 200 (OK) response to the SIP BYE 2517 request. All IP resources are now released 2518 3 The gateway maps the SIP BYE request to a QSIG DISCONNECT message 2519 4 The PISN sends back a QSIG RELEASE message to the gateway in 2520 response to the QSIG DISCONNECT message 2521 5 The gateway sends a QSIG RELEASE COMPLETE message in response. All 2522 PISN resources are now released. 2524 .-------------------. 2525 | | 2526 | GATEWAY | 2527 IP NETWORK | | PISN 2528 | `-----+------+------' | 2529 | | | | 2530 | | | | 2531 | 1- 4XX / 6XX | | QSIG DISCONNECT | 2532 1|----------------------->|......|----------------------->|3 2533 | | | QSIG RELEASE | 2534 | | |<-----------------------|4 2535 | 1- ACK | | QSIG RELEASE COMP | 2536 2|<-----------------------| |----------------------->|5 2537 | | | | 2538 | | | | 2539 | | | | 2541 Figure 13 � Typical message sequence for call clearing from SIP to 2542 QSIG during establishment of a call from QSIG to SIP (gateway has not 2543 previously received a final response to the SIP INVITE request) 2545 1 The IP network sends a SIP 4xx-6xx response to the gateway 2546 2 The gateway sends back a SIP ACK request in response to the SIP 2547 4xx-6xx response. All IP resources are now released 2548 3 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT 2549 message 2550 4 The PISN sends back a QSIG RELEASE message to the gateway in 2551 response to the QSIG DISCONNECT message 2552 5 The gateway sends a QSIG RELEASE COMPLETE message in response. All 2553 PISN resources are now released. 2555 .-------------------. 2556 | | 2557 | GATEWAY | 2558 IP NETWORK | | PISN 2559 | `-----+------+------' | 2560 | | | | 2561 | | | | 2562 | 1- CANCEL | | QSIG DISCONNECT | 2563 1|----------------------->|......|----------------------->|4 2564 | | | QSIG RELEASE | 2565 | | |<-----------------------|5 2566 |1-487 Request Terminated| | QSIG RELEASE COMP | 2567 2|<-----------------------| |----------------------->|6 2568 | | | | 2569 | 1- ACK | | | 2570 3|----------------------->| | | 2571 | | | | 2572 | 1- 200 OK | | | 2573 4|<-----------------------| | | 2575 Figure 14 � Typical message sequence for call clearing from SIP to 2576 QSIG during establishment of a call from SIP to QSIG (gateway has 2577 sent a provisional response to the SIP INVITE request but not a final 2578 response) 2580 1 The IP network sends a SIP CANCEL request to the gateway 2581 2 The gateway sends back a SIP 487 (Request Terminated) response to 2582 the SIP INVITE request 2583 3 The IP network, on receiving a SIP final response (487) to the SIP 2584 INVITE request, sends back a SIP ACK request to acknowledge receipt 2585 4 The gateway sends back a SIP 200 (OK) response to the SIP CANCEL 2586 request. All IP resources are now released 2587 5 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT 2588 message 2589 6 The PISN sends back a QSIG RELEASE message to the gateway in 2590 response to the QSIG DISCONNECT message 2591 7 The gateway sends a QSIG RELEASE COMPLETE message in response. All 2592 PISN resources are now released. 2594 Annex B (temporary) � Change log 2596 Compared with draft-elwell-sipping-qsig2sip-02 the following changes 2597 have been made: 2599 - addition of statement concerning QSIG segmented messages in section 2600 8.1; 2601 - clarifications concerning backward media establishment and local 2602 ringback tone in section 8.2.1; 2603 - clarifications to overlap sending in 8.2.2.2; 2604 - additions concerning availability of channel on inter-PINX link in 2605 8.3.1; 2606 - addition of note on handling certain QSIG cause values locally 2607 rather than mapping to SIP response codes in 8.4.1; 2608 - addition of statement concerning generation of location field in 2609 QSIG Cause information element in 8.4.4; 2610 - additions covering QSIG RESTART message and QSIG timer T301 expiry 2611 in 8.4.5; 2612 - addition of procedures for use of P-Asserted-Identity and Privacy 2613 headers in section 9; 2614 - addition of security considerations text in section 11, based on 2615 corresponding text in ISUP draft; 2616 - corrections to figures 11 and 14.