idnits 2.17.1 draft-taylor-mmusic-sdp-tdm-01.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (April 2002) is 8047 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) -- Missing reference section? '2' on line 49 looks like a reference -- Missing reference section? '3' on line 49 looks like a reference -- Missing reference section? '4' on line 51 looks like a reference -- Missing reference section? '5' on line 74 looks like a reference -- Missing reference section? '6' on line 52 looks like a reference -- Missing reference section? '7' on line 64 looks like a reference -- Missing reference section? '8' on line 69 looks like a reference -- Missing reference section? '9' on line 70 looks like a reference -- Missing reference section? '10' on line 83 looks like a reference -- Missing reference section? '1' on line 600 looks like a reference -- Missing reference section? '11' on line 238 looks like a reference -- Missing reference section? '13' on line 224 looks like a reference -- Missing reference section? '14' on line 239 looks like a reference -- Missing reference section? '15' on line 296 looks like a reference -- Missing reference section? '41' on line 488 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 T. Taylor 2 Internet Draft Nortel Networks 3 Document: draft-taylor-mmusic-sdp-tdm-01.txt 4 Expires: October 2002 April 2002 6 Conventions for the use of the Session Description Protocol (SDP) 7 for Digital Circuit Connections 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes conventions for using the Session 32 Description Protocol (SDP) for controlling digital circuits. These 33 conventions describe 34 - circuit addressing conventions for use on the SDP "c=" line 35 - content of the "m=" line(s) for digital circuits 36 - attributes to convey the parameters contained within the Bearer 37 Capability, Low Layer Compatibility, and High Layer Compatibility 38 Information Elements of ITU-T Recommendation Q.931. 40 These conventions have been defined for use in media gateway 41 control, particularly in support of NAS operation, but may also be 42 used by IP-based call signalling schemes (SIP, BICC) to control 43 media exchange over digital circuits. 45 1. Introduction 47 The scope of SDP control is being extended to a variety of bearer 48 types, particularly to serve the needs of media gateway control 49 protocols such as Megaco/H.248 [2] and MGCP [3], but also those of 50 the bearer-related portions of call signalling over the internet as 51 represented by SIP [4] and BICC [5]. Control of ATM bearers was 52 documented in [6]. This document uses [6] as a model for a rather 53 simpler case, the control of 64 kbit/s digital circuits. These 54 circuits may carry voice, video or multiplexed multimedia, voiceband 55 data (fax relay, modem relay), or baseband data (PPP, frame relay 56 etc.). 58 The conventions in this document may be applied in three possible 59 situations: 61 (1) For media gateway control at the boundary between an ISDN 62 access network and another bearer network. In this case, SDP 63 must capture bearer characteristics conveyed in the Q.931 call 64 signalling protocol [7]. 66 (2) For media gateway control at the boundary between an ISDN core 67 network and another bearer network. In this case, SDP must 68 capture bearer characteristics conveyed in the SS7 ISUP call 69 signalling protocol [8]. Since a mapping has been defined 70 between ISUP and Q.931 [9], the SDP conventions required will 71 be in large part the same as in the first case. 73 (3) For control of TDM circuits across a network using SIP or BICC 74 [5]. This is a potential future application, included here for 75 logical completeness, since neither SIP nor BICC is currently 76 being designed with TDM circuit networks in mind. 78 1.1 Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 82 this document are to be interpreted as described in RFC 2119 [10]. 84 "TDM" stands for "Time Division Multiplex" digital transmission. 86 In this document, the term "TDM circuit" is used to mean a 64 kbit/s 87 TDM channel. 89 1.2 Scope 91 This document provides the means to describe media flows in TDM 92 circuits. Although it will be of use in the general categories of 93 applications described in the introduction, it is specifically aimed 94 at satisfying the requirements of the Megaco/H.248 media gateway 95 control protocol including the voice, voice-band data (and NAS 96 operation in particular), and multimedia conferencing (H.320 and 97 H.324i) applications. 99 This document provides conventions for: 100 - use of the SDP "b=" line to convey the TDM circuit information 101 transfer rate 102 - addressing of TDM circuits on the SDP "c=" line 103 - the transport types TDM, PKT/TDM, and FRM/TDM 104 - a description of the content carried by the TDM circuit on the 105 SDP "m=" line 106 - attributes to convey the content of the Q.931 Low Layer and High 107 Layer Compatibility Information Elements. 109 The present issue of this document excludes the following: 111 1. Mapping of Layer 2 and Layer 3 protocol parameters (e.g. for 112 X.25, frame relay) into SDP attributes. It is assumed that such 113 mappings will be defined in separate protocol-specific documents 114 if they are required. 116 2. Bearer capability negotiation. Q.931 and ISUP support the 117 inclusion of multiple Bearer Capability Information Elements for 118 negotiation. This document supports transfer of only one set of 119 bearer capability information per session description. 121 3. Support of multi-rate (N x 64 kbit/s) service. 123 This document conforms to the syntactic conventions of SDP as 124 defined in [1]. 126 1.3 Why Are TDM-Circuit-Specific Conventions Needed? 128 SDP was originally designed for the description of media sessions 129 carried over IP packets, typically using RTP [11] encapsulation and 130 UDP transport. In contrast, description of media transport over TDM 131 circuits must begin at a much lower level, with the basic 132 organization of the bits across the 64 kbit/s channel. Moreover, 133 the higher-layer organization of the content is typically negotiated 134 "in-band", through protocols such as V.8bis or V.140. This forces a 135 re-interpretation of the contents of the SDP "m=" line in 136 particular, and the creation of a number of additional attributes to 137 describe the lower layers of transport. 139 Addressing of TDM circuits is also different, and for media gateway 140 control is actually irrelevant, since the information is conveyed by 141 other means (terminationIDs in Megaco/H.248, and endpoint 142 identifiers in MGCP). This affects the SDP "c=" line and makes 143 redundant the port identification on the "m=" line. 145 The other lines of the SDP session description can generally be used 146 without modification from their use as described in [1], with the 147 following notes: 149 1. If the "b=" line is present, it MUST indicate a bandwidth of 64 150 (kbit/s). The modifier used is "AS". The effective user rate, 151 if less than this, is indicated by an attribute within the media 152 description. 154 2. The "k=" line MAY be present. There are probably consistency 155 conditions on the media format value in this case. 157 1.4 Changes From The Previous Version 159 The main change from the previous version has been to limit the 160 scope of the present document by placing greater reliance on the 161 Megaco/H.248 multiplex concept. This has meant the removal of 162 wideband or aggregated N x 64 kbit/s service from the scope of the 163 document, and the reduction of H.320 and H.324 sessions to 164 application/octet-stream media flows from the point of view of TDM 165 transport. (Separate documents define SDP conventions for the H221, 166 H223, and H226 transport types.) 168 The syntax in this version conforms to [1] rather than RFC 2327. 170 MIME subtype registrations for audio/PCMU, audio/PCMA, audio/G721, 171 and application/octet-stream over TDM have been added in the 172 appendices. 174 2. "c=" Line For TDM circuits 176 The connection field ("c=" line) is structured as follows [1]: 178 connection-field = "c=" nettype space addrtype space 179 connection-address CRLF 181 This document reserves a nettype value of "TDM" for TDM circuits. 183 The present issue of this document proposes two naming schemes for 184 TDM circuits: the NUL scheme (addrtype is "NUL") and the group-and- 185 member scheme (addrtype is "GRP"). Future issues of this document 186 may specify other schemes. 188 The NUL scheme is suitable for use with media gateway control, since 189 other means are available (as mentioned above) for designating the 190 TDM circuit. The NUL connection-address MUST be present, but may be 191 any string satisfying the syntactical requirements of [1], for 192 example, "x". The receiver MUST ignore the connection-address when 193 addrtype is NUL. 195 The GRP scheme designates a logical or physical grouping of circuits 196 within which individual 64 kbit/s channels may be identified by 197 integer values. The GRP connection-address consists of two parts. 198 The first part identifies the logical or physical group, while the 199 second identifies the individual circuit within the group. 201 grp-connection-address = group-part "/" member-part 203 group-part = non-ws-string ; as defined in [1] 204 member-part = non-ws-string ; as defined in [1] 205 Over all, the syntax conforms to the extension-addr form of unicast- 206 address as defined in [1]. There is one additional restriction: 207 member-part MUST NOT contain the "/" character. 209 3. "m=" Line For TDM Circuits 211 [1] defines the syntax of the media field ("m=" line) as follows: 213 media-field = "m=" media space port ["/" integer] 214 space proto 1*(space fmt) CRLF 216 3.1 Specification of Medium and Format 218 In accordance with [1], the media token must be a MIME type and the 219 fmt token must reference a MIME subtype. Since existing MIME type 220 registration is for packet transport, it will be necessary to add or 221 extend registrations to include TDM transport. Where possible, the 222 extension route is preferable. 224 Based on RFC 2046 [13] and a review of the various fields of the 225 Bearer Capability Information Element, the two possible settings for 226 the media token appear to be "audio" and "application". The 227 available range of subtypes is more problematic. 229 We begin the discussion with "audio". RFC 2046 defines one audio 230 subtype: "basic". This denotes G.711 mu-law PCM. This would be 231 been quite acceptable to match the Q.931 User Information Layer 1 232 protocol codepoint "Recommendation G.711 mu-law", but leaves 233 "Recommendation G.711 A-law" out in the cold. Very fortunately, the 234 AVT Working Group has created a new document [14] to register RTP 235 payload types as MIME subtypes. Two of these subtypes are 236 audio/PCMA and audio/PCMU, corresponding to A-law and Mu-law 237 companding respectively. The Q.931 codepoint "Recommendation G.721 238 [11] 32 kbit/s ADPCM and Recommendation I.460" is actually for 239 G.726, which is covered in [14] by the audio/G726-16, audio/G726-24, 240 audio/G726-32, and audio/G726-40 MIME subtypes. 242 The Q.931 codepoints "Recommendations H.221 and H.242" and 243 "Recommendations H.223 and H.245" refer to the use of H.320 and 244 H.324I multimedia conferencing, respectively. In the Megaco/H.248 245 model, the TDM circuits carrying these sessions feed into 246 terminations representing the respective multiplexes. It is the 247 responsibility of the multiplexes to manage the audio, video, data, 248 and control flows. The SDP for this purpose is documented 249 separately, on the premise that each multiplex represents another 250 transport type. From the TDM point of view, the flows are 251 undifferentiated, so the MIME subtype application/octet-stream is 252 appropriate. 254 "application/octet-stream" is probably adequate to cover the other 255 possibilities provided for in Q.931. 257 In summary, the possible medium/format combinations for TDM 258 transport are: 259 - audio/pcma 260 - audio/pcmu 261 - audio/g726-16, 24, 32, 40 262 - application/octet-stream 263 The MIME registrations for all of these must be updated to note the 264 possibility of transport over TDM. This is done in the appendices 265 to the present document. 267 If the nature of the medium (typically "audio") is known, it should 268 be specified accordingly. Otherwise, medium and format are derived 269 from the Transmission Mode, Information Transfer Capability, and 270 User Information Layer 1 Protocol of the bearer, as follows: 272 1. Set media = "application" if Transmission Mode is not 273 "circuit", or if Information Transfer Capability is 274 "unrestricted digital information" or "restricted digital 275 information". 277 2. If Transmission Mode is "circuit" and Information Transfer 278 Capability is "Speech" or "3.1 kHz audio", set media = 279 "audio". 281 3. If Transmission Mode is "circuit" and Information Transfer 282 Capability is "Unrestricted digital information with tones and 283 announcements", set media = "audio" while the call is being 284 set up, then set it to "application". 286 4. If Transmission Mode is "circuit" and Information Transfer 287 Capability is "Video", set media = "application". 288 "Application" is more appropriate than "video" as a MIME type 289 because the bit stream carries more than just video and an 290 application tool is required to interpret it. 292 3.2 Specification of Port 294 Port number is inapplicable to TDM circuits, but must be specified 295 to satisfy SDP syntax. Where the present specification is being 296 used in circumstances in which the offer-answer model [15] applies, 297 setting port = 0 indicates rejection of a media stream. It is 298 therefore RECOMMENDED that the sender set port = 1 except when it is 299 being used in this way. The receiver must ignore non-zero port 300 values, and must ignore zero values unless the application is one to 301 which the offer-answer model applies. Megaco/H.248 in particular 302 does not conform to the offer-answer model, and port is therefore 303 irrelevant. 305 3.3 Specification of Protocol 307 Q.931 and Q.939 distinguish between protocol information which the 308 network sees and may modify (in the Bearer Capability Information 309 Element) and protocol information which is available only between 310 endpoints (in the Low Layer Compatibility Information Element). 312 Depending on endpoint intentions, any of the protocol information at 313 layers 1, 2, or 3 may appear in either place. The only information 314 which is guaranteed to be visible to the network is the transfer 315 mode (circuit, packet, or frame mode). It is therefore proposed 316 that the transport profile on the "m=" line indicate the transfer 317 mode, but that additional protocol information be indicated on 318 attribute lines within the media description. This document 319 accordingly defines three transport profiles: 321 . "TDM" denotes circuit mode (octet-oriented) transport over a TDM 322 circuit. 324 . "PKT/TDM" denotes packet mode transport over a TDM circuit 326 . "FRM/TDM" denotes frame mode transport over a TDM circuit. 328 The audio MIME type applies only to TDM transport. The 329 application/octet-string MIME type may be carried by any of the 330 three transports. 332 4. Attributes For TDM circuits 334 4.1 Audio Transfer Capability 336 a= spchonly 338 When present, attribute "spchonly" indicates that an audio 339 connection is suitable only for speech (Q.931 Information Transfer 340 Capability = speech) and not for modem or FAX signals. 342 4.2 Bandwidth Restriction 344 a=56kmax 346 When present, this attribute indicates that the transfer rate for 347 user data is limited to 56 kbit/s per channel. ITU-T Recommendation 348 I.464 gives further details of operation under these circumstances. 350 4.3 Protocol Profile 352 The protocol profile attribute is required to distinguish payloads 353 characterized by the apllication/octet-string MIME type. 355 As mentioned above, Q.931 provides two places for user protocols to 356 be specified: in Bearer Capability, where they are subject to 357 inspection and modification by network equipment such as gateways or 358 proxies, and in Low Layer Compatibility, where they are placed for 359 the information of the remote peer. Rules for the choice of 360 placement are given in Recommendation Q.939. 362 The present document assumes that if a protocol is exposed to the 363 network, all parameters describing that protocol are also exposed. 364 Thus it is unnecessary to provide segregated versions of the various 365 protocol parameters, only of the protocol stacks themselves. 367 a=netprof: 368 a=e2eprof: 370 Attribute "netprof" lists the protocols which the sender is prepared 371 to expose to network inspection. Attribute "e2eprof" lists those 372 which are intended for remote peer use only. Attribute "netprof" 373 SHOULD be present if media = "application" on the "m=" line, even if 374 it is empty. 376 consists of up to three protocol designators, one per 377 layer, separated by "/". The protocols are ordered from highest to 378 lowest. Missing layers are omitted, along with their separators. 379 For any given layer: 380 - no protocol is specified in either "netprof" or "e2eprof", or 381 - some protocol is specified in "netprof", or 382 - some protocol is specified in "e2eprof". 384 Protocol parameters for protocols listed in "e2eprof" SHOULD be 385 transmitted by network entities without modification. 387 Examples: 389 a=netprof:Q922A 390 frame relay 392 a=e2eprof:X25P/X25L/V110 393 X.25 packet layer over X.25 link layer over V.110 rate adaption 394 (circuit mode operation with user rate less than 64 kbit/s). 396 a=e2eprof:PPP 397 layers 1 and 2 are specified in "netprof" or not needed (e.g. 398 because framing is auto-sensed). 400 4.4.1 Layer 1 Protocols 402 The following table contains the Layer 1 protocols defined in this 403 document. They correspond to the non-audio codepoints for the User 404 information layer 1 protocol given in Q.931. 406 Symbol Description 408 V110 ITU-T standardized rate adaption V.110, I.460 and 409 X.30. Requires TDM transport. 411 V120 ITU-T standardized rate adaption V.120. Requires 412 TDM transport. 414 X31 ITU-T standardized rate adaption X.31 HDLC flag 415 stuffing. Requires PKT/TDM (packet-mode) 416 transport. 418 H221 An H.320 session using the H.221 multiplex. 419 Requires TDM transport. 421 H223 An H.324/I session using the H.223 multiplex [Note 422 1]. Requires TDM transport. 424 Note 1: The H223 codepoint is not intended to preclude the use of an 425 H.226 multiplex for multilink operation in accordance with H.324 426 Annex F. 428 4.4.2 Layer 2 Protocols 430 The Layer 2 codepoints defined in Q.931 and Q.933 are shown in the 431 table below. The Layer 2 protocol MUST be specified in attribute 432 "netprof" if either PKT/TDM (packet mode) or FRM/TDM (frame mode) 433 transport is being used. 435 Symbol Description 437 Q921 Recommendation Q.921/I.441 (typically used for D- 438 channel data). 440 X25L Recommendation X.25, link layer. 442 ISO8802 LAN logical link control (ISO/IEC 8802-2) 443 Requires TDM transport. 445 Q922 Recommendation Q.922 (frame switching). Layer 1 446 must be unspecified. Requires FRM/TDM (frame 447 mode) transport. 449 Q922A Core aspects of frame mode (Annex A/Q.922) (frame 450 relay). Layer 1 must be unspecified. Requires 451 FRM/TDM (frame mode) transport. 453 ISO1745 Basic mode (ISO/IEC 1745) 455 X25ML Recommendation X.25 Multilink. 457 T71 Extended LAPB; for half duplex operation 458 (Recommendation T.71) 460 HDLC-ARM HDLC ARM (ISO/IEC 4335). 462 HDLC-NRM HDLC NRM (ISO/IEC 4335). 464 HDLC-ABM HDLC ABM (ISO/IEC 4335). 466 X75SLP Recommendation X.75 single Link Procedure (SLP). 468 ISO7776 ISO/IEC 7776 DTE-DCE operation. 470 4.4.3 Layer 3 Protocols 472 The Layer 3 codepoints defined in Q.931 are shown in the table 473 below. 475 Symbol Description 477 Q931 Recommendation Q.931 (i.e. call signalling). 479 X25P Recommendation X.25, packet layer. 481 IP Internet Protocol (RFC 791) Requires TDM 482 transport. 484 PPP Point to Point Protocol (RFC 1598, RFC 1618, or 485 RFC 1973, depending on lower layer). Requires TDM 486 transport. 488 X25PLP ISO/IEC 8208 [41] (X.25 packet level protocol for 489 data terminal equipment) 491 ISO8878 ITU-T Rec. X.223 and ISO/IEC 8878 (use of ISO/IEC 492 8208 and Recommendation X.25 to provide the OSI- 493 CONS) 495 ISO8473 ISO/IEC 8473 (OSI connectionless mode protocol) 497 T70MIN Recommendation T.70 minimum network layer 499 4.5 User Rate 501 a=userbw: 503 is the user data rate in bits per second per 64 kbit/s 504 channel within the TDM circuit. This attribute is useful in cases 505 where the user rate information is not passed end-to-end through in- 506 band signalling and negotiation. 508 4.6 In-Band Negotiation 510 a=ibneg 512 This attribute if present indicates that in-band negotiation is 513 supported by the V.110, X.30, I.460 or modem layer 1 protocol. 515 4.7 V.110/X.30/I.460 Protocol Parameters 517 a=v110parms: 519 consists of a comma-separated list of parameters. The only 520 required parameter is the intermediate rate for rate adaptation, 521 which has the form: 522 "intrat=" 523 is the intermediate rate in kbit/s, and has the possible 524 values 8, 16, 32, or "NONE". 526 The remaining parameters are keyword values, as follows: 528 "sendNIC" indicates by its presence that network-independent 529 clocking will be sent with the outgoing media stream. 531 "sendFC" indicates that flow control will be sent with the 532 outgoing media stream. 534 "recvNIC" indicates that network-independent clocking may be 535 present in the incoming media stream. 537 "recvFC" indicates that flow control may be present in the 538 incoming media stream. 540 Note that the directionality convention used here is entity- 541 relative, whereas the directionality convention in Q.931 is call- 542 relative. The two conventions coincide at the end of the TDM 543 circuit closer to the calling party, but are opposed at the end 544 closer to the called party. The convention in this document is the 545 more suitable for media gateway control, since the media gateway is 546 unaware of call direction. 548 4.8 V.120 Protocol Parameters 550 a=v120parms: 552 consists of a comma-separated list of parameters, as 553 follows. These parameters are required unless otherwise indicated. 555 "mode=" 556 Indicates whether rate adaptation mode is bit-transparent 557 ( = "transp") or protocol-sensitive ( = "protdep"). 559 "llineg=" 560 Indicates whether and how Logical Link Identifier (LLI) 561 negotiation is done. has the possible values 562 "NONE" (default) if LLI = 256 is the only value supported, "OB" 563 if negotiation is possible over a temporary signalling channel, 564 or "IB" if negotiation is done on LLI 0. 566 "hdr" 567 Optional keyword parameter. If present, indicates that the 568 rate adaption header is included. 570 "multifrm" 571 Optional keyword parameter. If present, indicates that 572 multiframe establishment is supported. 574 "assgn" 575 Optional keyword parameter. If present, indicates that the 576 message originator is "Assignor only". If absent, message 577 originator is "Default assignee". 579 4.9 Asynchronous Parameters 581 a=asynch:stop=,data=,parity=,duplex= 583 If present, indicates asynchronous data transport. 585 4.10 Modem 587 a=modem: 589 If present, indicates data transport via modem. indicates 590 the type of modem used. It may have values "V34" or "V90". Other 591 values may be added in subsequent issues of this document if 592 required. Requires TDM transport and medium specified as audio/PCMU 593 or audio/PCMA. 595 Security Considerations 597 This document deals with the signalling of information to direct the 598 transfer of user information across TDM circuits. Threats to 599 security may be identified both at the signalling level and at the 600 media transport level. See [1] for a discussion of security issues 601 at the signalling level. 603 Media transport is in general subject to threats to integrity and 604 confidentiality. (Injection of spurious media into an ongoing 605 session is classed here as a breach of integrity. Passing of 606 spurious media outside of an established session is considered to be 607 a signalling problem.) These threats are sharply reduced for TDM as 608 opposed to IP bearer transport. However, the user is not normally 609 aware of what sort of transport is in use on an end-to-end basis, 610 and the media flow may well pass from one network to another. Where 611 integrity or confidentiality are a concern, end-to-end encryption of 612 the media stream should be considered. 614 References 615 1. M. Handley, V. Jacobson, C. Perkins "SDP: Session Description 616 Protocol", IETF draft-ietf-mmusic-sdp-new-xx.txt, work in 617 progress. 619 2. B. Rosen, J. Segers et al, "Megaco Protocol Version 1.0", 620 IETF RFC 3015, Standards Track, November 2000. 622 3. C. Huitema et al, "Media Gateway Control Protocol (MGCP) 623 Version 1.0", IETF RFC 2705, Informational, October 1999. 625 4. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: 626 Session Initiation Protocol", IETF RFC 2543, Standards Track, 627 March 1999. 629 5. ITU-T Recommendation Q.1902.1-6, "Bearer Independent Call 630 Control Protocol", July, 2001. 632 6. R. Kumar, M. Mostafa, "Conventions for the use of the Session 633 Description Protocol (SDP) for ATM Bearer Connections", IETF 634 RFC 3108, Standards Track, May 2001. 636 7. ITU-T Recommendation Q.931, "Digital subscriber Signalling 637 System No. 1 � Network layer", May 1998. 639 8. ITU-T Recommendation Q.763, "Signalling system No. 7 - ISDN 640 user part formats and codes", September 1997. 642 9. ITU-T Recommendation Q.699, "Interworking between ISDN access 643 and non-ISDN access over ISDN User Part of signalling system 644 No. 7", September 1997. 646 10. S. Bradner, Key words for use in RFCs to Indicate Requirement 647 Levels, IETF RFC 2119, Best Current Practice, March 1997. 649 11. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, " RTP: 650 A Transport Protocol for Real-Time Applications", IETF RFC 651 1889, Standards Track, January 1996. 653 12. ITU-T Recommendation I.230, "Definition of bearer service 654 categories", November 1988. 656 13. N. Freed, N. Borenstein, "Multipurpose Internet Mail 657 Extensions (MIME) Part Two: Media Types", IETF RFC 2046, 658 November 1996. 660 14. S. Casner, P.Hoschka, "MIME Type Registration of RTP Payload 661 Type Formats", IETF work in progress. 663 15. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with 664 SDP", IETF Internet Draft approved as Standards Track RFC in 665 March, 2002. 667 Author's Address 669 Tom Taylor 670 Nortel Networks 671 P.O. Box 3511, Station C 672 Ottawa, Ontario Phone: +1 613 736 0961 673 Canada K1Y 4H7 Email: taylor@nortelnetworks.com