idnits 2.17.1 draft-ma-h323-isup-gateway-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 430 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1998) is 9318 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 393, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 396, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 400, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 404, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 407, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Gene Ma 3 Category: Informational tti (telecom technologies inc.) 4 Date: October 1998 5 Expires: April 1999 7 H.323 Signaling and SS7 ISUP Gateway: Procedure Interworking 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 25 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 26 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 This document describes protocol procedure interworking in designing 31 signaling gateway between H.323 and SS7 ISUP, especially the procedure 32 and message mapping between H.225/H.245 and SS7 ISUP. 34 Table of Contents 36 1.0 Introduction 37 2.0 Acronyms 38 3.0 Basic Call Control and Signaling Overview 39 3.1 SS7 IUSP Protocol 40 3.2 H.225 and H.245 Protocols 41 4.0 H.323 to ISUP Interworking 42 4.1 Successful Basic Call Setup 43 4.2 Unsuccessful Basic Call Setup 44 4.3 Basic Call Release 45 5.0 Acknowledgements 46 6.0 References 47 7.0 Author 49 1.0 Introduction 51 One of the most important components in VoIP to ISDN/PSTN gateway is 52 the signaling gateway, which is to perform protocol procedure 53 interworking, message mapping, and gateway screening or firewall. H.225 54 and H.245 have been used by H.323 in VoIP for call signaling and media 55 control protocols. In PSTN Common Channel Signaling, all the circuits 56 used for data or voice calls are controlled (i.e., setup and teardown) 57 by the SS7 ISUP protocol. 59 Because of the fundamental difference between packet-based IP network 60 and circuit-based ISDN/PSTN, the signaling protocols for these two 61 networks are conceptually different. The H.323 to SS7 ISUP signaling 62 gateway needs to resolve the difference and interwork two protocols in 63 a smooth way, which is addressed in this document. 65 2.0 Acronyms 67 ACM - Address Complete Message 68 ANM - Answer Message 69 B-ISUP - Broadband ISUP 70 CIC - Circuit Identification Code 71 GK - Gate Keeper 72 IP - Internet Protocol 73 ISDN - Integrated Services Digital Network 74 ISUP - ISDN User Part 75 PSTN - Public Switched Telecommunication Network 76 RAS - Registration, Admission, and Status 77 REL - Release message 78 RLC - Release Complete Message 79 TSAP - Transport Service Access Point 80 VoIP - Voice over IP 82 3.0 Basic Call Control and Signaling Overview 84 3.1 SS7 IUSP Protocol 86 The SS7 ISUP protocol was created as the interexchange signaling between 87 ISDN access and PSTN , and also used as the interworking between ISDN 88 access and egress in PSTN. 90 For an unrestricted 64-kpbs circuit switched example, the ISDN Q.931 and 91 SS7 ISUP interworking can be showed in Figure 1. 93 +--------+ +------+ +------+ +-------+ 94 | Called | Q.931 | Orig.| SS7 ISUP | Dest.| Q.931 |Calling| 95 | Party | | Exch.| | Exch.| | Party | 96 +--------+ +------+ +------+ +-------+ 97 | | | | 98 |--------SETUP------>| | | 99 | |--------IAM-------->| | 100 |<-----CALL PROC-----| |------SETUP------->| 101 | | | | 102 | | |<--CALL PROC (opt)-| 103 | | | | 104 | | |<-----ALERT--------| 105 | |<-------ACM---------| | 106 |<-------ALERT-------| |<-----CONN---------| 107 | |<-------ANM---------| | 108 |<-------CONN--------| |------CONN ACK---->| 109 | | | | 110 |---CONN ACK (opt)-->| | | 111 | | | | 112 +-------------------------------------------------------------+ 113 | Call Information Flow | 114 +-------------------------------------------------------------+ 115 | | | | 116 | | |<-----DISC---------| 117 | |<-------REL---------| | 118 |<------DISC---------| |------REL--------->| 119 | |--------RLC-------->| | 120 |-------REL--------->| |<-----REL COMP-----| 121 | | | | 122 |<------REL COMP-----| | | 123 | | | | 124 Figure 1. Q.931-ISUP interworking for an ISDN call control 126 One of the important information elements in the Q.931 SETUP message 127 is the B-channel Bearer Capability, which is put in the ISUP User 128 Service Information parameter to indicate the requested service from 129 the network. The ISUP uses the CIC parameter in all of its messages to 130 identify the physical circuit(s) being set up based on the bearer 131 request from the called party. 133 In telecommunication industry, any emerging networks, including ISDNs, 134 have to interwork with other existing networks, notably the PSTNs that 135 are the largest and most numerous among the existing networks. For 136 example, a digital telephone set connected to an ISDN basic rate (2B+D) 137 interface certainly needs to be able to talk with a conventional set to 138 the conventional PSTN, which the bearer capability of speech or 3.1-kHz 139 audio is requested from the network to set up the call. By using ISUP, 140 there is no change required for either ISDN or PSTN, and protocol 141 conversion is provided at the ISDN interworking exchanges. 143 3.2 H.225 and H.245 Protocols 145 As we know, the packet-based IP network has the fundamental differences 146 from the circuit-based network PSTN. One of the important differences is 147 that there is no actual channel, such as ISDN B-channel or PSTN trunk 148 circuit, in the IP network. In other words, the H.323 terminals can have 149 more "channels", logical channels to carry more than one application, 150 such as video, audio or data, in ONE call. Because of this difference, 151 the call control in VoIP specified in ITU H.323 is more complicated. 153 In circuit-based network, the call signaling (i.e., setup and teardown) 154 and bearer capability control are processed in one protocol, Q.931 for 155 ISDN and ISUP for SS7 network. However, since different H.323 terminals 156 in VoIP may have different logical channel capabilities, ITU H.323 has 157 specified the call signaling and bearer capability control in two 158 separate protocols, H.225 and H.245. 160 The call signaling specified in H.225 begins by exchanging the RAS 161 information on the unreliable channel. This processing is followed by 162 the call setup sequence through a reliable channel, which is based on 163 Q.931 protocol with modifications. One modification is the bearer 164 capability information element in SETUP message can be ignored if the 165 call is bounded in the packet-based network, in which the bearer is set 166 up by H.245. Another difference is that closing H.225 call signaling 167 channel is not ending the call unless the H.245 channel is also closed. 168 The Release and DISConnect messages in Q.931 are forbidden in H.225 for 169 a H.323 entity. 171 H.245 uses the reliable H.225 call signaling channel to perform H.245 172 control functions, such as master/slave determination, terminal 173 capability exchange, open/closing logical channel, and others. During 174 the terminal capability exchange procedure, both ends are based on 175 their own terminal capability to set up the mutual acceptable bearer 176 service to the network. Then logical channel(s) are opened to handle 177 the bearer capability, for example, two channels for video and one for 178 audio. This procedure is very similar to the bearer capability request 179 in the ISDN Q.931 and SS7 ISUP. 181 4.0 H.323 to ISUP Interworking 183 After having a brief overview on call signaling and control for both 184 circuit-based and packet-based networks, interworking between SS7 ISUP 185 and H.323 (actually H.225 and H.245) becomes quite straightforward. As 186 mentioned in Section 3, the bearer capability set up within the packet- 187 based network is done by H.245. However, for a signaling gateway 188 between packet-based network and circuit network, the information from 189 the bearer capability information element in the H.225 SETUP message is 190 enough to set up a call in the ISDN or PSTN through SS7 ISUP. H.245 is 191 just used for logical channel set up based on bearer capability carried 192 in the H.225 SETUP message. 194 The following sections describes the procedure interworking between 195 ISUP and H.225/H.245. 197 4.1 Successful Basic Call Setup 199 In Figure 2, H.245 control channel procedure may only contain logical 200 channel setup messages since the H.323 terminal that initiate the call 201 knows only one logical channel with the requested bearer capability 202 needed for the call. Remember that circuit-based ISDN or PSTN has only 203 one bearer capability for a call. 205 +------+ H.323/ +-----------+ SS7 ISUP +------+ 206 | H323 | H.225/ | Signaling | | Dest.| 207 | GK | H.245 | Gateway | | Exch.| 208 +------+ +-----------+ +------+ 209 | | | 210 |----H.225 SETUP (with bearer)-->| | 211 | |------------IAM----------->| 212 |<---H.225 CALL PROC-------------| | 213 | |<-----------ACM------------| 214 |<---H.225 ALERT-----------------| | 215 | |<-----------ANM------------| 216 |<---H.225 CONN------------------| | 217 | | | 218 |<==H.245 Capability Exchanges==>| | 219 |<==H.245 Logical Channel Setup=>| | 220 | | | 221 +------------------------------------------------------------+ 222 | Media Information Flow | 223 +------------------------------------------------------------+ 224 Figure 2. Successful Call Setup by Signaling Interworking 226 The signaling gateway can, as optional, immediately start the H.245 227 logical channel setup procedure based on the TSAP address given in 228 the H.225 SETUP message without waiting for the CONNect message, which 229 can reduce the entire call setup time. However, media information will 230 not start to flow before the called party, a H.323 terminal in this 231 example, received the H.225 CONNect message, even H.245 has finished 232 the logical channel setup. We highly recommend the implementation of 233 signaling gateway to use this option for H.245 control channel setup, 234 which is showed in the following figure. 236 +------+ H.323/ +-----------+ SS7 ISUP +------+ 237 | H323 | H.225/ | Signaling | | Dest.| 238 | GK | H.245 | Gateway | | Exch.| 239 +------+ +-----------+ +------+ 240 | | | 241 |----H.225 SETUP (with bearer)-->| | 242 | |------------IAM----------->| 243 |<---H.225 CALL PROC-------------| | 244 | | | 245 |<==H.245 Logical Channel Setup=>| | 246 | |<-----------ACM------------| 247 |<---H.225 ALERT-----------------| | 248 | | | 249 |<---H.225 CONN------------------|<-----------ANM------------| 250 | | | 251 +------------------------------------------------------------+ 252 | Media Information Flow | 253 +------------------------------------------------------------+ 254 Figure 3. Successful Call Setup with a H.245 Option 256 For the call initiated from ISDN or PSTN side to a H.323 terminal, the 257 call setup procedure flow will be similar to Figure 2 or 3. Also, the 258 H.245 logical channel setup procedure can be performed based on the 259 bearer capability information in the ISUP IAM without waiting for the 260 H.225 CONNect message. Figure 4 shows a successful call setup from an 261 ISDN party to a H.323 terminal. 263 +------+ H.323/ +-----------+ SS7 ISUP +------+ 264 | H323 | H.225/ | Signaling | | Dest.| 265 | GK | H.245 | Gateway | | Exch.| 266 +------+ +-----------+ +------+ 267 | | | 268 | |<-----------IAM------------| 269 |<---H.225 SETUP (with bearer)---| | 270 | | | 271 |<==H.245 Capability Exchanges==>| | 272 |<==H.245 Logical Channel Setup=>| | 273 | | | 274 |----H.225 ALERT---------------->| | 275 | |------------ACM----------->| 276 |----H.225 CONN----------------->| | 277 | |------------ANM----------->| 278 | | | 279 +------------------------------------------------------------+ 280 | Media Information Flow | 281 +------------------------------------------------------------+ 282 Figure 4. Successful Call Setup Initiated from ISDN 284 It is noted that no H.245 capability exchanges procedure is required 285 in the Figure 4. When a H.323 terminal initiates the call to an ISDN 286 called party, it knows its own terminal capability that is carried by 287 the bearer capability information element in the H.225 SETUP message 288 sent the signaling gateway. If the gateway has the compatible terminal 289 capability, it forms an ISUP IAM and sends to the ISDN called party 290 through SS7 ISUP protocol. 292 4.2 Unsuccessful Basic Call Setup 294 In ISDN or PSTN, many causes are attributed to unsuccessful call setup, 295 such as called party busy, resource unavailable, bearer service not 296 implemented, and others. After the destination exchange receives the 297 IAM and determines that the call is not able to complete, it sends back 298 an ISUP REL message with the reason. At the originating exchange, the 299 ISUP REL message is mapped into the Q.931 DISConnect message and sent 300 to the calling party to end the call. 302 However, a H.225 reliable call signaling channel is not set up until 303 the H.225 CONNect message is received. Therefore, in an unsuccessful 304 call setup across between ISDN (or PSTN) and packet-based network, no 305 H.225 call signaling channel is established since no H.225 CONNect 306 message mapped from the ISUP ANM is received. Instead, H.245 session 307 end procedure is used to end the call. The Figures 5 and 6 show the 308 unsuccessful call setup caused by either the H.323 terminal or an ISDN 309 party. 311 +------+ H.323/ +-----------+ SS7 ISUP +------+ 312 | H323 | H.225/ | Signaling | | Dest.| 313 | GK | H.245 | Gateway | | Exch.| 314 +------+ +-----------+ +------+ 315 | | | 316 |----H.225 SETUP (with bearer)-->| | 317 | |------------IAM----------->| 318 |<---H.225 CALL PROC-------------| | 319 | | | 320 |<==H.245 Logical Channel Setup=>| | 321 | |<-----REL (with cause)-----| 322 |<==H.245 End Session Command===>| | 323 | | | 324 Figure 5. Unsuccessful Call Setup caused by the ISDN party 326 +------+ H.323/ +-----------+ SS7 ISUP +------+ 327 | H323 | H.225/ | Signaling | | Dest.| 328 | GK | H.245 | Gateway | | Exch.| 329 +------+ +-----------+ +------+ 330 | | | 331 | |<-----------IAM------------| 332 |<---H.225 SETUP (with bearer)---| | 333 | | | 334 |<===H.245 Capability Setup======| | 335 | | | 336 |====H.245 Capability Reject====>| | 337 | |------REL (with cause)---->| 338 |<===H.245 End Session Command==>| | 339 | | | 340 Figure 6. Unsuccessful Call Setup caused by H.323 Terminal 342 4.3 Basic Call Release 344 In packet-based network, the H.225 Release Complete message and the 345 H.245 session end procedure are used to release an established call. 346 The call release initiated by the H.323 terminal through the signaling 347 gateway is showed in Figure 4. 349 +------+ H.323/ +-----------+ SS7 ISUP +------+ 350 | H323 | H.225/ | Signaling | | Dest.| 351 | GK | H.245 | Gateway | | Exch.| 352 +------+ +-----------+ +------+ 353 | | | 354 |===H.245 End Session Command=====>| | 355 | |------------REL--------->| 356 |<==H.245 End Session Command======| | 357 | |<-----------RLC----------| 358 |----H.225 Release Complete------->| | 359 | | | 360 Figure 7. Basic Call Release by Signaling Interworking 362 The call release initiated from the ISDN or PSTN side is showed in 363 Figure 6, which is the same as that is showed in Figure 5. 365 +------+ H.323/ +-----------+ SS7 ISUP +------+ 366 | H323 | H.225/ | Signaling | | Dest.| 367 | GK | H.245 | Gateway | | Exch.| 368 +------+ +-----------+ +------+ 369 | | | 370 | |<-----------REL----------| 371 |<==H.245 End Session Command======| | 372 |===H.245 End Session Command=====>| | 373 | |------------RLC--------->| 374 |<---H.225 Release Complete--------| | 375 | | | 376 Figure 8. Basic Call Release by Signaling Interworking 378 5.0 Acknowledgement 380 The author would like to thank Wesley Hicks for his comments on this 381 document. 383 6.0 Further Studies 385 The H.323 to ISUP interworking presented in this document is based on 386 version 1 of the ITU-T H.323 standards. The next step is to consider 387 the fast connect procedures specified in the version 2 of the H.323 for 388 the signaling gateway design. It is also important to extend the current 389 work for signaling interworking between H.323 and B-ISUP. 391 7.0 References 393 [1] ANSI T1.113-1993, "Signaling System No. 7 (SS7) - Integrated 394 Services Digital Network (ISDN) User Part" 396 [2] ITU-T Recommendation Q.931-1993, "Digital Subscriber Signaling 397 System No. 1 (DSS 1) - ISDN User-Network Interface Layer 3 398 Specification for Basic Call Control" 400 [3] ITU-T Recommendation H.323-1996, "Visual telephone systems and 401 equipment for area networks which provide a non-guaranteed quality of 402 service" 404 [4] ITU-T Recommendation Q.225-1996, "Media stream packetization and 405 synchronization on non-guaranteed quality of service LANs" 407 [5] ITU-T Recommendation Q.245-1996, "Control protocol for multimedia 408 communication" 410 8.0 Author 412 Gene Ma 413 tti (telecom technologies inc.) 414 1700 North Collins Blvd. 415 Richardson, Texas 75080 416 Tel: 972-301-4987 417 Email: gene.ma@ttimail.com