idnits 2.17.1 draft-bell-ipdc-signaling-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-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 163 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 169: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 172: '... MUST NOT This phrase means tha...' RFC 2119 keyword, line 175: '... SHOULD This word, or the adjective ...' RFC 2119 keyword, line 180: '... MAY This word, or the adjective "...' RFC 2119 keyword, line 182: '...lude this option MUST be prepared to i...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 12 has weird spacing: '... This docum...' == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... and its w...' == Line 18 has weird spacing: '... and may be...' == Line 19 has weird spacing: '...me. It is i...' == (158 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. -- 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 (August 1998) is 9385 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 740, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 2 INTERNET DRAFT Bob Bell 3 Selsius Systems 4 Title: draft-bell-ipdc-signaling-00.txt Date: August 1998 6 IPDC 7 Device Management Protocol 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, 14 and its working groups. Note that other groups may also distribute 15 working 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 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The protocol described in this document is a member of the IP Device 31 Control (IPDC) family of protocols. The IPDC protocols are proposed 32 as a protocol suite, components of which can be used individually or 33 together to perform connection control, media control, and signaling 34 transport for environments where the service control logic is 35 separated from the network access server. Please see the references 36 section for other IPDC documents. 38 The protocol specification presented here is intended for use between 39 a media gateway controller and a media gateway. The media gateway 40 may be capable of acting as a voice over IP gateway, voice over ATM 41 gateway, dialup modem media gateway, circuit switch, or cross- 42 connect. Using the IP Device Signaling Transport protocol presented 43 here, the media gateway can receive a signaling from a circuit 44 switched network and deliver the signaling to a media gateway 45 controller on an intervening IP network. The media gateway 46 controller can also send signaling to a media gateway for delivery on 47 a circuit switched network. 49 Table of Contents 51 1.0 Introduction 52 1.1 Background 53 2.0 Protocol Definition 54 2.1 Specification of Requirements 55 2.2 Messages 56 2.2.1 Native Mode Q.931 Signalling 57 2.2.2 Tunneled Mode Signalling 58 3.0 New AVP Values 59 3.1 Control Channel IPDC-Reference AVP 60 3.2 PDU Block AVP 61 3.3 Protocol Type AVP 62 4.0 Examples of usage 63 4.1 Native Q.931 Mode Signalling 64 4.2 Tunneled Mode Signalling 65 5.0 Security Considerations 66 6.0 Rights and Permissions 67 7.0 Acknowledgments 68 8.0 References 69 9.0 Authors Address 71 1.0 Introduction 73 The messaging specification presented here is intended for use 74 between a media gateway and a media gateway controller. The media 75 gateway may be capable of acting as a voice over IP gateway, dialup 76 modem access server, or circuit switch. Using the IP Signaling 77 Transport (IPST) protocol within this document, the media gateway 78 controller (MGC) can send messages to the media gateway to setup and 79 clear connections within a media gateway (MG) or between media 80 gateways. 82 1.1 Background 84 This document is part of the IPST family of protocols. The IPDC 85 protocols have been proposed as a protocol suite that can be used 86 individually or together to perform connection control, media 87 control, and signaling transport for environments where the MGC is 88 separate from the MG itself. Please see the references section for a 89 list of other IPDC documents. 91 This document describes the commands and attribute value pairs that 92 are necessary within the IP Signaling Transport (IPST) messaging set 93 to allow the MGC to perform call and media control on the MG. This 94 control provides the ability for the MGC to setup, modify and clear 95 connections within a MG. 97 A MG may support multiple types of connections within itself and to 98 other MGs or endpoints. These connections are based upon the 99 specification of two MG entities or endpoints for each connection 100 request. The IPDC base specification describes the format for the 101 specification on these endpoints, This format may be seen in the 102 definition of the IPDC-Reference AVP. The base document describes a 103 set of references for device-based endpoints as well as "other entity 104 types" for packet based endpoints. 106 IPST provides a mechanism to transport call signaling information 107 between the MGC and the MG in a stateless fashion relative to the 109 +--------------------------------+ +----------------+ 110 | | | | 111 | +-----------+ +-+ +----------+ | | +----------+ | 112 | | External | |I| |Q.931/IPST| | | |Q.931/IPST| | 113 | | Signaling | |W| |Protocol | | | |Protocol | | 114 <->| | Protocol | |F| |Stack | |<-->| |Stack | | 115 | | Stack | | | | | | | | | | 116 | +-----------+ +-+ +----------+ | | +----------+ | 117 | | | | 118 | Media Gateway | | Media Gateway | 119 | | | Controller | 120 | | | | 121 +--------------------------------+ +----------------+ 123 Figure 1-1 Native Q.931 Mode Signaling 124 (IWF = Interworking Function) 126 link. There are two modes of operation presented in this document. 127 The first, styled as "Native Mode Q.931 Signaling" uses ITU-T Q.931 128 messages and Information Elements to convey signaling information to 129 and from the associated MGC-MG pair. Figure 1-1 illustrates the 130 structural requirements for native mode signaling. In this case, the 131 MG terminates the external signaling protocol and passes only 132 indications to the MGC in the form of stateless Q.931 messages. 134 The second, "styled as "Tunneled Signaling" provides transparent 135 transport for external signaling through the MG and is terminated at 136 the MGC. 138 +------------------------+ +-------------------------+ 139 | | | | 140 |+-----------++---------+| |+---------++-++---------+| 141 || Layer 2 ||Tunneled || ||Tunneled ||I||Layer 3 || 142 || Signaling ||IPST || ||IPST ||W||Protocol || 143 <->|| Protocol ||Protocol ||<-->||Protocol ||F||Stack || 144 || Stack ||Stack || ||Stack || ||(eg Q931)|| 145 |+-----------++---------+| |+---------++-++---------+| 146 | | | | 147 | Media Gateway | | Media Gateway | 148 | | | Controller | 149 | | | | 150 +------------------------+ +-------------------------+ 152 Figure 1-2 Tunneled Mode Signaling 153 (IWF = Interworking Function) 155 Figure 1-2 illustrates the structural requirements for the tunneled 156 mode signaling. In this case, the MG terminates only the lower layers 157 of the protocol stack. The higher layer signaling protocol is 158 encapsulated into a tunneled message and passed upward to the MGC for 159 processing. Both the protocol termination and the interworking 160 function exist in the MGC. 162 2.0 Protocol Definition 164 2.1 Specification of Requirements 166 In this document, several words are used to signify the requirements 167 of the specification. These words are often capitalized. 169 MUST This word, or the adjective "required", means that the 170 definition is an absolute requirement of the specification. 172 MUST NOT This phrase means that the definition is an absolute 173 prohibition of the specification. 175 SHOULD This word, or the adjective "recommended", means there may 176 exist valid reasons in particular circumstances to ignore this item, 177 but the full implications must be understood and carefully weighed 178 before choosing a different course. 180 MAY This word, or the adjective "optional", means that this item is 181 one of an allowed set of alternatives. An implementation which does 182 not include this option MUST be prepared to interoperate with another 183 implementation which does include the option. 185 2.2 Messages 187 This section describes the IPST commands that are described within 188 this document. All IPST implementations that support the signaling 189 transport extension MUST support one or the other of the following 190 commands depending upon which mode of operation is active: 192 Command Command Code Description 193 ------- ------------ -------------------------------------- 194 NATIVE 1800 (0x708) Transport native mode Q.931 signaling 196 TUNNELED 1801 (0x709) Transparent transport of signaling 197 protocol data units (Tunneling) 199 An implementation MAY support both modes, although only one MAY be 200 active at any time for a single circuit interface. 202 IPST messages are constructed in the same way as any IPDC message, 203 using a standard header followed by Attribute-Value pairs. The 204 standard header and required AVP information may be found in the IPDC 205 Base Document, reference [1]. 207 In the case of Tunneled Signaling, a transaction consists of all 208 messages exchanged between the MG and its associated MGC from the 209 initial signaling connection until the connection is dropped. Its 210 duration is effectively infinite. 212 For Native Mode Q.931 Signaling, a transaction consists of the set of 213 Q.931 messages related to a single call. The transaction begins with 214 the transmission of a SETUP message and terminates with the 215 transmission of a RELEASE COMPLETE message. 217 2.2.1 Native Mode Q.931 Signaling 219 In Native mode signaling, the MG maintains an external signaling 220 engine relative to the GSTN interface. Since state control is 221 accomplished by that function, the Native mode signaling need not be 222 state driven. 224 Events detected at the external signaling point are translated into 225 Q.931 messages with their associated IEs. The Q.931 message is then 226 encapsulated in a PDU Block AVP. This AVP contains the Q.931 message 227 as data. The format of the Native Mode Signaling data is determined 228 by the Q.931 message and is defined in ITU-T Recommendation Q.931, 229 reference [2]. 231 The single exception to the Q.931 signaling procedures as described 232 in ITU-T Recommendation Q.931 is that call clearing is indicated by 233 sending a RELEASE COMPLETE from the end initiating the call clearing 234 to its peer. 236 In addition to the PDU Block AVP, there may be other AVPs that are 237 exchanged to provide information not available within the Q.931 238 message itself. 240 The AVP content of the NATIVE message is presented below. 242 0 1 2 3 243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 244 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 245 | | 246 | Message Header | 247 | | 248 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 249 | Diameter Command AVP Code | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | AVP Length | AVP Flags | Reserved | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Native Mode Signaling Command Code | 254 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 255 | | 256 | Transaction Originator Host-Name AVP | 257 | | 258 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 259 | | 260 | Control Channel IPDC-Reference AVP | 261 | | 262 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 263 | | 264 | PDU Block AVP | 265 | | 266 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 268 AVP Code 269 256 DIAMETER-Command 271 AVP Length 273 The length of this attribute MUST be at exactly 12. 275 AVP Flags 277 The flag field MUST have bit one (Mandatory Support) set. Bit two 278 (SS-Encrypted-Data), Bit three (PK-Encrypted-Data) and Bit four 279 (Vendor-Specific-AVP) SHOULD NOT be set. 281 Reserved 283 The Reserved field MUST be set to zero (0). 285 Command Code 287 1800 Native Mode Signaling Command Code 289 Transaction Originator Host Name AVP 291 The host name of the initiator of the transaction. This is a 292 required parameter for all IPDC protocol messages. 294 Control Channel IPDC-Reference AVP 296 Required for all IPST messages, this AVP identifies the control 297 channel within the media gateway upon which the native mode 298 signaling PDU was received or upon which a native mode signaling 299 PDU will be sent. 301 PDU Block AVP 303 Required for all IPST Native Mode messages, this AVP contains the 304 Q.931 PDU in total. 306 The format of the Transaction Originator Hostname is of type IPDC 307 Reference, and the format is given in the IPDC Base Protocol 308 Document, reference [1]. 310 The Control Channel IPDC-Reference, and the PDU Block are both 311 presented in the New AVP Values section of this document. 313 2.2.2 Tunneled Mode Signaling 315 In the tunneled mode of signaling, the MG does not terminate the 316 signaling messaging. It may terminate the lower levels (such as Layer 317 2 in ISDN) but merely relays the received protocol data elements from 318 the MGC to the GSTN and vice-versa. The format of the Tunneled 319 message is shown below. 321 0 1 2 3 322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 323 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 324 | | 325 | Message Header | 326 | | 327 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 328 | Diameter Command AVP Code | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | AVP Length | AVP Flags | Reserved | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Tunneled Mode Signaling Command Code | 333 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 334 | | 335 | Transaction Originator Host-Name AVP | 336 | | 337 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 338 | | 339 | Control Channel IPDC-Reference AVP | 340 | | 341 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 342 | | 343 | Protocol Type AVP | 344 | | 345 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 346 | | 347 | PDU Block AVP | 348 | | 349 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 351 AVP Code 353 256 DIAMETER-Command 355 AVP Length 357 The length of this attribute MUST be at exactly 12. 359 AVP Flags 361 The flag field MUST have bit one (Mandatory Support) set. Bit two 362 (SS-Encrypted-Data), Bit three (PK-Encrypted-Data) and Bit four 363 (Vendor-Specific-AVP) SHOULD NOT be set. 365 Reserved 367 The Reserved field MUST be set to zero (0). 369 Command Code 371 1801 Tunneled Mode Signaling Command Code 373 Transaction Originator Host Name AVP 375 The host name of the initiator of the transaction. This is a 376 required parameter for all IPDC protocol messages. 378 Control Channel IPDC-Reference AVP 380 Required for all IPST messages, this AVP identifies the control 381 channel within the media gateway upon which the native mode 382 signaling PDU was received or upon which a native mode signaling 383 PDU will be sent. 385 Protocol Type AVP 387 Indicates the type of protocol being tunneled. If this field is 388 not present then the protocol type is presumed to be Q.931. 390 PDU Block AVP 392 Required for all IPST Native Mode messages, this AVP contains the 393 Q.931 PDU in total. 395 The format of the Transaction Originator Hostname is of type IPDC 396 Reference, and the format is given in the IPDC Base Protocol 397 Document, reference [1]. 399 The Control Channel IPDC-Reference, Protocol Type and the PDU Block 400 AVPs are presented in the New AVP Values section of this document. 402 3.0 New AVP Values 404 There are three new AVPs defined in this document. These are: 406 AVP Name AVP Value Description 407 ------------------ ------------ ---------------------------- 408 Control Channel 1900 (0x76C) Identifies the control 409 IPDC-Reference endpoint for GSTN signaling 410 PDU Block 1901 (0x76D) Contains the embedded 411 protocol data elements 413 Protocol Type 1902 (0x76E) Identified the type of 414 signaling protocol being 415 transported 417 Each is addressed below. 419 3.1 Control Channel IPDC-Reference AVP 421 This AVP provides the IPDC-Reference descriptor for the control 422 channel associated with this signaling event. 424 AVP Code 426 1900 Control Channel IPDC Reference 428 AVP Length 430 The length of this attribute MUST be at least 12 to accommodate 8 431 bytes of AVP header information plus a minimum 4 byte data field. 432 The character coding of this attribute is likely to make this 433 field considerably longer than 12. 435 AVP Flags 437 The flag field MUST have bit one (Mandatory Support) set. The 438 flag field MUST not have bit four (Vendor Specific AVP) set. 440 Control Channel IPDC-Reference 442 The Control Channel IPDC-Reference AVP is used to identify the 443 signaling endpoint for GSTN gateway. The value of this field is of 444 type IPDC Reference and the definition of this type may be found 445 in the IPDC Base Protocol Document, reference [1]. 447 3.2 PDU Block AVP 449 The PDU Block AVP encapsulates a signaling protocol data unit (PDU) 450 for transmission from or to the MGC. 452 AVP Code 454 1901 PDU Block 456 AVP Length 457 The length of this attribute MUST be at least 12 to accommodate 8 458 bytes of AVP header information plus a minimum 4 byte data field. 459 The actual encoding of this PDU Block may extend the length 460 considerably beyond the 12 byte minimum. The PDU Block is padded 461 in length to a multiple of 4 bytes. 463 AVP Flags 465 The flag field MUST have bit one (Mandatory Support) set. The 466 flag field MUST not have bit four (Vendor Specific AVP) set. 468 PDU Block Data 470 This field contains the formatted protocol data unit for 471 transport. If the Protocol Type AVP is present, this data field is 472 encoded according to the rules specified for the designated 473 protocol type. Otherwise, this data field is encoded as a simple 474 Q.931 PDU. 476 3.3 Protocol Type AVP 478 The Protocol Type AVP indicates the underlying signaling protocol to 479 be used on to interpret the accompanying PDU Block AVP. 481 AVP Code 483 1902 Protocol Type 485 AVP Length 487 The length of this attribute MUST be 12 to accommodate 8 bytes of 488 AVP header information plus a 4 byte integer32 data field. 490 AVP Flags 492 The flag field MUST have bit one (Mandatory Support) set. The flag 493 field MAY have bit four (Vendor Specific AVP) set. 495 Protocol Type Value 497 This field contains an integer-32 value corresponding to a 498 signaling protocol type. The following table of values represents 499 those protocol types currently defined. 501 Value Protocol 502 ---------- --------------- 503 0x00000001 ITU-T Q.931 504 0x00000002 ITU-T SS7 505 0x00000003 National ISDN-1 506 0x00000004 National ISDN-2 507 0x00000005 Euro-ISDN 508 0x00000006 QSIG 510 Additional protocol types may be assigned as needed. 512 4.0 Examples of Usage 514 The following examples illustrate the usage of these two types of 515 signaling. 517 4.1 Native Q.931 Mode Signaling 519 This example is of a 4 wire analog trunk using a wink start 520 procedure. The diagram in Figure 4-1 illustrates the message flow 521 between the MG and the MGC as a result of signaling events at the MG- 522 GSTN interface. 524 MGC MG GSTN 525 | | Incoming Seizure | 526 | |<---------------------------| 527 | | | 528 | | Return Wink | 529 | |--------------------------->| 530 | | | 531 | | Dialed Digit 1 | 532 | |<---------------------------| 533 | | Dialed Digit 2 | 534 | |<---------------------------| 535 | | Dialed Digit 3 | 536 | |<---------------------------| 537 | | Dialed Digit 4 | 538 | |<---------------------------| 539 | Native AVP (Setup) | | 540 |<------------------------| | 541 | Native AVP (Alerting) | | 542 |------------------------>| | 543 | Native AVP (Connect) | | 544 |------------------------>| Return Seizure | 545 | |--------------------------->| 546 | | | 547 |<---------------------------------------------------->| 548 | Conversation | 549 |<---------------------------------------------------->| 550 | | | 551 | Native AVP (Rel Compl.) | | 552 |------------------------>| Release Seizure | 553 | |--------------------------->| 554 | | | 555 | | Seizure Release | 556 | |<---------------------------| 557 | | | 559 Figure 4-1, 4-Wire Analog Trunk Incoming Call 561 In the above example, the GSTN initiates an inbound call by seizing 562 the trunk at the MG-GSTN interface. The MG returns a wink to indicate 563 that it is ready to receive digits. The GSTN then sends 4 digits to 564 the MG. Having all the digits needed, the MG sends a Native message 565 with a PDU Block containing a Q.931 SETUP message with the dialed 566 digits. As interworking occurs, the MCG sends a Native message with 567 the PDU Block containing an ALERTING message, followed by a Native 568 message with a PDU Block containing a CONNECT message. The CONNECT 569 message may also contain the connection control AVPs to complete the 570 RTP connections. The MG then returns seizure toward the GSTN to 571 indicate that the distant station has answered. The users are now in 572 conversation. 574 To clear the call, the MCG sends a Native message with the PDU Block 575 containing a RELEASE COMPLETE message. The MG responds by releasing 576 seizure towards the GSTN. The GSTN releases seizure towards the MG 577 and the call is complete. 579 The diagram in Figure 4-2 illustrates the reverse operation in which 580 the MGC initiates an outbound call on a 4-wire Analog Interface. 582 MGC MG GSTN 583 | Native AVP (SETUP) | Outgoing Seizure | 584 |------------------------>|--------------------------->| 585 | | | 586 | | Return Wink | 587 | |<---------------------------| 588 | | | 589 | | Dialed Digit 1 | 590 | |--------------------------->| 591 | | Dialed Digit 2 | 592 | |--------------------------->| 593 | | Dialed Digit n | 594 | |--------------------------->| 595 | Native AVP (Proceeding) | | 596 |<------------------------| Return Seizure | 597 | Native AVP (Connect) |<---------------------------| 598 |<------------------------| | 599 | Native AVP (Connect Ack)| | 600 |------------------------>| | 601 |<---------------------------------------------------->| 602 | Conversation | 603 |<---------------------------------------------------->| 604 | | | 605 | | | 606 | | Release Seizure | 607 | Native AVP (Rel Compl.) |<---------------------------| 608 |<------------------------| | 609 | | Seizure Release | 610 | |--------------------------->| 611 | | | 613 Figure 4-2 4-Wire Analog Trunk Outgoing Call 614 In the above example, the MGC requests an outgoing call by sending a 615 Native CMD with a PDU Block containing a SETUP message. If the trunk 616 is to be used for "fast connect", this Native CMD MUST also contain 617 the connection control AVPs needed to establish connections. In 618 response to the SETUP, the MG seizes the outbound trunk and waits for 619 "wink". Upon receiving "wink", the MG sends the supplied digits to 620 the GSTN. At the completion of digit transmission, the MG returns a 621 Native CMD with a PDU Block containing a CALL PROCEEDING message. 622 When the distant end station answers, the GSTN sends a return seizure 623 to the MG. The MG then sends a Native CMD with a PDU Block containing 624 a CONNECT message to the MGC. If the connection control AVPs have not 625 been sent already, the MGC sends a Native CMD with a PDU Block 626 containing a CONNECT ACK message and the required connection control 627 AVPs. The conversation is now active. 629 In this example, the GSTN releases the call first by releasing 630 seizure. The MG sends a PDU Block containing a RELEASE COMPLETE 631 message to the MGC and releases seizure towards the GSTN. The call is 632 now completed. 634 4.2 Tunneled Mode Signaling 636 Tunneling Mode Signaling simply encapsulates the underlying signaling 637 messages and sends them either to the MG or the MGC. The diagram in 638 4-3 illustrates this operation. The sequence is self-explanatory. The 639 protocol type AVP contains the value 2 to indicate that the trunk is 640 a National ISDN-1 trunk. 642 MGC MG GSTN 643 | Tunneled AVP (SETUP) | SETUP | 644 |------------------------>|--------------------------->| 645 | | | 646 | | CALL PROCEEDING | 647 | Tunneled AVP (Proceedin)|<---------------------------| 648 |<------------------------| | 649 | Tunneled AVP (Alerting) | | 650 |------------------------>| | 651 | | ALERTING | 652 | |--------------------------->| 653 | IPCC RCON | | 654 |------------------------>| | 655 | IPCC ACON | | 656 |<------------------------| | 657 | Tunneled AVP (Connect) | | 658 |------------------------>| CONNECT | 659 | |--------------------------->| 660 |<---------------------------------------------------->| 661 | Conversation | 662 |<---------------------------------------------------->| 663 | | | 664 | | | 665 | | DISCONNECT | 666 | Tunneled AVP (Disconn.) |<---------------------------| 667 |<------------------------| | 668 | IPCC RCR | | 669 |------------------------>| | 670 | IPCC ACR | | 671 |<------------------------| | 672 | Tunneled AVP (Release) | | 673 |------------------------>| RELEASE | 674 | |--------------------------->| 675 | | RELEASE COMPLETE | 676 | |<---------------------------| 677 | Tunneled AVP (Rel. Comp)| | 678 |<------------------------| | 680 Figure 4-3, Tunneled Mode ISDN Signaling 682 5.0 Security Considerations 684 Security considerations for these modes of signaling are addressed in 685 the IP Device Control Base Protocol document, reference [1]. These 686 issues are not addressed here. 688 6.0 Rights and Permissions 690 The contributors to this document are listed in the author's address 691 and acknowledgement sections of the document. All contributors to 692 this document and the organizations we represent grant an unlimited 693 perpetual, non-exclusive, royalty-free, world-wide right and license 694 to any party under the copyrights in the contribution. This license 695 includes the right to copy, publish and distribute the contribution 696 in any way, and to prepare derivative works that are based on or 697 incorporate all or part of the contribution, the license to such 698 derivative works to be of the same scope as the license of the 699 original contribution. The contributors grant permission to reference 700 the names and addresses of the contributors and of the organizations 701 we represent. We agree that no information in the contribution is 702 confidential and that the any party may freely disclose any 703 information in the contribution. 705 The contributors to this document believe that the organizations we 706 represent have the authority to grant the rights stated herein. The 707 contributors to this document will grant any party a perpetual, non- 708 exclusive, royalty-free, world-wide right to implement, use and 709 distribute the technology or works when implementing, using or 710 distributing technology based upon the specific specification. 712 The contributors represent that we have disclosed the existence of 713 any proprietary or intellectual property rights in the contribution 714 that are reasonably and personally known to the contributors. The 715 contributors do not represent that we personally know of all 716 potentially pertinent proprietary and intellectual property rights 717 owned or claimed by the organization he represents (if any) or third 718 parties. 720 The contributors represent that there are no limits to the 721 contributors' ability to make the grants, acknowledgments and 722 agreements above that are reasonably and personally known to the 723 contributors. 725 7.0 Acknowledgments 727 The author wishes to acknowledge the following individuals for their 728 contribution to the IP Signaling Control protocol: 730 Ilya Akramovich, Bob Bell, Dan Brendes, Peter Chung, Russ Dehlinger, 731 Andrew Dugan, Ike Elliott, Cary FitzGerald, Jan Gronski, Tom Hess, 732 Geoff Jordan, Tony Lam, Shawn Lewis, Dave Mazik, Pete O'Connell, 733 Shyamal Prasad, Paul Richards, Dale Skran, Louise Spergel, Raj 734 Srinivasan, Tom Taylor, Michael Thomas. 736 8.0 References 738 [1] Taylor, "IP Device Control Base Protocol" 739 [2] ITU-T, "Recommendation Q.931", March 1993 740 [3] Dugan, "IP Device Connection Control Protocol" 741 Other references: 743 Calhoun, Rubens, "DIAMETER Base Protocol". Internet-Draft, draft- 744 calhoun-diameter-03.txt, May 1998. 745 Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-Draft, draft- 746 calhoun-diameter-framework-00.txt, May 1998. 747 Elliott, "IP Media Control Protocol", Internet-Draft, draft-elliott- 748 ipdc-media-00.txt, August, 1998. 749 Skran, "IP Device Control Framework" 750 Pickett, "IP Device Management Protocol", Internet-Draft, draft- 751 pickett-ipdc-management-00.txt, August, 1998 753 9.0 Author's Address 755 Questions about this document can be directed to: 757 Bob Bell Selsius Systems Inc. 640 N. Main St. Suite 2246 North 758 Salt Lake, Utah 84054 760 Phone: 1-801-294-3034 761 Fax: 1-801-294-3023 762 Email: bbell@selsius.com 764 Page - ii 765 5 August, 1998 767 Page - i 5 August, 1998