idnits 2.17.1 draft-ietf-sipping-qsig2sip-04.txt: 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: ---------------------------------------------------------------------------- == 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 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 506 has weird spacing: '...dentity heade...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 2004) is 7401 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** 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) ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. '14') ** Obsolete normative reference: RFC 2460 (ref. '16') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 6 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-ietf-sipping-qsig2sip-04.txt Alcatel 8 Expires: July 2004 January 2004 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 RFC 2026 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 Table of Contents 47 1 Introduction....................................................4 48 2 Terminology.....................................................5 49 3 Definitions.....................................................5 50 3.1 External definitions..........................................5 51 3.2 Other definitions.............................................6 52 3.2.1 Corporate telecommunication Network (CN) (also known as 53 enterprise network)...............................................6 54 3.2.2 Gateway.....................................................6 55 3.2.3 IP network..................................................6 56 3.2.4 Media stream................................................6 57 3.2.5 Private Integrated Services Network (PISN)..................6 58 3.2.6 Private Integrated services Network eXchange (PINX).........6 59 4 Acronyms........................................................6 60 5 Background and architecture.....................................7 61 6 Overview.......................................................10 62 7 General requirements...........................................11 63 8 Message mapping requirements...................................12 64 8.1 Message validation and handling of protocol errors...........12 65 8.2 Call establishment from QSIG to SIP..........................13 66 8.2.1 Call establishment from QSIG to SIP using enbloc procedures13 67 8.2.1.1 Receipt of QSIG SETUP message............................14 68 8.2.1.2 Receipt of SIP 100 (Trying) response to an INVITE request14 69 8.2.1.3 Receipt of SIP 18x provisional response to an INVITE request 70 .................................................................15 71 8.2.1.4 Receipt of SIP 2xx response to an INVITE request.........15 72 8.2.1.5 Receipt of SIP 3xx response to an INVITE request.........16 73 8.2.2 Call establishment from QSIG to SIP using overlap procedures16 74 8.2.2.1 Enbloc signalling in SIP network.........................16 75 8.2.2.1.1 Receipt of QSIG SETUP message..........................16 76 8.2.2.1.2 Receipt of QSIG INFORMATION message....................17 77 8.2.2.1.3 Receipt of SIP responses to INVITE requests............17 78 8.2.2.2 Overlap signalling in SIP network........................17 79 8.2.2.2.1 Receipt of QSIG SETUP message..........................17 80 8.2.2.2.2 Receipt of QSIG INFORMATION message....................17 81 8.2.2.2.3 Receipt of SIP 100 (Trying) response to an INVITE request 82 .................................................................18 83 8.2.2.2.4 Receipt of SIP 18x provisional response to an INVITE 84 request..........................................................18 85 8.2.2.2.5 Receipt of SIP 2xx response to an INVITE request.......18 86 8.2.2.2.6 Receipt of SIP 3xx response to an INVITE request.......18 87 8.2.2.2.7 Receipt of a SIP 4xx, 5xx or 6xx final response to an 88 INVITE request...................................................18 89 8.2.2.2.8 Receipt of multiple SIP responses to an INVITE request.19 90 8.2.2.2.9 Cancelling pending SIP INVITE transactions.............19 91 8.2.2.2.10 QSIG timer T302 expiry................................19 92 8.3 Call Establishment from SIP to QSIG..........................20 93 8.3.1 Receipt of SIP INVITE request for a new call...............20 94 8.3.2 Receipt of QSIG CALL PROCEEDING message....................21 95 8.3.3 Receipt of QSIG PROGRESS message...........................21 96 8.3.4 Receipt of QSIG ALERTING message...........................22 97 8.3.5 Inclusion of SDP information in a SIP 18x provisional response 98 .................................................................22 99 8.3.6 Receipt of QSIG CONNECT message............................23 100 8.3.7 Receipt of SIP PRACK request...............................24 101 8.3.8 Receipt of SIP ACK request.................................24 102 8.3.9 Receipt of a SIP INVITE request for a call already being 103 established......................................................24 104 8.4 Call clearing and call failure...............................25 105 8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE 106 message..........................................................25 107 8.4.2 Receipt of a SIP BYE request...............................28 108 8.4.3 Receipt of a SIP CANCEL request............................28 109 8.4.4 Receipt of a SIP 4xx - 6xx response to an INVITE request...28 110 8.4.5 Gateway-initiated call clearing............................30 111 8.5 Request to change media characteristics......................31 112 9 Number mapping.................................................31 113 9.1 Mapping from QSIG to SIP.....................................31 114 9.1.1 Using information from the QSIG Called party number information 115 element..........................................................32 116 9.1.2 Using information from the QSIG Calling party number 117 information element..............................................32 118 9.1.2.1 No URI derived and presentation indicator does not have value 119 "presentation restricted"........................................32 120 9.1.2.2 No URI derived and presentation indicator has value 121 "presentation restricted"........................................32 122 9.1.2.3 URI derived and presentation indicator has value 123 "presentation restricted"........................................32 124 9.1.2.4 URI derived and presentation indicator does not have value 125 "presentation restricted"........................................33 126 9.1.3 Using information from the QSIG Connected number information 127 element..........................................................33 128 9.1.3.1 No URI derived and presentation indicator does not have value 129 "presentation restricted"........................................33 130 9.1.3.2 No URI derived and presentation indicator has value 131 "presentation restricted"........................................33 132 9.1.3.3 URI derived and presentation indicator has value 133 "presentation restricted"........................................34 134 9.1.3.4 URI derived and presentation indicator does not have value 135 "presentation restricted"........................................34 136 9.2 Mapping from SIP to QSIG.....................................34 137 9.2.1 Generating the QSIG Called party number information element35 138 9.2.2 Generating the QSIG Calling party number information element35 139 9.2.3 Generating the QSIG Connected number information element...36 140 10 Requirements for support of basic services....................36 141 10.1 Derivation of QSIG Bearer capability information element....37 142 10.2 Derivation of media type in SDP.............................37 143 11 Security considerations.......................................38 144 11.1 General.....................................................38 145 11.2 Calls from QSIG to invalid or restricted numbers............38 146 11.3 Abuse of SIP response code..................................39 147 11.4 Use of the To header URI....................................39 148 11.5 Use of the From header URI..................................39 149 11.6 Abuse of early media........................................40 150 11.7 Protection from denial of service attacks...................40 151 12 Acknowledgements..............................................41 152 13 Author's Addresses............................................41 153 14 Normative References..........................................41 154 15 Intellectual Property Statement...............................43 155 16 Full Copyright Statement......................................43 156 Annex A - Example message sequences..............................44 157 Annex B - Change log.............................................60 159 1 Introduction 161 This document specifies signalling interworking between QSIG and the 162 Session Initiation Protocol (SIP) in support of basic services within 163 a corporate telecommunication network (CN) (also known as enterprise 164 network). 166 QSIG is a signalling protocol that operates between Private 167 Integrated Services eXchanges (PINX) within a Private Integrated 168 Services Network (PISN). A PISN provides circuit-switched basic 169 services and supplementary services to its users. QSIG is specified 170 in ECMA Standards, in particular [2] (call control in support of 171 basic services), [3] (generic functional protocol for the support of 172 supplementary services) and a number of Standards specifying 173 individual supplementary services. 175 NOTE. The name QSIG was derived from the fact that it is used for 176 signalling at the Q reference point. The Q reference point is a point 177 of demarcation between two PINXs. 179 SIP is an application layer protocol for establishing, terminating 180 and modifying multimedia sessions. It is typically carried over IP 181 [15], [16]. Telephone calls are considered as a type of multimedia 182 session where just audio is exchanged. SIP is defined in [10]. 184 As the support of telephony within corporate networks evolves from 185 circuit-switched technology to Internet technology, the two 186 technologies will co-exist in many networks for a period, perhaps 187 several years. Therefore there is a need to be able to establish, 188 modify and terminate sessions involving a participant in the SIP 189 network and a participant in the QSIG network. Such calls are 190 supported by gateways that perform interworking between SIP and QSIG. 192 This document specifies SIP-QSIG signalling interworking for basic 193 services that provide a bi-directional transfer capability for 194 speech, DTMF, facsimile and modem media between a PISN employing QSIG 195 and a corporate IP network employing SIP. Other aspects of 196 interworking, e.g., the use of RTP and SDP, will differ according to 197 the type of media concerned and are outside the scope of this 198 specification. 200 Call-related and call-independent signalling in support of 201 supplementary services is outside the scope of this specification, 202 but support for certain supplementary services (e.g., call transfer, 203 call diversion) could be the subject of future work. 205 Interworking between QSIG and SIP permits a call originating at a 206 user of a PISN to terminate at a user of a corporate IP network, or a 207 call originating at a user of a corporate IP network to terminate at 208 a user of a PISN. 210 Interworking between a PISN employing QSIG and a public IP network 211 employing SIP is outside the scope of this specification. However, 212 the functionality specified in this specification is in principle 213 applicable to such a scenario when deployed in conjunction with other 214 relevant functionality (e.g., number translation, security functions, 215 etc.). 217 This specification is applicable to any interworking unit that can 218 act as a gateway between a PISN employing QSIG and a corporate IP 219 network employing SIP. 221 2 Terminology 223 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 224 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 225 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and 226 indicate requirement levels for compliant SIP implementations. 228 3 Definitions 230 For the purposes of this specification, the following definitions 231 apply. 233 3.1 External definitions 235 The definitions in [2] and [10] apply as appropriate. 237 3.2 Other definitions 239 3.2.1 Corporate telecommunication Network (CN) (also known as enterprise 240 network) 242 Sets of privately-owned or carrier-provided equipment that are 243 located at geographically dispersed locations and are interconnected 244 to provide telecommunication services to a defined group of users. 246 NOTE. A CN can comprise a PISN, a private IP network (intranet) or a 247 combination of the two. 249 3.2.2 Gateway 251 An entity that performs interworking between a PISN using QSIG and an 252 IP network using SIP. 254 3.2.3 IP network 256 A network, unless otherwise stated a corporate network, offering 257 connectionless packet-mode services based on the Internet Protocol 258 (IP) as the network layer protocol. 260 3.2.4 Media stream 262 Audio or other user information transmitted in UDP packets, typically 263 containing RTP, in a single direction between the gateway and a peer 264 entity participating in a session established using SIP. 266 NOTE. Normally a SIP session establishes a pair of media streams, one 267 in each direction. 269 3.2.5 Private Integrated Services Network (PISN) 271 A CN or part of a CN that employs circuit-switched technology. 273 3.2.6 Private Integrated services Network eXchange (PINX) 275 A PISN nodal entity comprising switching and call handling functions 276 and supporting QSIG signalling in accordance with [2]. 278 4 Acronyms 280 DNS Domain Name Service 281 IP Internet Protocol 282 PINX Private Integrated services Network eXchange 283 PISN Private Integrated Services Network 284 RTP Real-time Transport Protocol 285 SCTP Stream Control Transmission Protocol 286 SDP Session Description Protocol 287 SIP Session Initiation Protocol 288 TCP Transmission Control Protocol 289 TLS Transport Layer Security 290 TU Transaction User 291 UA User Agent 292 UAC User Agent Client 293 UAS User Agent Server 294 UDP User Datagram Protocol 296 5 Background and architecture 298 During the 1980s, corporate voice telecommunications adopted 299 technology similar in principle to Integrated Services Digital 300 Networks (ISDN). Digital circuit switches, commonly known as Private 301 Branch eXchanges (PBX) or more formally as Private Integrated 302 services Network eXchanges (PINX) have been interconnected by digital 303 transmission systems to form Private Integrated Services Networks 304 (PISN). These digital transmission systems carry voice or other 305 payload in fixed rate channels, typically 64 Kbit/s, and signalling 306 in a separate channel. A technique known as common channel signalling 307 is employed, whereby a single signalling channel potentially controls 308 a number of payload channels or bearer channels. A typical 309 arrangement is a point-to-point transmission facility at T1 or E1 310 rate providing a 64 Kbit/s signalling channel and 23 or 30 bearer 311 channels respectively. Other arrangements are possible and have been 312 deployed, including the use of multiple transmission facilities for a 313 signalling channel and its logically associated bearer channels. Also 314 arrangements involving bearer channels at sub-64 Kbit/s have been 315 deployed, where voice payload requires the use of codecs that perform 316 compression. 318 QSIG is the internationally-standardized message-based signalling 319 protocol for use in networks as described above. It runs in a 320 signalling channel between two PINXs and controls calls on a number 321 of logically associated bearer channels between the same two PINXs. 322 The signalling channel and its logically associated bearer channels 323 are collectively known as an inter-PINX link. QSIG is independent of 324 the type of transmission capabilities over which the signalling 325 channel and bearer channels are provided. QSIG is also independent of 326 the transport protocol used to transport QSIG messages reliably over 327 the signalling channel. 329 QSIG provides a means for establishing and clearing calls that 330 originate and terminate on different PINXs. A call can be routed over 331 a single inter-PINX link connecting the originating and terminating 332 PINX, or over several inter-PINX links in series with switching at 333 intermediate PINXs known as transit PINXs. A call can originate or 334 terminate in another network, in which case it enters or leaves the 335 PISN environment through a gateway PINX. Parties are identified by 336 numbers, in accordance with either [17] or a private numbering plan. 337 This basic call capability is specified in [2]. In addition to basic 338 call capability, QSIG specifies a number of further capabilities 339 supporting the use of supplementary services in PISNs. 341 More recently corporate telecommunications networks have started to 342 exploit IP in various ways. One way is to migrate part of the network 343 to IP using SIP. This might, for example, be a new branch office with 344 a SIP proxy and SIP endpoints instead of a PINX. Alternatively, SIP 345 equipment might be used to replace an existing PINX or PINXs. The new 346 SIP environment needs to interwork with the QSIG-based PISN in order 347 to support calls originating in one environment and terminating in 348 the other. Interworking is achieved through a gateway. 350 Interworking between QSIG and SIP at gateways can also be used where 351 a SIP network interconnects different parts of a PISN, thereby 352 allowing calls between the different parts. A call can enter the SIP 353 network at one gateway and leave at another. Each gateway would 354 behave in accordance with this specification. 356 Another way of connecting two parts of a PISN would be to encapsulate 357 QSIG signalling in SIP messages for calls between the two parts. This 358 is outside the scope of this specification but could be the subject 359 of future work. 361 This document specifies signalling protocol interworking aspects of a 362 gateway between a PISN employing QSIG signalling and an IP network 363 employing SIP signalling. The gateway appears as a PINX to other 364 PINXs in the PISN. The gateway appears as a SIP endpoint to other SIP 365 entities in the IP network. The environment is shown in figure 1. 367 +------+ IP network PISN 368 | | 369 |SIP | +------+ 370 |Proxy | /| | 371 | | / |PINX | 372 +---+--+ *-----------+ / | | 373 | | | +-----+/ +------+ 374 | | | | | 375 | | | |PINX | 376 ---+-----+-------+--------+ Gateway +--------| | 377 | | | | | |\ 378 | | | | +-----+ \ 379 | | | | \ +------+ 380 | | | | \| | 381 +--+---+ +--+---+ *-----------+ |PINX | 382 |SIP | |SIP | | | 383 |End- | |End- | +------+ 384 |point | |point | 385 +------+ +------+ 387 Figure 1 - Environment 389 In addition to the signalling interworking functionality specified in 390 this specification, it is assumed that the gateway also includes the 391 following functionality: 393 -one or more physical interfaces on the PISN side supporting one or 394 more inter-PINX links, each link providing one or more constant bit 395 rate channels for media information and a reliable layer 2 connection 396 (e.g., over a fixed rate physical channel) for transporting QSIG 397 signalling messages; and 399 -one or more physical interfaces on the IP network side supporting, 400 through layer 1 and layer 2 protocols, IP as the network layer 401 protocol and UDP [6] and TCP [5] as transport layer protocols, these 402 being used for the transport of SIP signalling messages and, in the 403 case of UDP, also for media information; 405 -optionally the support of TLS [7] and/or SCTP [9] as additional 406 transport layer protocols on the IP network side, these being used 407 for the transport of SIP signalling messages; and 409 -a means of transferring media information in each direction between 410 the PISN and the IP network, including as a minimum packetization of 411 media information sent to the IP network and de-packetization of 412 media information received from the IP network. 414 NOTE. [10] mandates support for both UDP and TCP for the transport of 415 SIP messages and allows optional support for TLS and/or SCTP for this 416 same purpose. 418 The protocol model relevant to signalling interworking functionality 419 of a gateway is shown in figure 2. 421 +---------------------------------------------------------+ 422 | Inter-working function | 423 | | 424 +-----------------------+---------+-----------------------+ 425 | | | | 426 | SIP | | | 427 | | | | 428 +-----------------------+ | | 429 | | | | 430 | UDP/TCP/TLS/SCTP | | QSIG | 431 | | | | 432 +-----------------------+ | | 433 | | | | 434 | IP | | | 435 | | | | 436 +-----------------------+ +-----------------------+ 437 | IP network | | PISN | 438 | lower layers | | lower layers | 439 | | | | 440 +-----------------------+ +-----------------------+ 442 Figure 2 - Protocol model 444 In figure 2, the SIP box represents SIP syntax and encoding, the SIP 445 transport layer and the SIP transaction layer. The Interworking 446 function includes SIP Transaction User (TU) functionality. 448 6 Overview 450 The gateway maps received QSIG messages, where appropriate, to SIP 451 messages and vice versa and maintains an association between a QSIG 452 call and a SIP dialog. 454 A call from QSIG to SIP is initiated when a QSIG SETUP message 455 arrives at the gateway. The QSIG SETUP message initiates QSIG call 456 establishment and an initial response message completes negotiation 457 of the bearer channel to be used for that call. The gateway then 458 sends a SIP INVITE request, having translated the QSIG called party 459 number to a URI suitable for inclusion in the Request-URI. The SIP 460 INVITE request and the resulting SIP dialog, if successfully 461 established, are associated with the QSIG call. The SIP 2xx response 462 to the INVITE request is mapped to a QSIG CONNECT message, signifying 463 answer of the call. During establishment, media streams established 464 by SIP and SDP are connected to the bearer channel. 466 A call from SIP to QSIG is initiated when a SIP INVITE request 467 arrives at the gateway. The gateway sends a QSIG SETUP message to 468 initiate QSIG call establishment, having translated the SIP Request- 469 URI to a number suitable for use as the QSIG called party number. The 470 resulting QSIG call is associated with the SIP INVITE request and 471 with the eventual SIP dialog. Receipt of an initial QSIG response 472 message completes negotiation of the bearer channel to be used, 473 allowing media streams established by SIP and SDP to be connected to 474 that bearer channel. The QSIG CONNECT message is mapped to a SIP 200 475 OK response to the INVITE request. 477 Annex A gives examples of typical message sequences that can arise. 479 7 General requirements 481 In order to conform to this specification, a gateway SHALL support 482 QSIG in accordance with [2] as a gateway and SHALL support SIP in 483 accordance with [10] as a UA. In particular the gateway SHALL support 484 SIP syntax and encoding, the SIP transport layer and the SIP 485 transaction layer in accordance with [10]. In addition, the gateway 486 SHALL support SIP TU behaviour for a UA in accordance with [10] 487 except where stated otherwise in sections 8, 9 and 10 of this 488 specification. 490 NOTE 1. [10] mandates that a SIP entity support both UDP and TCP as 491 transport layer protocols for SIP messages. Other transport layer 492 protocols can also be supported. 494 The gateway SHALL also support SIP reliable provisional responses in 495 accordance with [11] as a UA. 497 NOTE 2. [11] makes provision for recovering from loss of provisional 498 responses (other than 100) to INVITE requests when using unreliable 499 transport services in the IP network. This is important for ensuring 500 delivery of responses that map to essential QSIG messages. 502 The gateway SHALL support SDP in accordance with [8] and its use in 503 accordance with the offer / answer model in [12]. 505 Section 9 also specifies optional use of the Privacy header in 506 accordance with [13] and the P-Asserted-Identity header in 507 accordance with [14]. 509 The gateway SHALL support calls from QSIG to SIP and calls from SIP 510 to QSIG. 512 SIP methods not defined in [10] or [11] are outside the scope of this 513 specification but could be the subject of other specifications for 514 interworking with QSIG, e.g., for interworking in support of 515 supplementary services. 517 As a result of DNS look-up by the gateway in order to determine where 518 to send a SIP INVITE request, a number of candidate destinations can 519 be attempted in sequence. The way in which this is handled by the 520 gateway is outside the scope of this specification. However, any 521 behaviour specified in this document on receipt of a SIP 4xx or 5xx 522 final response to an INVITE request SHOULD apply only when there are 523 no more candidate destinations to try or when overlap signalling 524 applies in the SIP network (see 8.2.2.2). 526 8 Message mapping requirements 528 8.1 Message validation and handling of protocol errors 530 The gateway SHALL validate received QSIG messages in accordance with 531 the requirements of [2] and SHALL act in accordance with [2] on 532 detection of a QSIG protocol error. The requirements of this section 533 for acting on a received QSIG message apply only to a received QSIG 534 message that has been successfully validated and that satisfies one 535 of the following conditions: 537 -the QSIG message is a SETUP message and indicates a destination in 538 the IP network and a bearer capability for which the gateway is able 539 to provide interworking; or 541 -the QSIG message is a message other than SETUP and contains a call 542 reference that identifies an existing call for which the gateway is 543 providing interworking between QSIG and SIP. 545 The processing of any valid QSIG message that does not satisfy any of 546 these conditions is outside the scope of this specification. Also the 547 processing of any QSIG message relating to call-independent 548 signalling connections or connectionless transport, as specified in 549 [3], is outside the scope of this specification. 551 If segmented QSIG messages are received, the gateway SHALL await 552 receipt of all segments of a message and SHALL validate and act on 553 the complete reassembled message. 555 The gateway SHALL validate received SIP messages (requests and 556 responses) in accordance with the requirements of [10] and SHALL act 557 in accordance with [10] on detection of a SIP protocol error. 558 Requirements of this section for acting on a received SIP message 559 apply only to a received message that has been successfully validated 560 and that satisfies one of the following conditions: 562 -the SIP message is an INVITE request that contains no tag parameter 563 in the To header field, does not match an ongoing transaction (i.e., 564 is not a merged request, see 8.2.2.2 of [10]) and indicates a 565 destination in the PISN for which the gateway is able to provide 566 interworking; or 568 -the SIP message is a request that relates to an existing dialog 569 representing a call for which the gateway is providing interworking 570 between QSIG and SIP; or 572 -the SIP message is a CANCEL request that relates to a received 573 INVITE request for which the gateway is providing interworking with 574 QSIG but for which the only response sent is informational (1xx), no 575 dialog having been confirmed; or 577 -the SIP message is a response to a request sent by the gateway in 578 accordance with this section. 580 The processing of any valid SIP message that does not satisfy any of 581 these conditions is outside the scope of this specification. 583 NOTE. These rules mean that an error detected in a received message 584 will not be propagated to the other side of the gateway. However, 585 there can be an indirect impact on the other side of the gateway, 586 e.g., the initiation of call clearing procedures. 588 The gateway SHALL run QSIG protocol timers as specified in [2] and 589 SHALL act in accordance with [2] if a QSIG protocol timer expires. 590 Any other action on expiry of a QSIG protocol timer is outside the 591 scope of this specification, except that if it results in the 592 clearing of the QSIG call, the gateway SHALL also clear the SIP call 593 in accordance with 8.4.5. 595 The gateway SHALL run SIP protocol timers as specified in [10] and 596 SHALL act in accordance with [10] if a SIP protocol timer expires. 597 Any other action on expiry of a SIP protocol timer is outside the 598 scope of this specification, except that if it results in the 599 clearing of the SIP call, the gateway SHALL also clear the QSIG call 600 in accordance with 8.4.5. 602 8.2 Call establishment from QSIG to SIP 603 8.2.1 Call establishment from QSIG to SIP using enbloc procedures 605 The following procedures apply when the gateway receives a QSIG SETUP 606 message containing a Sending Complete information element or the 607 gateway receives a QSIG SETUP message and is able to determine that 608 the number in the Called party number information element is 609 complete. 611 NOTE. In the absence of a Sending Complete information element the 612 means by which the gateway determines the number to be complete is an 613 implementation matter. It can involve knowledge of the numbering plan 614 and/or use of inter-digit timer expiry. 616 8.2.1.1 Receipt of QSIG SETUP message 618 On receipt of a QSIG SETUP message containing a number that the 619 gateway determines to be complete in the Called party number 620 information element, or containing a Sending complete information 621 element and a number that could potentially be complete, the gateway 622 SHALL map the QSIG SETUP message to a SIP INVITE request. The gateway 623 SHALL also send a QSIG CALL PROCEEDING message. 625 The gateway SHALL generate the SIP Request-URI, To and From fields in 626 the SIP INVITE request in accordance with section 9. The gateway 627 SHALL include in the INVITE request a Supported header containing 628 option tag 100rel, to indicate support for [11]. 630 The gateway SHALL include SDP offer information in the SIP INVITE 631 request as described in section 10. It SHOULD also connect the 632 incoming media stream to the user information channel of the inter- 633 PINX link, to allow the caller to hear in-band tones or announcements 634 and prevent speech clipping on answer. Because of forking, the 635 gateway may receive more than one media stream, in which case it 636 SHOULD select one (e.g., the first received). If the gateway is able 637 to correlate an unselected media stream with a particular early 638 dialog established using a reliable provisional response, it MAY use 639 the UPDATE method [19] to stop that stream and then use the UPDATE 640 method to start that stream again if a 2xx response is received on 641 that dialog. 643 On receipt of a QSIG SETUP message containing a Sending complete 644 information element and a number that the gateway determines to be 645 incomplete in the Called party number information element, the 646 gateway SHALL initiate QSIG call clearing procedures using cause 647 value 28 "invalid number format (address incomplete)". 649 If information in the QSIG SETUP message is unsuitable for generating 650 any of the mandatory fields in a SIP INVITE request (e.g., if a 651 Request-URI cannot be derived from the QSIG Called party number 652 information element) or for generating SDP information, the gateway 653 SHALL NOT issue a SIP INVITE request and SHALL initiate QSIG call 654 clearing procedures in accordance with [2]. 656 8.2.1.2 Receipt of SIP 100 (Trying) response to an INVITE request 657 A SIP 100 response SHALL NOT trigger any QSIG messages. It only 658 serves the purpose of suppressing INVITE request retransmissions. 660 8.2.1.3 Receipt of SIP 18x provisional response to an INVITE request 662 The gateway SHALL map a received SIP 18x response to an INVITE 663 request to a QSIG PROGRESS or ALERTING message based on the following 664 conditions. 666 - If a SIP 180 response is received and no QSIG ALERTING message has 667 been sent, the gateway SHALL generate a QSIG ALERTING message. The 668 gateway MAY supply ring-back tone on the user information channel of 669 the inter-PINX link, in which case the gateway SHALL include progress 670 description number 8 in the QSIG ALERTING message. Otherwise the 671 gateway SHALL NOT include progress description number 8 in the QSIG 672 ALERTING message unless the gateway is aware that in-band information 673 (e.g., ring-back tone) is being transmitted. 675 - If a SIP 181/182/183 response is received, no QSIG ALERTING message 676 has been sent and no message containing progress description number 1 677 has been sent, the gateway SHALL generate a QSIG PROGRESS message 678 containing progress description number 1. 680 NOTE. This will ensure that QSIG timer T310 is stopped if running at 681 the Originating PINX. 683 In all other scenarios the gateway SHALL NOT map the SIP 18x response 684 to a QSIG message. 686 If the SIP 18x response contains a Require header with option tag 687 100rel, the gateway SHALL send back a SIP PRACK request in accordance 688 with [11]. 690 8.2.1.4 Receipt of SIP 2xx response to an INVITE request 692 If the gateway receives a SIP 2xx response as the first SIP 2xx 693 response to a SIP INVITE request, the gateway SHALL map the SIP 2xx 694 response to a QSIG CONNECT message. The gateway SHALL also send a SIP 695 ACK request to acknowledge the 2xx response. The gateway SHALL NOT 696 include any SDP information in the SIP ACK request. If the gateway 697 receives further 2xx responses, it SHALL respond to each in 698 accordance with [10], SHOULD issue a BYE request for each and SHALL 699 NOT generate any further QSIG messages. 701 Media streams will normally have been established in the IP network 702 in each direction. If so, the gateway SHALL connect the media streams 703 to the corresponding user-information channel on the inter-PINX link 704 if it has not already done so and stop any local ring-back tone. 706 If the SIP 2xx response is received in response to the SIP PRACK 707 request, the gateway SHALL NOT map this message to any QSIG message. 709 NOTE. A SIP 2xx response to the INVITE request can be received later 710 on a different dialog as a result of a forking proxy. 712 8.2.1.5 Receipt of SIP 3xx response to an INVITE request 714 On receipt of a SIP 3xx response to an INVITE request, the gateway 715 SHALL act in accordance with [10]. 717 NOTE. This will normally result in sending a new SIP INVITE request. 719 Unless the gateway supports the QSIG Call Diversion Supplementary 720 Service, no QSIG message SHALL be sent. The definition of Call 721 Diversion Supplementary Service for QSIG to SIP interworking is 722 beyond the scope of this specification. 724 8.2.2 Call establishment from QSIG to SIP using overlap procedures 726 SIP uses en-bloc signalling and it is strongly RECOMMENDED to avoid 727 using overlap signalling in a SIP network. A SIP/QSIG gateway dealing 728 with overlap signalling, SHOULD perform a conversion from overlap to 729 en-bloc signalling method using one or more of the following 730 mechanisms: 732 -timers; 734 -numbering plan information; 736 -the presence of a Sending complete information element in a received 737 QSIG INFORMATION message. 739 If the gateway performs a conversion from overlap to en-bloc 740 signalling in the SIP network then the procedures defined in 8.2.2.1 741 SHALL apply. 743 However, for some applications it might be impossible to avoid using 744 overlap signalling in the SIP network. In this case the procedures 745 defined in 8.2.2.2 SHALL apply. 747 8.2.2.1 Enbloc signalling in SIP network 749 8.2.2.1.1 Receipt of QSIG SETUP message 751 On receipt of a QSIG SETUP message containing no Sending complete 752 information element and a number in the Called party number 753 information element that the gateway cannot determine to be complete, 754 the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start 755 QSIG timer T302 and await further number digits. 757 8.2.2.1.2 Receipt of QSIG INFORMATION message 759 On receipt of each QSIG INFORMATION message containing no Sending 760 complete information element and containing a number that the gateway 761 cannot determine to be complete, QSIG timer T302 SHALL be restarted. 762 When QSIG timer T302 expires or a QSIG INFORMATION message containing 763 a Sending complete information element is received the gateway SHALL 764 send a SIP INVITE request as described in 8.2.1.1. The Request-URI 765 and To fields (see section 9) SHALL be generated from the 766 concatenation of information in the Called party number information 767 element in the received QSIG SETUP and INFORMATION messages. The 768 gateway SHALL also send a QSIG CALL PROCEEDING message. 770 8.2.2.1.3 Receipt of SIP responses to INVITE requests 772 SIP responses to INVITE requests SHALL be mapped as described in 773 8.2.1. 775 8.2.2.2 Overlap signalling in SIP network 777 The procedures below for using overlap signalling in the SIP network 778 are in accordance with the principles described in [18] for using 779 overlap sending when interworking with ISUP. In [18] there is 780 discussion of some potential problems arising from the use of overlap 781 sending in the SIP network. These potential problems are applicable 782 also in the context of QSIG-SIP interworking and can be avoided if 783 overlap sending in the QSIG network is terminated at the gateway, in 784 accordance with 8.2.2.1. The procedures below should be used only 785 where it is not feasible to use the procedures of 8.2.2.1. 787 8.2.2.2.1 Receipt of QSIG SETUP message 789 On receipt of a QSIG SETUP message containing no Sending complete 790 information element and a number in the Called party number 791 information element that the gateway cannot determine to be complete, 792 the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message and 793 start QSIG timer T302. If the QSIG SETUP message contains the minimum 794 number of digits required to route the call in the IP network, the 795 gateway SHALL send a SIP INVITE request as specified in 8.2.1.1. 796 Otherwise the gateway SHALL wait for more digits to arrive in QSIG 797 INFORMATION messages. 799 8.2.2.2.2 Receipt of QSIG INFORMATION message 801 On receipt of a QSIG INFORMATION message the gateway SHALL handle the 802 QSIG timer T302 in accordance with [2]. 804 NOTE 1. [2] requires the QSIG timer to be stopped if the INFORMATION 805 message contains a Sending complete information element or to be 806 restarted otherwise. 808 Further behaviour of the gateway SHALL depend on whether or not it 809 has already sent a SIP INVITE request. If the gateway has not sent a 810 SIP INVITE request and it now has the minimum number of digits 811 required to route the call, it SHALL send a SIP INVITE request as 812 specified in 8.2.2.1.2. If the gateway still does not have the 813 minimum number of digits required it SHALL wait for more QSIG 814 INFORMATION messages to arrive. 816 If the gateway has already sent one or more SIP INVITE requests, and 817 whether or not final responses to those requests have been received, 818 it SHALL send a new SIP INVITE request in accordance with 3.2 of 819 [18].The updated Request-URI and To fields (see section 9) SHALL be 820 generated from the concatenation of information in the Called party 821 number information element in the received QSIG SETUP and INFORMATION 822 messages. 824 NOTE 2. [18] requires the new request to have the same Call-ID and 825 the same From header (including tag) as in the previous INVITE 826 request. [18] recommends that the CSeq header should contain a value 827 higher than that in the previous INVITE request. 829 8.2.2.2.3 Receipt of SIP 100 (Trying) response to an INVITE request 831 The requirements of 8.2.1.2 SHALL apply. 833 8.2.2.2.4 Receipt of SIP 18x provisional response to an INVITE request 835 The requirements of 8.2.1.3 SHALL apply. 837 8.2.2.2.5 Receipt of SIP 2xx response to an INVITE request 839 The requirements of 8.2.1.4 SHALL apply. In addition the gateway 840 SHALL send a SIP CANCEL request in accordance with 3.4 of [18] to 841 cancel any SIP INVITE transactions for which no final response has 842 been received. 844 8.2.2.2.6 Receipt of SIP 3xx response to an INVITE request 846 The requirements of 8.2.1.5 SHALL apply. 848 8.2.2.2.7 Receipt of a SIP 4xx, 5xx or 6xx final response to an INVITE 849 request 851 On receipt of a SIP 4xx, 5xx or 6xx final response to an INVITE 852 request the gateway SHALL send back a SIP ACK request. Unless the 853 gateway is able to retry the INVITE request to avoid the problem 854 (e.g., by supplying authentication in the case of a 401 or 407 855 response), the gateway SHALL also send a QSIG DISCONNECT message 856 (8.4.4) if no further QSIG INFORMATION messages are expected and 857 final responses have been received to all transmitted SIP INVITE 858 requests. 860 NOTE 1. Further QSIG INFORMATION messages will not be expected after 861 QSIG timer T302 has expired or after a Sending complete information 862 element has been received. 864 In all other cases the receipt of a SIP 4xx, 5xx or 6xx final 865 response to an INVITE request SHALL NOT trigger the sending of any 866 QSIG message. 868 NOTE 2. If further QSIG INFORMATION messages arrive, these will 869 result in further SIP INVITE requests being sent, one of which might 870 result in successful call establishment. For example, initial INVITE 871 requests might produce 484 (Address Incomplete) or 404 (Not Found) 872 responses because the Request-URIs derived from incomplete numbers 873 cannot be routed, yet a subsequent INVITE request with a routable 874 Request-URI might produce a 2xx final response or a more meaningful 875 4xx, 5xx or 6xx final response. 877 8.2.2.2.8 Receipt of multiple SIP responses to an INVITE request 879 3.3 of [18] applies. 881 8.2.2.2.9 Cancelling pending SIP INVITE transactions 883 As stated in 3.4 of [18], when a gateway sends a new SIP INVITE 884 request containing new digits, it SHOULD NOT send a SIP CANCEL 885 request to cancel a previous SIP INVITE transaction that has not had 886 a final response. This SIP CANCEL request could arrive at an egress 887 gateway before the new SIP INVITE request and trigger premature call 888 clearing. 890 NOTE. Previous SIP INVITE transactions can be expected to result in 891 SIP 4xx class responses, which terminate the transaction. In 892 8.2.2.2.5 there is provision for cancelling any transactions still in 893 progress after a SIP 2xx response has been received. 895 8.2.2.2.10 QSIG timer T302 expiry 897 If QSIG timer T302 expires and the gateway has received 4xx, 5xx or 898 6xx responses to all transmitted SIP INVITE requests, the gateway 899 SHALL send a QSIG DISCONNECT message. If T302 expires and the gateway 900 has not received 4xx, 5xx or 6xx responses to all transmitted SIP 901 INVITE requests, the gateway SHALL ignore any further QSIG 902 INFORMATION messages but SHALL NOT send a QSIG DISCONNECT message at 903 this stage. 905 NOTE. A QSIG DISCONNECT request will be sent when all outstanding SIP 906 INVITE requests have received 4xx, 5xx or 6xx responses. 908 8.3 Call Establishment from SIP to QSIG 910 8.3.1 Receipt of SIP INVITE request for a new call 912 On receipt of a SIP INVITE request for a new call, and if a suitable 913 channel is available on the inter-PINX link, the gateway SHALL 914 generate a QSIG SETUP message from the received SIP INVITE request. 915 The gateway SHALL generate the Called party number and Calling party 916 number information elements in accordance with section 9 and SHALL 917 generate the Bearer capability information element in accordance with 918 section 10. If the gateway can determine that the number placed in 919 the Called party number information element is complete, the gateway 920 MAY include the Sending complete information element. 922 NOTE 1. The means by which the gateway determines the number to be 923 complete is an implementation matter. It can involve knowledge of the 924 numbering plan and/or use of the inter-digit timer. 926 The gateway SHOULD send a SIP 100 (Trying) response. 928 If information in the SIP INVITE request is unsuitable for generating 929 any of the mandatory information elements in a QSIG SETUP message 930 (e.g., if a QSIG Called party number information element cannot be 931 derived from SIP Request-URI field) or if no suitable channel is 932 available on the inter-PINX link, the gateway SHALL NOT issue a QSIG 933 SETUP message and SHALL send a SIP 4xx, 5xx or 6xx response. If no 934 suitable channel is available the gateway should use response code 935 503 (Service Unavailable). 937 If the SIP INVITE request does not contain SDP information and does 938 not contain either a Required header or a Supported header with 939 option tag 100rel, the gateway SHOULD still proceed as above, 940 although an implementation can instead send a SIP 488 (Not Acceptable 941 Here) response, in which case it SHALL NOT issue a QSIG SETUP 942 message. 944 NOTE 2. The absence of SDP offer information in the SIP INVITE 945 request means that the gateway might need to send SDP offer 946 information in a provisional response and receive SDP answer 947 information in a SIP PRACK request (in accordance with [11]) in order 948 to ensure that tones and announcements from the PISN are transmitted. 950 SDP offer information cannot be sent in an unreliable provisional 951 response because SDP answer information would need to be returned in 952 a SIP PRACK request. The recommendation above still to proceed with 953 call establishment in this situation reflects the desire to maximise 954 the chances of a successful call. However, if important in-band 955 information is likely to be denied in this situation, a gateway can 956 choose not to proceed. 958 NOTE 3. If SDP offer information is present in the INVITE request, 959 the issuing of a QSIG SETUP message is not dependent on the presence 960 of a Required header or a Supported header with option tag 100rel. 962 On receipt of a SIP INVITE request relating to a call that has 963 already been established from SIP to QSIG, the procedures of 8.3.9 964 SHALL apply. 966 8.3.2 Receipt of QSIG CALL PROCEEDING message 968 The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any 969 SIP message being sent. 971 8.3.3 Receipt of QSIG PROGRESS message 973 A QSIG PROGRESS message can be received in the event of interworking 974 on the remote side of the PISN or if the PISN is unable to complete 975 the call and generates an in-band tone or announcement. In the latter 976 case a Cause information element is included in the QSIG PROGRESS 977 message. 979 The gateway SHALL map a received QSIG PROGRESS message to a SIP 183 980 (Session Progress) response to the INVITE request. If the SIP INVITE 981 request contained either a Require header or a Supported header with 982 option tag 100rel, the gateway SHALL include in the SIP 183 response 983 a Require header with option tag 100rel. 985 NOTE. In accordance with [11], inclusion of option tag 100rel in a 986 provisional response instructs the UAC to acknowledge the provisional 987 response by sending a PRACK request. [11] also specifies procedures 988 for repeating a provisional response with option tag 100rel if no 989 PRACK is received. 991 If the QSIG PROGRESS message contained a Progress indicator 992 information element with Progress description number 1 or 8, the 993 gateway SHALL connect the media streams to the corresponding user 994 information channel of the inter-PINX link if it has not already done 995 so, provided SDP answer information is included in the transmitted 996 SIP response to the INVITE request or has already been sent or 997 received. Inclusion of SDP offer or answer information in the 183 998 provisional response SHALL be in accordance with 8.3.5. 1000 If the QSIG PROGRESS message is received with a Cause information 1001 element, the gateway SHALL either wait until the tone/announcement is 1002 complete or has been applied for sufficient time before initiating 1003 call clearing, or wait for a SIP CANCEL request. If call clearing is 1004 initiated, the cause value in the QSIG PROGRESS message SHALL be used 1005 to derive the response to the SIP INVITE request in accordance with 1006 table 1. 1008 8.3.4 Receipt of QSIG ALERTING message 1010 The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing) 1011 response to the INVITE request. If the SIP INVITE request contained 1012 either a Require header or a Supported header with option tag 100rel, 1013 the gateway SHALL include in the SIP 180 response a Require header 1014 with option tag 100rel. 1016 NOTE. In accordance with [11], inclusion of option tag 100rel in a 1017 provisional response instructs the UAC to acknowledge the provisional 1018 response by sending a PRACK request. [11] also specifies procedures 1019 for repeating a provisional response with option tag 100rel if no 1020 PRACK is received. 1022 If the QSIG ALERTING message contained a Progress indicator 1023 information element with Progress description number 1 or 8, the 1024 gateway SHALL connect the media streams to the corresponding user 1025 information channel of the inter-PINX link if it has not already done 1026 so, provided SDP answer information is included in the transmitted 1027 SIP response or has already been sent or received. Inclusion of SDP 1028 offer or answer information in the 180 provisional response SHALL be 1029 in accordance with 8.3.5. 1031 8.3.5 Inclusion of SDP information in a SIP 18x provisional response 1033 When sending a SIP 18x provisional response to the INVITE request, if 1034 a QSIG message containing a Progress indicator information element 1035 with progress description number 1 or 8 has been received the gateway 1036 SHALL include SDP information. Otherwise the gateway MAY include SDP 1037 information. If SDP information is included it shall be in accordance 1038 with the following rules. 1040 If the SIP INVITE request contained a Required or Supported header 1041 with option tag 100rel, and if SDP offer and answer information has 1042 already been exchanged, no SDP information SHALL be included in the 1043 SIP 18x provisional response. 1045 If the SIP INVITE request contained a Required or Supported header 1046 with option tag 100rel, and if SDP offer information was received in 1047 the SIP INVITE request but no SDP answer information has been sent, 1048 SDP answer information SHALL be included in the SIP 18x provisional 1049 response. 1051 If the SIP INVITE request contained a Required or Supported header 1052 with option tag 100rel, and if no SDP offer information was received 1053 in the SIP INVITE request and no SDP offer information has already 1054 been sent, SDP offer information SHALL be included in the SIP 18x 1055 provisional response. 1057 NOTE 1. In this case, SDP answer information can be expected in the 1058 SIP PRACK. 1060 If the SIP INVITE request contained neither a Required nor a 1061 Supported header with option tag 100rel, SDP answer information SHALL 1062 be included in the SIP 18x provisional response. 1064 NOTE 2. Because the provisional response is unreliable, SDP answer 1065 information needs to be repeated in each provisional response and in 1066 the final SIP 2xx response. 1068 NOTE 3. If the SIP INVITE request contained no SDP offer information 1069 and neither a Required nor a Supported header with option tag 100rel, 1070 it should have been rejected in accordance with 8.3.1. 1072 8.3.6 Receipt of QSIG CONNECT message 1074 The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final 1075 response for the SIP INVITE request. The gateway SHALL also send a 1076 QSIG CONNECT ACKNOWLEDGE message. 1078 If the SIP INVITE request contained a Required or Supported header 1079 with option tag 100rel, and if SDP offer and answer information has 1080 already been exchanged, no SDP information SHALL be included in the 1081 SIP 200 response. 1083 If the SIP INVITE request contained a Required or Supported header 1084 with option tag 100rel, and if SDP offer information was received in 1085 the SIP INVITE request but no SDP answer information has been sent, 1086 SDP answer information SHALL be included in the SIP 200 response. 1088 If the SIP INVITE request contained a Required or Supported header 1089 with option tag 100rel, and if no SDP offer information was received 1090 in the SIP INVITE request and no SDP offer information has already 1091 been sent, SDP offer information SHALL be included in the SIP 200 1092 response. 1094 NOTE 1. In this case, SDP answer information can be expected in the 1095 SIP ACK. 1097 If the SIP INVITE request contained neither a Required nor a 1098 Supported header with option tag 100rel, SDP answer information SHALL 1099 be included in the SIP 200 response. 1101 NOTE 2. Because the provisional response is unreliable, SDP answer 1102 information needs to be repeated in each provisional response and in 1103 the final 2xx response. 1105 NOTE 3. If the SIP INVITE request contained no SDP offer information 1106 and neither a Required nor a Supported header with option tag 100rel, 1107 it may have been rejected in accordance with 8.3.1. 1109 The gateway SHALL connect the media streams to the corresponding user 1110 information channel of the inter-PINX link if it has not already done 1111 so, provided SDP answer information is included in the transmitted 1112 SIP response or has already been sent or received. 1114 8.3.7 Receipt of SIP PRACK request 1116 The receipt of a SIP PRACK request acknowledging a reliable 1117 provisional response SHALL NOT result in any QSIG message being sent. 1118 The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK 1119 request. 1121 If the SIP PRACK contains SDP answer information and a QSIG message 1122 containing a Progress indicator information element with progress 1123 description number 1 or 8 has been received, the gateway SHALL 1124 connect the media streams to the corresponding user information 1125 channel of the inter-PINX link. 1127 8.3.8 Receipt of SIP ACK request 1129 The receipt of a SIP ACK request SHALL NOT result in any QSIG message 1130 being sent. 1132 If the SIP ACK contains SDP answer information, the gateway SHALL 1133 connect the media streams to the corresponding user information 1134 channel of the inter-PINX link if it has not already done so. 1136 8.3.9 Receipt of a SIP INVITE request for a call already being 1137 established 1139 A gateway can receive a call from SIP using overlap procedures. This 1140 should occur when the UAC for the INVITE request is a gateway from a 1141 network that employs overlap procedures (e.g., an ISUP gateway or 1142 another QSIG gateway) and the gateway has not absorbed overlap. 1144 For a call from SIP using overlap procedures, the gateway will 1145 receive multiple SIP INVITE requests that belong to the same call but 1146 have different Request-URI and To fields. Each SIP INVITE request 1147 belongs to a different dialog. 1149 A SIP INVITE request is considered to be for the purpose of overlap 1150 sending if, compared to a previously received SIP INVITE request, it 1151 has: 1153 - the same Call-ID header; 1154 - the same From header (including the tag); 1155 - no tag in the To header; 1156 - an updated Request-URI from which can be derived a called party 1157 number with a superset of the digits derived from the previously 1158 received SIP INVITE request; 1159 - the gateway has not yet sent a final response other than 484 to the 1160 previously received SIP INVITE request. 1162 If a gateway receives a SIP INVITE request for the purpose of overlap 1163 sending, it SHALL generate a QSIG INFORMATION message using the call 1164 reference of the existing QSIG call instead of a new QSIG SETUP 1165 message and containing only the additional digits in the Called party 1166 number information element. It SHALL also respond to the SIP INVITE 1167 request received previously with a SIP 484 Address Incomplete 1168 response. 1170 If a gateway receives a SIP INVITE request that meets all of the 1171 conditions for a SIP INVITE request for the purpose of overlap 1172 sending except the condition concerning the Request-URI, the gateway 1173 SHALL respond to the new request with a SIP 485 (Ambiguous) response. 1175 8.4 Call clearing and call failure 1177 8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message 1179 On receipt of QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message as 1180 the first QSIG call clearing message, gateway behaviour SHALL depend 1181 on the state of call establishment. 1183 1)If the gateway has sent a SIP 200 (OK) response to a SIP INVITE 1184 request and received a SIP ACK request or has received a SIP 200 (OK) 1185 response to a SIP INVITE request and sent a SIP ACK request, the 1186 gateway SHALL send a SIP BYE request to clear the call. 1188 2)If the gateway has sent a SIP 200 (OK) response to a SIP INVITE 1189 request (indicating that call establishment is complete) but has not 1190 received a SIP ACK request, the gateway SHALL wait until a SIP ACK is 1191 received and then send a SIP BYE request to clear the call. 1193 3)If the gateway has sent a SIP INVITE request and received a SIP 1194 provisional response but not a SIP final response, the gateway SHALL 1195 send a SIP CANCEL request to clear the call. 1197 NOTE 1. In accordance with [10], if after sending a SIP CANCEL 1198 request a SIP 2xx response is received to the SIP INVITE request, the 1199 gateway will need to send a SIP BYE request. 1201 4)If the gateway has sent a SIP INVITE request but received no SIP 1202 response, the gateway SHALL NOT send a SIP message. If a SIP final or 1203 provisional response is subsequently received, the gateway SHALL then 1204 act in accordance with 1, 2 or 3 above respectively. 1206 5)If the gateway has received a SIP INVITE request but not sent a SIP 1207 final response, the gateway SHALL send a SIP final response chosen 1208 according to the cause value in the received QSIG message as 1209 specified in table 1. SIP response 500 (Server internal error) SHALL 1210 be used as the default for cause values not shown in table 1. 1212 NOTE 2. It is not necessarily appropriate to map some QSIG cause 1213 values to SIP messages because these cause values are meaningful only 1214 at the gateway. A good example of this is cause value 44 "Requested 1215 circuit or channel not available", which signifies that the channel 1216 number in the transmitted QSIG SETUP message was not acceptable to 1217 the peer PINX. The appropriate behavior in this case is for the 1218 gateway to send another SETUP message indicating a different channel 1219 number. If this is not possible, the gateway should treat it either 1220 as a congestion situation (no channels available, see 8.3.1) or as a 1221 gateway failure situation (in which case the default SIP response 1222 code applies). 1224 In all cases the gateway SHALL also disconnect media streams, if 1225 established, and allow QSIG and SIP signalling to complete in 1226 accordance with [2] and [10] respectively. 1228 Table 1 - Mapping of QSIG Cause Value to SIP 4xx-6xx responses to an 1229 INVITE request 1231 QSIG Cause value SIP response 1232 1 Unallocated number 404 Not found 1233 2 No route to specified 404 Not found 1234 transit network 1235 3 No route to destination 404 Not found 1236 16 Normal call clearing (NOTE 3) 1237 17 User busy 486 Busy here 1238 18 No user responding 408 Request timeout 1239 19 No answer from the user 480 Temporarily unavailable 1240 20 Subscriber absent 480 Temporarily unavailable 1241 21 Call rejected 603 Decline, if location field 1242 in Cause information element 1243 indicates user. Otherwise: 1244 403 Forbidden 1245 22 Number changed 301 Moved permanently, if 1246 information in diagnostic field 1247 of Cause information element is 1248 suitable for generating a SIP 1249 Contact header. Otherwise: 1250 410 Gone 1251 23 Redirection to new 410 Gone 1252 destination 1253 27 Destination out of order 502 Bad gateway 1254 28 Address incomplete 484 Address incomplete 1255 29 Facility rejected 501 Not implemented 1256 31 Normal, unspecified 480 Temporarily unavailable 1257 34 No circuit/channel 503 Service unavailable 1258 available 1259 38 Network out of order 503 Service unavailable 1260 41 Temporary failure 503 Service unavailable 1261 42 Switching equipment 503 Service unavailable 1262 congestion 1263 47 Resource unavailable, 503 Service unavailable 1264 unspecified 1265 55 Incoming calls barred 403 Forbidden 1266 within CUG 1267 57 Bearer capability not 403 Forbidden 1268 authorized 1269 58 Bearer capability not 503 Service unavailable 1270 presently available 1271 65 Bearer capability not 488 Not acceptable here (NOTE 1272 implemented 4) 1273 69 Requested facility not 501 Not implemented 1274 implemented 1275 70 Only restricted digital 488 Not acceptable here (NOTE 1276 information available 4) 1277 79 Service or option not 501 Not implemented 1278 implemented, unspecified 1279 87 User not member of CUG 403 Forbidden 1280 88 Incompatible destination 503 Service unavailable 1281 102 Recovery on timer expiry 504 Server time-out 1283 NOTE 3. A QSIG call clearing message containing cause value 16 will 1284 normally result in the sending of a SIP BYE or CANCEL request. 1285 However, if a SIP response is to be sent to the INVITE request, the 1286 default response code should be used. 1288 NOTE 4. The gateway may include a SIP Warning header if diagnostic 1289 information in the QSIG Cause information element allows a suitable 1290 warning code to be selected. 1292 8.4.2 Receipt of a SIP BYE request 1294 On receipt of a SIP BYE request, the gateway SHALL send a QSIG 1295 DISCONNECT message with cause value 16 (normal call clearing). The 1296 gateway SHALL also disconnect media streams, if established, and 1297 allow QSIG and SIP signalling to complete in accordance with [2] and 1298 [10] respectively. 1300 NOTE. When responding to a SIP BYE request, in accordance with [10] 1301 the gateway is also required to respond to any other outstanding 1302 transactions, e.g., with a SIP 487 (Request Terminated) response. 1303 This applies in particular if the gateway has not yet returned a 1304 final response to the SIP INVITE request. 1306 8.4.3 Receipt of a SIP CANCEL request 1308 On receipt of a SIP CANCEL request to clear a call for which the 1309 gateway has not sent a SIP final response to the received SIP INVITE 1310 request, the gateway SHALL send a QSIG DISCONNECT message with cause 1311 value 16 (normal call clearing). The gateway SHALL also disconnect 1312 media streams, if established, and allow QSIG and SIP signalling to 1313 complete in accordance with [2] and [10] respectively. 1315 8.4.4 Receipt of a SIP 4xx - 6xx response to an INVITE request 1317 Except where otherwise specified in the context of overlap sending 1318 (8.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP 1319 INVITE request, unless the gateway is able to retry the INVITE 1320 request to avoid the problem (e.g., by supplying authentication in 1321 the case of a 401 or 407 response), the gateway SHALL transmit a QSIG 1322 DISCONNECT message. The cause value in the QSIG DISCONNECT message 1323 SHALL be derived from the SIP 4xx-6xx response according to table 2. 1324 Cause value 31 (Normal, unspecified) SHALL be used as the default for 1325 SIP responses not shown in table 2. The gateway SHALL also disconnect 1326 media streams, if established, and allow QSIG and SIP signalling to 1327 complete in accordance with [2] and [10] respectively. 1329 When generating a QSIG Cause information element, the location field 1330 SHOULD contain the value "user" if generated as a result of a SIP 1331 response code 6xx or the value "Private network serving the remote 1332 user" in other circumstances. 1334 Table 2 - Mapping of SIP 4xx-6xx responses to an INVITE request to 1335 QSIG Cause values 1337 SIP response QSIG Cause value (NOTE 2) 1338 400 Bad request 41 Temporary failure 1339 401 Unauthorized 21 Call rejected (NOTE 1) 1340 402 Payment required 21 Call rejected 1341 403 Forbidden 21 Call rejected 1342 404 Not found 1 Unallocated number 1343 405 Method not allowed 63 Service or option 1344 unavailable, unspecified 1345 406 Not acceptable 79 Service or option not 1346 implemented, unspecified 1347 407 Proxy Authentication required 21 Call rejected (NOTE 1) 1348 408 Request timeout 102 Recovery on timer expiry 1349 410 Gone 22 Number changed 1350 413 Request entity too large 127 Interworking, unspecified 1351 (NOTE 2) 1352 414 Request-URI too long 127 Interworking, unspecified 1353 (NOTE 2) 1354 415 Unsupported media type 79 Service or option not 1355 implemented, unspecified (NOTE 1356 2) 1357 416 Unsupported URI scheme 127 Interworking, unspecified 1358 (NOTE 2) 1359 420 Bad extension 127 Interworking, unspecified 1360 (NOTE 2) 1361 421 Extension required 127 Interworking, unspecified 1362 (NOTE 2) 1363 423 Interval too brief 127 Interworking, unspecified 1364 (NOTE 2) 1365 480 Temporarily unavailable 18 No user responding 1366 481 Call/transaction does not exist 41 Temporary failure 1367 482 Loop detected 25 Exchange routing error 1368 483 Too many hops 25 Exchange routing error 1369 484 Address incomplete 28 Invalid number format (NOTE 1370 2) 1371 485 Ambiguous 1 Unallocated Number 1372 486 Busy here 17 User busy 1373 487 Request terminated (NOTE 3) 1374 488 Not Acceptable Here 65 Bearer capability not 1375 implemented or 31 Normal, 1376 unspecified(NOTE 4) 1377 500 Server internal error 41 Temporary failure 1378 501 Not implemented 79 Service or option not 1379 implemented, unspecified 1380 502 Bad gateway 38 Network out of order 1381 503 Service unavailable 41 Temporary failure 1382 504 Gateway time-out 102 Recovery on timer expiry 1383 505 Version not supported 127 Interworking, unspecified 1384 (NOTE 2) 1385 513 Message too large 127 Interworking, unspecified 1386 (NOTE 2) 1387 600 Busy everywhere 17 User busy 1388 603 Decline 21 Call rejected 1389 604 Does not exist anywhere 1 Unallocated number 1390 606 Not acceptable 65 Bearer capability not 1391 implemented or 1392 31 Normal, unspecified(NOTE 4) 1394 NOTE 1. In some cases, it may be possible for the gateway to provide 1395 credentials to the SIP UAS that is rejecting an INVITE due to 1396 authorization failure. If the gateway can authenticate itself, then 1397 obviously it should do so and proceed with the call. Only if the 1398 gateway cannot authorize itself should the gateway clear the call in 1399 the QSIG network with this cause value. 1401 NOTE 2. For some response codes the gateway may be able to retry the 1402 INVITE request in order to work around the problem. In particular, 1403 this may be the case with response codes indicating a protocol error. 1404 The gateway SHOULD clear the call in the QSIG network with the 1405 indicated cause value only if retry is not possible or fails. 1407 NOTE 3. The circumstances in which SIP response code 487 can be 1408 expected to arise do not require it to be mapped to a QSIG cause 1409 code, since the QSIG call will normally already be cleared or in the 1410 process of clearing. If QSIG call clearing does, however, need to be 1411 initiated, the default cause value should be used. 1413 NOTE 4. When the Warning header is present in a SIP 606 or 488 1414 message, the warning code should be examined to determine whether it 1415 is reasonable to generate cause value 65. This cause value should be 1416 generated only if there is a chance that a new call attempt with 1417 different content in the Bearer capability information element will 1418 avoid the problem. In other circumstances the default cause value 1419 should be used. 1421 8.4.5 Gateway-initiated call clearing 1423 If the gateway initiates clearing of the QSIG call owing to QSIG 1424 timer expiry, QSIG protocol error or use of the QSIG RESTART message 1425 in accordance with [2], the gateway SHALL also initiate clearing of 1426 the SIP call in accordance with 8.4.1. If this involves the sending 1427 of a final response to a SIP INVITE request, the gateway SHALL use 1428 response code 480 (Temporarily Unavailable) if optional QSIG timer 1429 T301 has expired or otherwise response code 408 (Request timeout) or 1430 500 (Server internal error) as appropriate. 1432 If the gateway initiates clearing of the SIP call owing to SIP timer 1433 expiry or SIP protocol error in accordance with [10], the gateway 1434 SHALL also initiate clearing of the QSIG call in accordance with [2] 1435 using cause value 102 (Recovery on timer expiry) or 41 (Temporary 1436 failure) as appropriate. 1438 8.5 Request to change media characteristics 1440 If after a call has been successfully established the gateway 1441 receives a SIP INVITE request to change the media characteristics of 1442 the call in a way that would be incompatible with the bearer 1443 capability in use within the PISN, the gateway SHALL send back a SIP 1444 488 (Not Acceptable Here) response and SHALL NOT change the media 1445 characteristics of the existing call. 1447 9 Number mapping 1449 In QSIG, users are identified by numbers, as defined in [1]. Numbers 1450 are conveyed within the Called party number, Calling party number and 1451 Connected number information elements. The Calling party number and 1452 Connected number information elements also contain a presentation 1453 indicator, which can indicate that privacy is required (presentation 1454 restricted) and a screening indicator that indicates the source and 1455 authentication status of the number. 1457 In SIP, users are identified by Universal Resource Identifiers (URIs) 1458 conveyed within the Request-URI and various headers, including the 1459 From and To headers specified in [10] and optionally the P-Asserted- 1460 Identity header specified in [14]. In addition, privacy is indicated 1461 by the Privacy header specified in [13]. 1463 This clause specifies the mapping between QSIG Called party number, 1464 Calling party number and Connected number information elements and 1465 corresponding elements in SIP. 1467 A gateway MAY implement the P-Asserted-Identity header in accordance 1468 with [14]. If a gateway implements the P-Asserted-Identity header it 1469 SHALL also implement the Privacy header in accordance with [13]. If a 1470 gateway does not implement the P-Asserted-Identity header it MAY 1471 implement the Privacy header. 1473 9.1 Mapping from QSIG to SIP 1475 The method used to convert a number to a URI is outside the scope of 1476 this specification. However, the gateway SHOULD take account of the 1477 Numbering Plan (NPI) and Type Of Number (TON) fields in the QSIG 1478 information element concerned when interpreting a number. 1480 Some aspects of mapping depend on whether the gateway trusts the next 1481 hop SIP node (i.e., the proxy or UA to which the INVITE request is 1482 sent or from which INVITE request is received) to honour requests for 1483 identity privacy in the Privacy header. This will be network- 1484 dependent and it is RECOMMENDED that gateways supporting the P- 1485 Asserted-Identity header hold a configurable list of next hop nodes 1486 that are to be trusted in this respect. 1488 9.1.1 Using information from the QSIG Called party number information 1489 element 1491 When mapping a QSIG SETUP message to a SIP INVITE request, the 1492 gateway SHALL convert the number in the QSIG Called party number 1493 information to a URI and include that URI in the SIP Request-URI and 1494 in the To header. 1496 9.1.2 Using information from the QSIG Calling party number information 1497 element 1499 When mapping a QSIG SETUP message to a SIP INVITE request, the 1500 gateway SHALL use the Calling party number information element, if 1501 present, as follows. 1503 If the information element contains a number, the gateway SHALL 1504 attempt to derive a URI from that number. Further behaviour depends 1505 on whether a URI has been derived and the value of the presentation 1506 indication. 1508 9.1.2.1 No URI derived and presentation indicator does not have value 1509 "presentation restricted" 1511 In this case (including the case where the Calling party number 1512 information element is absent) the gateway SHALL include a URI 1513 identifying the gateway in the From header. Also, if the gateway 1514 supports the mechanism defined in [14], the gateway SHALL NOT 1515 generate a P-Asserted-Identity header. 1517 9.1.2.2 No URI derived and presentation indicator has value 1518 "presentation restricted" 1520 In this case the gateway SHALL generate an anonymous From header. 1521 Also, if the gateway supports the mechanism defined in [14], the 1522 gateway SHALL generate a Privacy header field with parameter priv- 1523 value = "id" and SHALL NOT generate a P-Asserted-Identity header. The 1524 inclusion of additional values of the priv-value parameter in the 1525 Privacy header is outside the scope of this specification. 1527 9.1.2.3 URI derived and presentation indicator has value "presentation 1528 restricted" 1530 If the gateway supports the P-Asserted-Identity header and trusts the 1531 next hop proxy to honour the Privacy header, the gateway SHALL 1532 generate a P-Asserted-Identity header containing the derived URI, 1533 SHALL generate a Privacy header with parameter priv-value = "id" and 1534 SHALL generate an anonymous From header. The inclusion of additional 1535 values of the priv-value parameter in the Privacy header is outside 1536 the scope of this specification. 1538 If the gateway does not support the P-Asserted-Identity header or 1539 does not trust the proxy to honour the Privacy header, the gateway 1540 SHALL behave as in 9.1.2.2. 1542 9.1.2.4 URI derived and presentation indicator does not have value 1543 "presentation restricted" 1545 In this case the gateway SHALL generate a P-Asserted-Identity header 1546 containing the derived URI if the gateway supports this header, SHALL 1547 NOT generate a Privacy header and SHALL include the derived URI in 1548 the From header. In addition, the gateway MAY use S/MIME as described 1549 in section 23 of [10] to sign a copy of the From header included in a 1550 message/sipfrag body of the INVITE request as described in [20]. 1552 9.1.3 Using information from the QSIG Connected number information 1553 element 1555 When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an 1556 INVITE request, the gateway SHALL use the Connected number 1557 information element, if present, as follows. 1559 If the information element contains a number, the gateway SHALL 1560 attempt to derive a URI from that number. Further behaviour depends 1561 on whether a URI has been derived and the value of the presentation 1562 indication. 1564 9.1.3.1 No URI derived and presentation indicator does not have value 1565 "presentation restricted" 1567 In this case (including the case where the Connected number 1568 information element is absent) the gateway SHALL NOT generate a P- 1569 Asserted-Identity header and SHALL NOT generate a Privacy header. 1571 9.1.3.2 No URI derived and presentation indicator has value 1572 "presentation restricted" 1574 In this case, if the gateway supports the mechanism defined in [14], 1575 the gateway SHALL generate a Privacy header field with parameter 1576 priv-value = "id" and SHALL NOT generate a P-Asserted-Identity 1577 header. The inclusion of additional values of the priv-value 1578 parameter in the Privacy header is outside the scope of this 1579 specification. 1581 9.1.3.3 URI derived and presentation indicator has value "presentation 1582 restricted" 1584 If the gateway supports the P-Asserted-Identity header and trusts the 1585 next hop proxy to honour the Privacy header, the gateway SHALL 1586 generate a P-Asserted-Identity header containing the derived URI and 1587 SHALL generate a Privacy header with parameter priv-value = "id". The 1588 inclusion of additional values of the priv-value parameter in the 1589 Privacy header is outside the scope of this specification. 1591 If the gateway does not support the P-Asserted-Identity header or 1592 does not trust the proxy to honour the Privacy header, the gateway 1593 SHALL behave as in 9.1.3.2. 1595 9.1.3.4 URI derived and presentation indicator does not have value 1596 "presentation restricted" 1598 In this case the gateway SHALL generate a P-Asserted-Identity header 1599 containing the derived URI if the gateway supports this header and 1600 SHALL NOT generate a Privacy header. In addition, the gateway MAY use 1601 S/MIME as described in section 23 of [10] to sign a To header 1602 containing the derived URI, the To header being included in a 1603 message/sipfrag body of the INVITE response as described in [20]. 1605 NOTE. The To header in the message/sipfrag body may differ from the 1606 to header in the response's headers. 1608 9.2 Mapping from SIP to QSIG 1610 The method used to convert a URI to a number is outside the scope of 1611 this specification. However, NPI and TON fields in the QSIG 1612 information element concerned SHALL be set to appropriate values in 1613 accordance with [1]. 1615 Some aspects of mapping depend on whether the gateway trusts the next 1616 hop SIP node (i.e., the proxy or UA to which the INVITE request is 1617 sent or from which INVITE request is received) to provide accurate 1618 information in the P-Asserted-Identity header. This will be network- 1619 dependent and it is RECOMMENDED that gateways hold a configurable 1620 list of next hop nodes that are to be trusted in this respect. 1622 Some aspects of mapping depend on whether the gateway is prepared to 1623 use a URI in the From header to derive a number for the Calling party 1624 number information element. The default behaviour SHOULD be not to 1625 use an unsigned or unvalidated From header for this purpose, since in 1626 principle the information comes from an untrusted source (the remote 1627 UA). However, it is recognised that some network administrations may 1628 consider that the benefits to be derived from supplying a calling 1629 party number outweigh any risks of supplying false information. 1631 Therefore a gateway MAY be configurable to use the an unsigned or 1632 unvalidated From header for this purpose. 1634 9.2.1 Generating the QSIG Called party number information element 1636 When mapping a SIP INVITE request to a QSIG SETUP message, the 1637 gateway SHALL convert the URI in the SIP Request-URI to a number and 1638 include that number in the QSIG Called party number information 1639 element. 1641 NOTE. The To header should not be used for this purpose. This is 1642 because re-targeting of the request in the SIP network can change the 1643 Request-URI but leave the To header unchanged. It is important that 1644 routing in the QSIG network be based on the final target from the SIP 1645 network. 1647 9.2.2 Generating the QSIG Calling party number information element 1649 When mapping a SIP INVITE request to a QSIG SETUP message, the 1650 gateway SHALL generate a Calling party number information element as 1651 follows. 1653 If the SIP INVITE request contains an S/MIME signed message/sipfrag 1654 body [20] containing a From header and the gateway supports this 1655 capability and can verify the authenticity and trustworthiness of 1656 this information, the gateway SHALL attempt to derive a number from 1657 the URI in that header. If no number is derived from a 1658 message/sipfrag body and if the SIP INVITE request contains a P- 1659 Asserted-Identity header and the gateway supports that header and 1660 trusts the information therein, the gateway SHALL attempt to derive a 1661 number from the URI in that header. If a number is derived from one 1662 of these headers, the gateway SHALL include it in the Calling party 1663 number information element and include value "network provided" in 1664 the screening indicator. 1666 If no number is derivable as described above and if the gateway is 1667 prepared to use the unsigned or unvalidated From header, the gateway 1668 SHALL attempt to derive a number from the URI in the From header. If 1669 a number is derived from the From header, the gateway SHALL include 1670 it in the Calling party number information element and include value 1671 "user provided, not screened" in the screening indicator. 1673 If no number is derivable, the gateway SHALL NOT include a number in 1674 the Calling party number information element. 1676 If the SIP INVITE request contains a Privacy header with value "id" 1677 in parameter priv-value and the gateway supports this header, the 1678 gateway SHALL include value "presentation restricted" in the 1679 presentation indicator. Based on local policy, the gateway MAY use 1680 the presence of other priv-values to set the presentation indicator 1681 to "presentation restricted". Otherwise the gateway SHALL include 1682 value "presentation allowed" if a number is present or "not available 1683 due to interworking" if no number is present. 1685 If the resulting Calling party number information element contains no 1686 number and value "not available due to interworking" in the 1687 presentation indicator, the gateway MAY omit the information element 1688 from the QSIG SETUP message. 1690 9.2.3 Generating the QSIG Connected number information element 1692 When mapping a SIP 2xx response to an INVITE request to a QSIG 1693 CONNECT message, the gateway SHALL generate a Connected number 1694 information element as follows. 1696 If the SIP 2xx response contains an S/MIME signed message/sipfrag 1697 [20] body containing a To header and the gateway supports this 1698 capability and can verify the authenticity and trustworthiness of 1699 this information, the gateway SHALL attempt to derive a number from 1700 the URI in that header. If no number is derived from a 1701 message/sipfrag body and if the SIP 2xx response contains a P- 1702 Asserted-Identity header and the gateway supports that header and 1703 trusts the information therein, the gateway SHALL attempt to derive a 1704 number from the URI in that header. If a number is derived from one 1705 of these headers, the gateway SHALL include it in the Connected 1706 number information element and include value "network provided" in 1707 the screening indicator. 1709 If no number is derivable as described above, the gateway SHOULD NOT 1710 include a number in the Connected number information element. 1712 If the SIP 2xx response contains a Privacy header with value "id" in 1713 parameter priv-value and the gateway supports this header, the 1714 gateway SHALL include value "presentation restricted" in the 1715 presentation indicator. Based on local policy, the gateway MAY use 1716 the presence of other priv-values to set the presentation indicator 1717 to "presentation restricted". Otherwise the gateway SHALL include 1718 value "presentation allowed" if a number is present or "not available 1719 due to interworking" if no number is present. 1721 If the resulting Connected number information element contains no 1722 number and value "not available due to interworking" in the 1723 presentation indicator, the gateway MAY omit the information element 1724 from the QSIG CONNECT message. 1726 10 Requirements for support of basic services 1727 This document specifies signalling interworking for basic services 1728 that provide a bi-directional transfer capability for speech, 1729 facsimile and modem media between the two networks. 1731 10.1 Derivation of QSIG Bearer capability information element 1733 The gateway SHALL generate the Bearer Capability Information Element 1734 in the QSIG SETUP message based on SDP offer information received 1735 along with the SIP INVITE request. If the SIP INVITE request does not 1736 contain SDP offer information or the media type in the SDP offer 1737 information is only 'audio' then the Bearer capability information 1738 element SHALL BE generated according to table 3. Coding of the Bearer 1739 capability information element for other media types is outside the 1740 scope of this specification. 1742 In addition, the gateway MAY include a Low layer compatibility 1743 information element and/or High layer compatibility information in 1744 the QSIG SETUP message if the gateway is able to derive relevant 1745 information from the SDP offer information. Specific mappings are 1746 outside the scope of this specification. 1748 Table 3 - Bearer capability encoding for 'audio' transfer 1750 Field Value 1751 Coding Standard "CCITT standardized coding" (00) 1752 Information transfer "3,1 kHz audio" (10000) 1753 capability 1754 Transfer mode "circuit mode" (00) 1755 Information transfer rate "64 Kbits/s" (10000) 1756 Multiplier Octet omitted 1757 User information layer 1 Generated by gateway based on 1758 protocol Information of the PISN. Supported 1759 values are 1760 "CCITT recommendation G.711 mu-law" 1761 (00010) 1762 "CCITT recommendation G.711 A-law" 1763 (00011) 1765 10.2 Derivation of media type in SDP 1767 The gateway SHALL generate SDP offer information to include in the 1768 SIP INVITE request based on information in the QSIG SETUP message. 1769 The gateway MAY take account of QSIG Low layer compatibility and/or 1770 High layer compatibility information elements, if present in the QSIG 1771 SETUP message, when deriving SDP offer information, in which case 1772 specific mappings are outside the scope of this specification. 1773 Otherwise the gateway shall generate SDP offer information based only 1774 on the Bearer capability information element in the QSIG SETUP 1775 message, in which case the media type SHALL be derived according to 1776 table 4. 1778 Table 4 - Media type setting in SDP based on Bearer capability 1779 information element 1781 Information transfer capability in Media type in SDP 1782 Bearer capability information element 1784 "speech" (00000) audio 1785 "3,1 kHz audio" (10000) audio 1787 11 Security considerations 1789 11.1 General 1791 Normal considerations apply for UA use of SIP security measures, 1792 including digest authentication, TLS and SMIME. 1794 The translation of QSIG information elements into SIP headers can 1795 introduce some privacy and security concerns. For example, care needs 1796 to be taken to provide adequate privacy for a user requesting 1797 presentation restriction if the Calling party number information 1798 element is openly mapped to the From header. Procedures for dealing 1799 with this particular situation are specified in 9.1.2. However, 1800 since the mapping specified in this document is mainly concerned with 1801 translating information elements into the headers and fields used to 1802 route SIP requests, gateways consequently reveal (through this 1803 translation process) the minimum possible amount of information. 1805 There are some concerns, however, that arise from the other direction 1806 of mapping, the mapping of SIP headers to QSIG information elements, 1807 which are enumerated in the following paragraphs. 1809 11.2 Calls from QSIG to invalid or restricted numbers 1811 When end users dial numbers in a PISN, their selections populate the 1812 Called party number information element in the QSIG SETUP message. 1813 Similarly, the SIP URI or tel URL and its optional parameters in the 1814 Request-URI of a SIP INVITE request, which can be created directly by 1815 end users of a SIP device, map to that information element at a 1816 gateway. However, in a PISN, policy can prevent the user from 1817 dialing certain (invalid or restricted) numbers. Thus, gateway 1818 implementers may wish to provide a means for gateway administrators 1819 to apply policies restricting the use of certain SIP URIs or tel 1820 URLs, or SIP URI or tel URL parameters, when authorizing a call from 1821 SIP to QSIG. 1823 11.3 Abuse of SIP response code 1825 Some additional risks may result from the SIP response code to QSIG 1826 cause value mapping. SIP user agents could conceivably respond to an 1827 INVITE request from a gateway with any arbitrary SIP response code, 1828 and thus they can dictate (within the boundaries of the mappings 1829 supported by the gateway) the Q.850 cause code that will be sent by 1830 the gateway in the resulting QSIG call clearing message. Generally 1831 speaking, the manner in which a call is rejected is unlikely to 1832 provide any avenue for fraud or denial of service (e.g., by 1833 signalling that a call should not be billed, or that the network 1834 should take critical resources off-line). However, gateway 1835 implementers may wish to make provision for gateway administrators to 1836 modify the response code to cause value mappings to avoid any 1837 undesirable network-specific behaviour resulting from the mappings 1838 recommended in 8.4.4. 1840 11.4 Use of the To header URI 1842 This specification requires the gateway to map the Request-URI rather 1843 than the To header in a SIP INVITE request to the Called party number 1844 information element in a QSIG SETUP message. Although a SIP UA is 1845 expected to put the same URI in the To header and in the Request-URI, 1846 this is not policed by other SIP entities. Therefore a To header URI 1847 that differs from the Request-URI received at the gateway cannot be 1848 used as a reliable indication that the call has been retargeted in 1849 the SIP network or as a reliable indication of the original target. 1850 Gateway implementers making use of the To header for mapping to QSIG 1851 elements (e.g., as part of QSIG call diversion signalling) may wish 1852 to make provision for disabling this mapping when deployed in 1853 situations where the reliability of the QSIG elements concerned is 1854 important. 1856 11.5 Use of the From header URI 1858 The arbitrary population of the From header of requests by SIP user 1859 agents has some well-understood security implications for devices 1860 that rely on the From header as an accurate representation of the 1861 identity of the originator. Any gateway that intends to use an 1862 unsigned or unverified From header to populate the Calling party 1863 number information element of a QSIG SETUP message should 1864 authenticate the originator of the request and make sure that it is 1865 authorized to assert that calling number (or make use of some more 1866 secure method to ascertain the identity of the caller). Note that 1867 gateways, like all other SIP user agents, MUST support Digest 1868 authentication as described in [10]. Similar considerations apply to 1869 the use of the SIP P-Asserted-Identity header for mapping to the QSIG 1870 Calling party number or Connected number information element, i.e., 1871 the source of this information should be authenticated. Use of a 1872 signed message/sipfrag body to derive a QSIG Calling party number or 1873 Connected number information element is another secure alternative. 1875 11.6 Abuse of early media 1877 There is another class of potential risk that is related to the cut- 1878 through of the backwards media path before the call is answered. 1879 Several practices described in this document involve the connection 1880 of media streams to user information channels on inter-PINX links and 1881 the sending of progress description number 1 or 8 in a backward QSIG 1882 message. This can result in media being cut through end-to-end, and 1883 it is possible for the called user agent then to play arbitrary audio 1884 to the caller for an indefinite period of time before transmitting a 1885 final response (in the form of a 2xx or higher response code) to an 1886 INVITE request. This is useful since it also permits network 1887 entities (particularly legacy networks that are incapable of 1888 transmitting Q.850 cause values) to play tones and announcements to 1889 indicate call failure or call progress, without triggering charging 1890 by transmitting a 2xx response. Also early cut-through can help to 1891 prevent clipping of the initial media when the call is answered. 1892 There are conceivable respects in which this capability could be used 1893 fraudulently by the called user agent for transmitting arbitrary 1894 information without answering the call or before answering the call. 1895 However, in corporate networks charging is often not an issue, and 1896 for calls arriving at a corporate network from a carrier network the 1897 carrier network normally takes steps to prevent fraud. 1899 The usefulness of this capability appears to outweigh any risks 1900 involved, which may in practice be no greater than in existing 1901 PISN/ISDN environments. However, gateway implementers may wish to 1902 make provision for gateway administrators to turn off cut-through or 1903 minimise its impact (e.g., by imposing a time limit) when deployed in 1904 situations where problems can arise. 1906 11.7 Protection from denial of service attacks 1908 Unlike a traditional PISN phone, a SIP user agent can launch multiple 1909 simultaneous requests in order to reach a particular resource. It 1910 would be trivial for a SIP user agent to launch 100 SIP INVITE 1911 requests at a 100 port gateway, thereby tying up all of its ports. A 1912 malicious user could choose to launch requests to telephone numbers 1913 that are known never to answer, or, where overlap signalling is used, 1914 to incomplete addresses. This could saturate resources at the gateway 1915 indefinitely, potentially without incurring any charges. Gateways 1916 implementers may therefore wish to provide means of restricting 1917 according to policy the number of simultaneous requests originating 1918 from the same authenticated source, or similar mechanisms to address 1919 this possible denial-of-service attack. 1921 12 Acknowledgements 1923 This document is a product of the authors' activities in ECMA 1924 (www.ecma-international.org) on interoperability of QSIG with IP 1925 networks. An earlier version is published as Standard ECMA-339. ECMA 1926 has made this work available to the IETF as the basis for publishing 1927 an RFC. 1929 The authors wish to acknowledge the assistance of Francois Audet, 1930 Adam Roach, Jean-Francois Rey, Thomas Stach and members of ECMA TC32- 1931 TG17 in preparing and commenting on this draft. 1933 13 Author's Addresses 1935 John Elwell 1936 Siemens Communications 1937 Technology Drive 1938 Beeston 1939 Nottingham, UK, NG9 1LA 1940 email: john.elwell@siemens.com 1942 Frank Derks 1943 Philips Business Communications 1944 P.O. Box 32 1945 1200 JD, Hilversum 1946 The Netherlands 1947 email: frank.derks@philips.com 1949 Olivier Rousseau 1950 Alcatel Business Systems 1951 32,Avenue Kleber 1952 92700 Colombes 1953 France 1954 email: olivier.rousseau@col.bsf.alcatel.fr 1956 Patrick Mourot 1957 Alcatel Business Systems 1958 1,Rue Dr A. Schweitzer 1959 67400 Illkirch 1960 France 1961 email: patrick.mourot@sxb.bsf.alcatel.fr 1963 14 Normative References 1965 [1] International Standard ISO/IEC 11571 "Private Integrated Services 1966 Networks (PISN) - Addressing" (also published by ECMA as Standard 1967 ECMA-155) 1969 [2] International Standard ISO/IEC 11572 "Private Integrated Services 1970 Network - Circuit-mode Bearer Services - Inter-Exchange Signalling 1971 Procedures and Protocol" (also published by ECMA as Standard ECMA- 1972 143) 1974 [3] International Standard ISO/IEC 11582 "Private Integrated Services 1975 Network - Generic Functional Protocol for the Support of 1976 Supplementary Services - Inter-Exchange Signalling Procedures and 1977 Protocol" (also published by ECMA as Standard ECMA-165) 1979 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1980 Levels", BCP 14, RFC 2119, March 1997. 1982 [5] J. Postel, "Transmission Control Protocol", RFC 793. 1984 [6] J. Postel, "User Datagram Protocol", RFC 768. 1986 [7] T. Dierks, C.Allen, "The TLS protocol version 1.0", RFC 2246. 1988 [8] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 1989 2327. 1991 [9] R. Stewart et al., "Stream Control Transmission Protocol" RFC 1992 2960. 1994 [10] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 1995 protocol", RFC 3261. 1997 [11] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional 1998 Responses in SIP", RFC 3262. 2000 [12] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with SDP", 2001 RFC 3264. 2003 [13] J. Peterson, "A Privacy Mechanism for the Session Initiation 2004 Protocol (SIP) ", RFC 3323 2006 [14] C. Jennings, J. Peterson, M. Watson, "Private Extensions to the 2007 Session Initiation Protocol (SIP) for Asserted Identity within 2008 Trusted Networks", RFC 3325 2010 [15] J. Postel, "Internet Protocol", RFC 791. 2012 [16] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) ", 2013 RFC 2460. 2015 [17] ITU-T Recommendation E.164, "The International Public 2016 Telecommunication Numbering Plan", (1997-05). 2018 [18] G. Camarillo, A. Roach, J. Peterson, L. Ong, "Mapping of 2019 Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap 2020 Signalling to the Session Initiation Protocol", RFC3578 2022 [19] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 2023 method", RFC 3311. 2025 [20] R. Sparks, "Internet Media Type message/sipfrag", RFC 3420. 2027 15 Intellectual Property Statement 2029 The IETF takes no position regarding the validity or scope of any 2030 intellectual property or other rights that might be claimed to 2031 pertain to the implementation or use of the technology described in 2032 this document or the extent to which any license under such rights 2033 might or might not be available; neither does it represent that it 2034 has made any effort to identify any such rights. Information on the 2035 IETF's procedures with respect to rights in standards-track and 2036 standards-related documentation can be found in BCP-11. Copies of 2037 claims of rights made available for publication and any assurances of 2038 licenses to be made available, or the result of an attempt made to 2039 obtain a general license or permission for the use of such 2040 proprietary rights by implementors or users of this specification can 2041 be obtained from the IETF Secretariat. 2043 The IETF invites any interested party to bring to its attention any 2044 copyrights, patents or patent applications, or other proprietary 2045 rights which may cover technology that may be required to practice 2046 this standard. Please address the information to the IETF Executive 2047 Director. 2049 16 Full Copyright Statement 2051 Copyright (C) The Internet Society (2004). All Rights Reserved. 2053 This document and translations of it may be copied and furnished to 2054 others, and derivative works that comment on or otherwise explain it 2055 or assist in its implementation may be prepared, copied, published 2056 and distributed, in whole or in part, without restriction of any 2057 kind, provided that the above copyright notice and this paragraph are 2058 included on all such copies and derivative works. However, this 2059 document itself may not be modified in any way, such as by removing 2060 the copyright notice or references to the Internet Society or other 2061 Internet organizations, except as needed for the purpose of 2062 developing Internet standards in which case the procedures for 2063 copyrights defined in the Internet Standards process must be 2064 followed, or as required to translate it into languages other than 2065 English. 2067 The limited permissions granted above are perpetual and will not be 2068 revoked by the Internet Society or its successors or assignees. 2070 This document and the information contained herein is provided on an 2071 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2072 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2073 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2074 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2075 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2077 Annex A (informative) - Example message sequences 2079 A.1 Introduction 2081 This annex shows some typical message sequences that can occur for an 2082 interworking between QSIG and SIP. 2084 NOTE 1. For all message sequence diagrams, there is no message 2085 mapping between QSIG and SIP unless explicitly indicated by dotted 2086 lines. Also, if there are no dotted lines connecting two messages, 2087 this means that these are independent of each other in terms of the 2088 time when they occur. 2090 NOTE 2. Numbers prefixing SIP method names and response codes in the 2091 diagrams represent sequence numbers. Messages bearing the same 2092 number will have the same value in the CSeq header. 2094 NOTE 3. In these examples SIP provisional responses (other than 100) 2095 are shown as being sent reliably, using the PRACK method for 2096 acknowledgement. 2098 A.2 Message sequences for call establishment from QSIG to SIP 2100 Below are typical message sequences for successful call establishment 2101 from QSIG to SIP 2103 A.2.1 Typical message sequence for successful call establishment from 2104 QSIG to SIP using enbloc procedures on both QSIG and SIP 2105 +-------------------+ 2106 | | 2107 | GATEWAY | 2108 PISN | | IP NETWORK 2109 | +-----+------+------+ | 2110 | | | | 2111 | | | | 2112 | QSIG SETUP | | 1-INVITE | 2113 1|----------------------->|......|----------------------->| 2 2114 | | | | 2115 | | | | 2116 | QSIG CALL PROCEEDING | | 1-100 TRYING | 2117 3|<-----------------------| |<-----------------------+ 4 2118 | | | | 2119 | | | | 2120 | QSIG ALERTING | | 1-180 RINGING | 2121 8|<-----------------------|......|<-----------------------+ 5 2122 | | | | 2123 | | | 2-PRACK | 2124 | | |----------------------->| 6 2125 | | | 2-200 OK | 2126 | | |<-----------------------+ 7 2127 | | | | 2128 | QSIG CONNECT | | 1-200 OK | 2129 11|<-----------------------|......|<-----------------------+ 9 2130 | | | | 2131 | QSIG CONNECT ACK | | 1-ACK | 2132 12|----------------------->| |----------------------->| 10 2133 | | | | 2134 |<======================>| |<======================>| 2135 | AUDIO | | AUDIO | 2137 Figure 3 - Typical message sequence for successful call establishment 2138 from QSIG to SIP using enbloc procedures on both QSIG and SIP 2140 1 The PISN sends a QSIG SETUP message to the gateway to begin a 2141 session with a SIP UA 2142 2 On receipt of the QSIG SETUP message, the gateway generates a SIP 2143 INVITE request and sends it to an appropriate SIP entity in the IP 2144 network based on the called number 2145 3 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no 2146 more QSIG INFORMATION messages will be accepted 2147 4 The IP network sends a SIP 100 (Trying) response to the gateway 2148 5 The IP network sends a SIP 180 (Ringing) response. 2149 6 The gateway may send back a SIP PRACK request to the IP network 2150 based on the inclusion of a Require header or a Supported header with 2151 option tag 100rel in the initial SIP INVITE request 2152 7 The IP network sends a SIP 200 (OK) response to the gateway to 2153 acknowledge the SIP PRACK request 2154 8 The gateway maps this SIP 180 (Ringing) response to a QSIG 2155 ALERTING message and sends it to the PISN. 2156 9 The IP network sends a SIP 200 (OK) response when the call is 2157 answered. 2158 10 The gateway sends a SIP ACK request to acknowledge the SIP 200 2159 (OK)response. 2160 11 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 2161 message and sends it to the PISN. 2162 12 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 2163 the QSIG CONNECT message. 2165 A.2.2 Typical message sequence for successful call establishment from 2166 QSIG to SIP using overlap receiving on QSIG and enbloc sending on SIP 2168 +------------------------+ 2169 PISN | GATEWAY | IP NETWORK 2170 | | 2171 | QSIG SETUP +--------+-------+-------+ | 2172 1|-------------------------->| | | 2173 | | | | 2174 | QSIG SETUP ACK | | | 2175 2|<--------------------------| | | 2176 | | | | 2177 | QSIG INFORMATION | | | 2178 3|-------------------------->| | | 2179 | | | | 2180 | QSIG INFORMATION | | 1-INVITE | 2181 3a|-------------------------->|.......|----------------------->|4 2182 | QSIG CALL PROCEEDING | | 1-100 TRYING | 2183 5|<--------------------------| |<-----------------------|6 2184 | | | | 2185 | QSIG ALERTING | | 1-180 RINGING | 2186 10|<--------------------------|.......|<-----------------------|7 2187 | | | 2-PRACK | 2188 | | |----------------------->|8 2189 | | | 2-200 OK | 2190 | | |<-----------------------|9 2191 | QSIG CONNECT | | 1-200 OK | 2192 13|<--------------------------|.......|<-----------------------|11 2193 | | | | 2194 | QSIG CONNECT ACK | | 1-ACK | 2195 14|-------------------------->| |----------------------->|12 2196 | AUDIO | | AUDIO | 2197 |<=========================>| |<======================>| 2199 Figure 4 - Typical message sequence for successful call establishment 2200 from QSIG to SIP using overlap receiving on QSIG and enbloc sending 2201 on SIP 2202 1 The PISN sends a QSIG SETUP message to the gateway to begin a 2203 session with a SIP UA. The QSIG SETUP message does not contain a 2204 Sending Complete information element. 2205 2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. 2206 More digits are expected. 2207 3 More digits are sent from the PISN within a QSIG INFORMATION 2208 message. 2209 3a More digits are sent from the PISN within a QSIG INFORMATION 2210 message. The QSIG INFORMATION message contains a Sending Complete 2211 information element 2212 4 The Gateway generates a SIP INVITE request and sends it to an 2213 appropriate SIP entity in the IP network, based on the called number 2214 5 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no 2215 more QSIG INFORMATION messages will be accepted 2216 6 The IP network sends a SIP 100 (Trying) response to the gateway 2217 7 The IP network sends a SIP 180 (Ringing) response. 2218 8 The gateway may send back a SIP PRACK request to the IP network 2219 based on the inclusion of a Require header or a Supported header with 2220 option tag 100rel in the initial SIP INVITE request 2221 9 The IP network sends a SIP 200 (OK) response to the gateway to 2222 acknowledge the SIP PRACK request 2223 10 The gateway maps this SIP 180 (Ringing) response to a QSIG 2224 ALERTING message and sends it to the PINX. 2225 11 The IP network sends a SIP 200 (OK) response when the call is 2226 answered. 2227 12 The gateway sends an SIP ACK request to acknowledge the SIP 200 2228 (OK) response. 2229 13 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 2230 message and sends it to the PINX. 2231 14 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 2232 the QSIG CONNECT message. 2234 A.2.3 Typical message sequence for successful call establishment from 2235 QSIG to SIP using overlap procedures on both QSIG and SIP 2236 +----------------------+ 2237 PISN | GATEWAY | IP NETWORK 2238 | | 2239 | QSIG SETUP +-------+-------+------+ | 2240 1 |------------------------->| | | 2241 | | | | 2242 | QSIG SETUP ACK | | | 2243 2 |<-------------------------| | | 2244 | | | | 2245 | QSIG INFORMATION | | | 2246 3 |------------------------->| | | 2247 | QSIG INFORMATION | | 1-INVITE | 2248 3 |------------------------->|.......|------------------------>|4 2249 | | | 1-484 | 2250 | | |<------------------------|5 2251 | | | 1-ACK | 2252 | | |------------------------>|6 2253 | QSIG INFORMATION | | 2-INVITE | 2254 7 |------------------------->|.......|------------------------>|4 2255 | | | 2-484 | 2256 | | |<------------------------|5 2257 | | | 2-ACK | 2258 | | |------------------------>|6 2259 | | | | 2260 | QSIG INFORMATION | | | 2261 | Sending Complete IE | | 3-INVITE | 2262 8 |------------------------->|.......|------------------------>|10 2263 | QSIG CALL PROCEEDING | | 3-100 TRYING | 2264 9 |<-------------------------| |<------------------------|11 2265 | | | | 2266 | QSIG ALERTING | | 3-180 RINGING | 2267 15|<-------------------------|.......|<------------------------|12 2268 | | | 4-PRACK | 2269 | | |------------------------>|13 2270 | | | 4-200 OK | 2271 | | |<------------------------|14 2272 | QSIG CONNECT | | 3-200 OK | 2273 18|<-------------------------|.......|<------------------------|16 2274 | | | | 2275 | QSIG CONNECT ACK | | 3-ACK | 2276 19|------------------------->| |------------------------>|17 2277 | AUDIO | | AUDIO | 2278 |<========================>| |<=======================>| 2279 | | | | 2281 Figure 5 - Typical message sequence for successful call establishment 2282 from QSIG to SIP using overlap procedures on both QSIG and SIP 2283 1 The PISN sends a QSIG SETUP message to the gateway to begin a 2284 session with a SIP UA. The QSIG SETUP message does not contain a 2285 Sending complete information element. 2286 2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. 2287 More digits are expected. 2288 3 More digits are sent from the PISN within a QSIG INFORMATION 2289 message. 2290 4 When the gateway receives the minimum number of digits required to 2291 route the call it generates a SIP INVITE request and sends it to an 2292 appropriate SIP entity in the IP network based on the called number 2293 5 Due to an insufficient number of digits the IP network will return 2294 a SIP 484 (Address Incomplete) response. 2295 6 The SIP 484 (Address Incomplete) response is acknowledged. 2296 7 More digits are received from the PISN in a QSIG INFORMATION 2297 message. A new INVITE is sent with the same Call-ID and From values 2298 but an updated Request-URI. 2299 8 More digits are received from the PISN in a QSIG INFORMATION 2300 message. The QSIG INFORMATION message contains a Sending Complete 2301 information element 2302 9 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no 2303 more information will be accepted 2304 10 The gateway sends a new SIP INVITE request with an updated 2305 Request-URI field. 2306 11 The IP network sends a SIP 100 (Trying) response to the gateway 2307 12 The IP network sends a SIP 180 (Ringing) response. 2308 13 The gateway may send back a SIP PRACK request to the IP network 2309 based on the inclusion of a Require header or a Supported header with 2310 option tag 100rel in the initial SIP INVITE request 2311 14 The IP network sends a SIP 200 (OK) response to the gateway to 2312 acknowledge the SIP PRACK request 2313 15 The gateway maps this SIP 180 (Ringing) response to a QSIG 2314 ALERTING message and sends it to the PISN. 2315 16 The IP network sends a SIP 200 (OK) response when the call is 2316 answered. 2317 17 The gateway sends a SIP ACK request to acknowledge the SIP 200 2318 (OK) response. 2319 18 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 2320 message. 2321 19 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 2322 the QSIG CONNECT message. 2324 A.3 Message sequences for call establishment from SIP to QSIG 2326 Below are typical message sequences for successful call establishment 2327 from SIP to QSIG 2329 A.3.1 Typical message sequence for successful call establishment from 2330 SIP to QSIG using enbloc procedures 2331 +----------------------+ 2332 IP NETWORK | GATEWAY | PISN 2333 | | 2334 | +-------+-------+------+ | 2335 | | | | 2336 | | | | 2337 | 1-INVITE | | QSIG SETUP | 2338 1 |------------------------->|.......|------------------------>|3 2339 | 1-100 TRYING | | QSIG CALL PROCEEDING | 2340 2 |<-------------------------| |<------------------------|4 2341 | 1-180 RINGING | | QSIG ALERTING | 2342 6 |<-------------------------|.......|<------------------------|5 2343 | | | | 2344 | | | | 2345 | 2-PRACK | | | 2346 7 |------------------------->| | | 2347 | 2-200 OK | | | 2348 8 |<-------------------------| | | 2349 | 1-200 OK | | QSIG CONNECT | 2350 11|<-------------------------|.......|<------------------------|9 2351 | | | | 2352 | 1-ACK | | QSIG CONNECT ACK | 2353 12|------------------------->| |------------------------>|10 2354 | AUDIO | | AUDIO | 2355 |<========================>| |<=======================>| 2356 | | | | 2358 Figure 6 - Typical message sequence for successful call establishment 2359 from SIP to QSIG using enbloc procedures 2361 1 The IP network sends a SIP INVITE request to the gateway 2362 2 The gateway sends a SIP 100 (Trying) response to the IP network 2363 3 On receipt of the SIP INVITE request, the gateway sends a QSIG 2364 SETUP message 2365 4 The PISN sends a QSIG CALL PROCEEDING message to the gateway 2366 5 A QSIG ALERTING message is returned to indicate that the end user 2367 in the PISN is being alerted 2368 6 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) 2369 response 2370 7 The IP network can send back a SIP PRACK request to the IP network 2371 based on the inclusion of a Require header or a Supported header with 2372 option tag 100rel in the initial SIP INVITE request 2373 8 The gateway sends a SIP 200 (OK) response to acknowledge the SIP 2374 PRACK request 2375 9 The PISN sends a QSIG CONNECT message to the gateway when the call 2376 is answered 2377 10 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 2378 acknowledge the QSIG CONNECT message 2379 11 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 2381 12 The IP network, upon receiving a SIP INVITE final response (200), 2382 will send a SIP ACK request to acknowledge receipt 2384 A.3.2 Typical message sequence for successful call establishment from 2385 SIP to QSIG using overlap receiving on SIP and enbloc sending on QSIG 2387 +----------------------+ 2388 IP NETWORK | GATEWAY | PISN 2389 | | 2390 | 1-INVITE +-------+-------+------+ | 2391 1 |------------------------->| | | 2392 | 1-484 | | | 2393 2 |<-------------------------| | | 2394 | 1-ACK | | | 2395 3 |------------------------->| | | 2396 | 2-INVITE | | | 2397 1 |------------------------->| | | 2398 | 2-484 | | | 2399 2 |<-------------------------| | | 2400 | 2- ACK | | | 2401 3 |------------------------->| | | 2402 | 3-INVITE | | QSIG SETUP | 2403 4 |------------------------->|.......|------------------------>|6 2404 | 3-100 TRYING | | QSIG CALL PROCEEDING | 2405 5 |<-------------------------| |<------------------------|7 2406 | 3-180 RINGING | | QSIG ALERTING | 2407 9 |<-------------------------|.......|<------------------------|8 2408 | | | | 2409 | | | | 2410 | 4-PRACK | | | 2411 10|------------------------->| | | 2412 | 4-200 OK | | | 2413 11|<-------------------------| | | 2414 | 3-200 OK | | QSIG CONNECT | 2415 14|<-------------------------|.......|<------------------------|12 2416 | | | | 2417 | 3-ACK | | QSIG CONNECT ACK | 2418 15|------------------------->| |------------------------>|13 2419 | AUDIO | | AUDIO | 2420 |<========================>| |<=======================>| 2421 | | | | 2423 Figure 7 - Typical message sequence for successful call establishment 2424 from SIP to QSIG using overlap receiving on SIP and enbloc sending on 2425 QSIG 2427 1 The IP network sends a SIP INVITE request to the gateway 2428 2 Due to an insufficient number of digits the gateway returns a SIP 2429 484(Address Incomplete) response. 2431 3 The IP network acknowledge the SIP 484 (Address Incomplete) 2432 response. 2433 4 The IP network sends a new SIP INVITE request with the same Call- 2434 ID and updated Request-URI. 2435 5 The gateway now has all the digits required to route the call to 2436 the PISN. The gateway sends back a SIP 100 (Trying) response 2437 6 The gateway sends a QSIG SETUP message 2438 7 The PISN sends a QSIG CALL PROCEEDING message to the gateway 2439 8 A QSIG ALERTING message is returned to indicate that the end user 2440 in the PISN is being alerted 2441 9 The gateway maps the QSIG ALERTING message to a SIP 180 2442 (Ringing)response 2443 10 The IP network can send back a SIP PRACK request to the IP network 2444 based on the inclusion of a Require header or a Supported header with 2445 option tag 100rel in the initial SIP INVITE request 2446 11 The gateway sends a SIP 200 (OK) response to acknowledge the SIP 2447 PRACK request 2448 12 The PISN sends a QSIG CONNECT message to the gateway when the call 2449 is answered 2450 13 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 2451 acknowledge the CONNECT message 2452 14 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 2453 15 The IP network, upon receiving a SIP INVITE final response (200), 2454 will send a SIP ACK request to acknowledge receipt 2456 A.3.3 Typical message sequence for successful call establishment from 2457 SIP to QSIG using overlap procedures on both SIP and QSIG 2458 +----------------------+ 2459 IP NETWORK | GATEWAY | PISN 2460 | | 2461 | 1-INVITE +-------+-------+------+ | 2462 1 |------------------------->| | | 2463 | 1-484 | | | 2464 2 |<-------------------------| | | 2465 | 1-ACK | | | 2466 3 |------------------------->| | | 2467 | 2-INVITE | | QSIG SETUP | 2468 4 |------------------------->|.......|------------------------>|6 2469 | 2-100 TRYING | | QSIG SETUP ACK | 2470 5 |<-------------------------| |<------------------------|7 2471 | 3- INVITE | | QSIG INFORMATION | 2472 8 |------------------------->|.......|------------------------>|10 2473 | 3-100 TRYING | | | 2474 9 |<-------------------------| | QSIG CALL PROCEEDING | 2475 | | |<------------------------|11 2476 13| 3-180 RINGING | | QSIG ALERTING | 2477 |<-------------------------|.......|<------------------------|12 2478 | 2-484 | | | 2479 14|<-------------------------| | | 2480 | 2-ACK | | | 2481 15|------------------------->| | | 2482 | 4-PRACK | | | 2483 16|------------------------->| | | 2484 | 4-200 OK | | | 2485 17|<-------------------------| | | 2486 | 3-200 OK | | QSIG CONNECT | 2487 20|<-------------------------|.......|<------------------------|18 2488 | | | | 2489 | 3-ACK | | QSIG CONNECT ACK | 2490 21|------------------------->| |------------------------>|19 2491 | AUDIO | | AUDIO | 2492 |<========================>| |<=======================>| 2493 | | | | 2495 Figure 8 - Typical message sequence for successful call establishment 2496 from SIP to QSIG using overlap procedures on both SIP and QSIG 2498 1 The IP network sends a SIP INVITE request to the gateway 2499 2 Due to an insufficient number of digits the gateway returns a SIP 2500 484(Address Incomplete) response. 2501 3 The IP network acknowledges the SIP 484 (Address Incomplete) 2502 response. 2503 4 The IP network sends a new SIP INVITE request with the same Call- 2504 ID and updated Request-URI. 2506 5 The gateway now has all the digits required to route the call to 2507 the PISN. The gateway sends back a SIP 100 (Trying) response to the 2508 IP network 2509 6 The gateway sends a QSIG SETUP message 2510 7 The PISN needs more digits to route the call and sends a QSIG 2511 SETUP ACKNOWLEDGE message to the gateway 2512 8 The IP network sends a new SIP INVITE request with the same Call- 2513 ID and From values and updated Request-URI. 2514 9 The gateway sends back a SIP 100 (Trying) response to the IP 2515 network 2516 10 The gateway maps the new SIP INVITE request to a QSIG INFORMATION 2517 message 2518 11 The PISN has all the digits required and sends back a QSIG CALL 2519 PROCEEDING message to the gateway 2520 12 A QSIG ALERTING message is returned to indicate that the end user 2521 in the PISN is being alerted 2522 13 The gateway maps the QSIG ALERTING message to a SIP 180 2523 (Ringing)response 2524 14 The gateway sends a SIP 484 (Address Incomplete) response for the 2525 previous SIP INVITE request 2526 15 The IP network acknowledges the SIP 484 (Address Incomplete) 2527 response 2528 16 The IP network can send back a SIP PRACK request to the IP network 2529 based on the inclusion of a Require header or a Supported header with 2530 option tag 100rel in the initial SIP INVITE request 2531 17 The gateway sends a SIP 200 (OK) response to acknowledge the SIP 2532 PRACK request 2533 18 The PISN sends a QSIG CONNECT message to the gateway when the call 2534 is answered 2535 19 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 2536 acknowledge the QSIG CONNECT message 2537 20 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 2538 21 The IP network, upon receiving a SIP INVITE final response (200), 2539 will send a SIP ACK request to acknowledge receipt 2541 A.4 Message sequence for call clearing from QSIG to SIP 2543 Below are typical message sequences for Call Clearing from QSIG to 2544 SIP 2546 A.4.1 Typical message sequence for call clearing from QSIG to SIP 2547 subsequent to call establishment 2548 +-------------------+ 2549 | | 2550 | GATEWAY | 2551 PISN | | IP NETWORK 2552 | +-----+------+------+ | 2553 | | | | 2554 | | | | 2555 | QSIG DISCONNECT | | 2- BYE | 2556 1|----------------------->|......|----------------------->|4 2557 | QSIG RELEASE | | 2-200 OK | 2558 2|<-----------------------| |<-----------------------|5 2559 | QSIG RELEASE COMP | | | 2560 3|----------------------->| | | 2561 | | | | 2562 | | | | 2563 | | | | 2565 Figure 9 - Typical message sequence for call clearing from QSIG to 2566 SIP subsequent to call establishment 2568 1 The PISN sends a QSIG DISCONNECT message to the gateway 2569 2 The gateway sends back a QSIG RELEASE message to the PISN in 2570 response to the QSIG DISCONNECT message 2571 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All 2572 PISN resources are now released. 2573 4 The gateway maps the QSIG DISCONNECT message to a SIP BYE request 2574 5 The IP network sends back a SIP 200 (OK) response to the SIP BYE 2575 request. All IP resources are now released 2577 A.4.2 Typical message sequence for call clearing from QSIG to SIP during 2578 establishment of a call from SIP to QSIG (gateway has not sent a final 2579 response to the SIP INVITE request) 2580 +-------------------+ 2581 | | 2582 | GATEWAY | 2583 PISN | | IP NETWORK 2584 | +-----+------+------+ | 2585 | | | | 2586 | | | | 2587 | QSIG DISCONNECT | | 1- 4XX / 6XX | 2588 1|----------------------->|......|---------------------->|4 2589 | QSIG RELEASE | | 1- ACK | 2590 2|<-----------------------| |<----------------------|5 2591 | QSIG RELEASE COMP | | | 2592 3|----------------------->| | | 2593 | | | | 2594 | | | | 2596 Figure 10 - Typical message sequence for call clearing from QSIG to 2597 SIP during establishment of a call from SIP to QSIG (gateway has not 2598 sent a final response to the SIP INVITE request) 2600 1 The PISN sends a QSIG DISCONNECT message to the gateway 2601 2 The gateway sends back a QSIG RELEASE message to the PISN in 2602 response to the QSIG DISCONNECT message 2603 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All 2604 PISN resources are now released. 2605 4 The gateway maps the QSIG DISCONNECT message to a SIP 4xx-6xx 2606 response 2607 5 The IP network sends back a SIP ACK request in response to the SIP 2608 4xx-6xx response. All IP resources are now released 2610 A.4.3 Typical message sequence for call clearing from QSIG to SIP during 2611 establishment of a call from QSIG to SIP (gateway has received a 2612 provisional response to the SIP INVITE request but not a final response) 2613 +-------------------+ 2614 | | 2615 | GATEWAY | 2616 PISN | | IP NETWORK 2617 | +-----+------+------+ | 2618 | | | | 2619 | | | | 2620 | QSIG DISCONNECT | | 1- CANCEL | 2621 1|----------------------->|......|----------------------->|4 2622 | QSIG RELEASE | |1-487 Request Terminated| 2623 2|<-----------------------| |<-----------------------|5 2624 | QSIG RELEASE COMP | | | 2625 3|----------------------->| | 1- ACK | 2626 | | |----------------------->|6 2627 | | | | 2628 | | | 1- 200 OK | 2629 | | |<-----------------------|7 2630 | | | | 2632 Figure 11 - Typical message sequence for call clearing from QSIG to 2633 SIP during establishment of a call from QSIG to SIP (gateway has 2634 received a provisional response to the SIP INVITE request but not a 2635 final response) 2637 1 The PISN sends a QSIG DISCONNECT message to the gateway 2638 2 The gateway sends back a QSIG RELEASE message to the PISN in 2639 response to the QSIG DISCONNECT message 2640 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All 2641 PISN resources are now released. 2642 4 The gateway maps the QSIG DISCONNECT message to a SIP CANCEL 2643 request(subject to a provisional response but no final response 2644 having been received) 2645 5 The IP network sends back a SIP 487 (Request Terminated) response 2646 to the SIP INVITE request. 2647 6 The gateway, on receiving a SIP final response (487) to the SIP 2648 INVITE request, sends back a SIP ACK request to acknowledge receipt 2649 7 The IP network sends back a SIP 200 (OK) response to the SIP 2650 CANCEL request. All IP resources are now released 2652 A.5 Message sequence for call clearing from SIP to QSIG 2654 Below are typical message sequences for Call Clearing from SIP to 2655 QSIG 2657 A.5.1 Typical message sequence for call clearing from SIP to QSIG 2658 subsequent to call establishment 2659 +-------------------+ 2660 | | 2661 | GATEWAY | 2662 IP NETWORK | | PISN 2663 | +-----+------+------+ | 2664 | | | | 2665 | | | | 2666 | 2- BYE | | QSIG DISCONNECT | 2667 1|----------------------->|......|----------------------->|3 2668 | | | QSIG RELEASE | 2669 | | |<-----------------------|4 2670 | 2-200 OK | | QSIG RELEASE COMP | 2671 2|<-----------------------| |----------------------->|5 2672 | | | | 2673 | | | | 2675 Figure 12 - Typical message sequence for call clearing from SIP to 2676 QSIG subsequent to call establishment 2678 1 The IP network sends a SIP BYE request to the gateway 2679 2 The gateway sends back a SIP 200 (OK) response to the SIP BYE 2680 request. All IP resources are now released 2681 3 The gateway maps the SIP BYE request to a QSIG DISCONNECT message 2682 4 The PISN sends back a QSIG RELEASE message to the gateway in 2683 response to the QSIG DISCONNECT message 2684 5 The gateway sends a QSIG RELEASE COMPLETE message in response. All 2685 PISN resources are now released. 2687 A.5.2 Typical message sequence for call clearing from SIP to QSIG during 2688 establishment of a call from QSIG to SIP (gateway has not previously 2689 received a final response to the SIP INVITE request) 2690 +-------------------+ 2691 | | 2692 | GATEWAY | 2693 IP NETWORK | | PISN 2694 | +-----+------+------+ | 2695 | | | | 2696 | | | | 2697 | 1- 4XX / 6XX | | QSIG DISCONNECT | 2698 1|----------------------->|......|----------------------->|3 2699 | | | QSIG RELEASE | 2700 | | |<-----------------------|4 2701 | 1- ACK | | QSIG RELEASE COMP | 2702 2|<-----------------------| |----------------------->|5 2703 | | | | 2704 | | | | 2705 | | | | 2707 Figure 13 - Typical message sequence for call clearing from SIP to 2708 QSIG during establishment of a call from QSIG to SIP (gateway has not 2709 previously received a final response to the SIP INVITE request) 2711 1 The IP network sends a SIP 4xx-6xx response to the gateway 2712 2 The gateway sends back a SIP ACK request in response to the SIP 2713 4xx-6xx response. All IP resources are now released 2714 3 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT 2715 message 2716 4 The PISN sends back a QSIG RELEASE message to the gateway in 2717 response to the QSIG DISCONNECT message 2718 5 The gateway sends a QSIG RELEASE COMPLETE message in response. All 2719 PISN resources are now released. 2721 A.5.3 Typical message sequence for call clearing from SIP to QSIG during 2722 establishment of a call from SIP to QSIG (gateway has sent a provisional 2723 response to the SIP INVITE request but not a final response) 2724 +-------------------+ 2725 | | 2726 | GATEWAY | 2727 IP NETWORK | | PISN 2728 | +-----+------+------+ | 2729 | | | | 2730 | | | | 2731 | 1- CANCEL | | QSIG DISCONNECT | 2732 1|----------------------->|......|----------------------->|4 2733 | | | QSIG RELEASE | 2734 | | |<-----------------------|5 2735 |1-487 Request Terminated| | QSIG RELEASE COMP | 2736 2|<-----------------------| |----------------------->|6 2737 | | | | 2738 | 1- ACK | | | 2739 3|----------------------->| | | 2740 | | | | 2741 | 1- 200 OK | | | 2742 4|<-----------------------| | | 2744 Figure 14 - Typical message sequence for call clearing from SIP to 2745 QSIG during establishment of a call from SIP to QSIG (gateway has 2746 sent a provisional response to the SIP INVITE request but not a final 2747 response) 2749 1 The IP network sends a SIP CANCEL request to the gateway 2750 2 The gateway sends back a SIP 487 (Request Terminated) response to 2751 the SIP INVITE request 2752 3 The IP network, on receiving a SIP final response (487) to the SIP 2753 INVITE request, sends back a SIP ACK request to acknowledge receipt 2754 4 The gateway sends back a SIP 200 (OK) response to the SIP CANCEL 2755 request. All IP resources are now released 2756 5 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT 2757 message 2758 6 The PISN sends back a QSIG RELEASE message to the gateway in 2759 response to the QSIG DISCONNECT message 2760 7 The gateway sends a QSIG RELEASE COMPLETE message in response. All 2761 PISN resources are now released. 2763 Annex B (temporary) - Change log 2765 Compared with draft-ietf-sipping-qsig2sip-03 the following changes 2766 have been made: 2768 - clarification on handling media streams when forking occurs; 2769 - clarification concerning the possibility of recovering from certain 2770 SIP responses without reflecting these into the QSIG network; 2771 - addition of the possibility of including a signed sigfrag to convey 2772 an authenticated From or To header; 2773 - mention of optional use of other RFC3323 priv-values. 2774 - minor editorial changes.