idnits 2.17.1 draft-agrawal-sip-h323-interworking-reqs-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 657. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 611 has weird spacing: '...ateways via...' == 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 (October 18, 2004) is 7123 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: 'I-D.levin-iptel-h323-url-scheme' is defined on line 604, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational RFC: RFC 3508 == Outdated reference: A later version (-09) exists of draft-ietf-iptel-tgrep-03 == Outdated reference: A later version (-04) exists of draft-ietf-sipping-overlap-03 == Outdated reference: A later version (-05) exists of draft-levin-iptel-h323-url-scheme-04 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Schulzrinne 2 Internet-Draft Columbia U. 3 Expires: April 18, 2005 C. Agboh 4 Motorola 5 October 18, 2004 7 Session Initiation Protocol (SIP)-H.323 Interworking Requirements 8 draft-agrawal-sip-h323-interworking-reqs-07 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 18, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This document describes the requirements for the logical entity known 44 as the Session Initiation Protocol (SIP)-H.323 Interworking Function 45 (SIP-H.323 IWF) that will allow the interworking between SIP and 46 H.323. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Functionality within the SIP-H.323 IWF . . . . . . . . . . . 6 54 5. Pre-Call Requirements . . . . . . . . . . . . . . . . . . . 7 55 5.1 Registration with H.323 Gatekeeper . . . . . . . . . . . . 7 56 5.2 Registration with SIP Server . . . . . . . . . . . . . . . 7 57 6. General Interworking Requirements . . . . . . . . . . . . . 8 58 6.1 Basic Call Requirements . . . . . . . . . . . . . . . . . 8 59 6.1.1 General Requirements . . . . . . . . . . . . . . . . . 8 60 6.1.2 Address Resolution . . . . . . . . . . . . . . . . . . 8 61 6.1.3 Call with H.323 Gatekeeper . . . . . . . . . . . . . . 8 62 6.1.4 Call with SIP Registrar . . . . . . . . . . . . . . . 8 63 6.1.5 Capability Negotiation . . . . . . . . . . . . . . . . 8 64 6.1.6 Opening of Logical Channels . . . . . . . . . . . . . 9 65 6.2 IWF H.323 Features . . . . . . . . . . . . . . . . . . . . 9 66 6.3 Overlapped Sending . . . . . . . . . . . . . . . . . . . . 9 67 6.3.1 DTMF Support . . . . . . . . . . . . . . . . . . . . . 10 68 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. Mapping between SIP and H.323 . . . . . . . . . . . . . . . 12 70 8.1 General Requirements . . . . . . . . . . . . . . . . . . . 12 71 8.2 H.225.0 and SIP Call Signaling . . . . . . . . . . . . . . 12 72 8.3 Call Sequence . . . . . . . . . . . . . . . . . . . . . . 12 73 8.4 State Machine Requirements . . . . . . . . . . . . . . . . 12 74 9. Security Considerations . . . . . . . . . . . . . . . . . . 14 75 10. Examples and Scenarios . . . . . . . . . . . . . . . . . . . 15 76 10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 15 77 10.2 IWF Configurations . . . . . . . . . . . . . . . . . . . 15 78 10.3 Call Flows . . . . . . . . . . . . . . . . . . . . . . . 15 79 10.3.1 Call from H.323 Terminal to SIP UA . . . . . . . . . 16 80 10.3.2 Call from SIP UA to H.323 Terminal . . . . . . . . . 16 81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 82 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 13.1 Normative References . . . . . . . . . . . . . . . . . . . 20 85 13.2 Informative References . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 87 Intellectual Property and Copyright Statements . . . . . . . 22 89 1. Introduction 91 The SIP-H.323 Interworking function (IWF) converts between SIP 92 (Session Initiation Protocol) [RFC3261] and the ITU Recommendation 93 H.323 protocol [H.323]. This document describes requirements for 94 this protocol conversion. 96 2. Terminology 98 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 99 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 100 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 101 [RFC2119] and indicate requirement levels for compliant 102 implementations. 104 3. Definitions 106 H.323 gatekeeper (GK): An H.323 gatekeeper is an optional component 107 in an H.323 network. If it is present, it performs address 108 translation, bandwidth control, admission control and zone 109 management. 110 H.323 network: In this document, we refer to the collection of all 111 H.323-speaking components as the H.323 network. 112 SIP network: In this document, we refer to the collection of all SIP 113 servers and user agents as the SIP network. 114 Interworking Function (IWF): The Interworking Function (IWF) performs 115 interworking between H.323 and SIP. It belongs to both the H.323 116 and SIP networks. 117 SIP server: A SIP server can be either a SIP proxy, redirect server, 118 or registrar server. 119 Endpoint: An endpoint can call and be called. An endpoint is an 120 entity from which the media such as voice, video or fax originates 121 or terminates. An endpoint can be H.323 terminal, H.323 Gateway, 122 H.323 MCU [H.323] or SIP user agent (UA) [RFC3261]. 123 Media Switching Fabric (MSF): The Media Switching Fabric (MSF) is an 124 optional logical entity within the IWF. The MSF switches media 125 such as voice, video or fax from one network association to 126 another. 128 4. Functionality within the SIP-H.323 IWF 130 This section summarizes the functional requirements of the SIP-H.323 131 interworking function (IWF). 133 A SIP-H.323 IWF MAY be integrated into an H.323 gatekeeper or SIP 134 server. Interworking SHOULD NOT require any optional components in 135 either the SIP or H.323 network, such as H.323 gatekeepers. IWF 136 redundancy in the network is beyond the scope of this document. 138 An IWF contain functions from the following list, inter alia: 140 o Mapping of the call setup and teardown sequences; 141 o Registering H.323 and SIP endpoints with SIP registrars and H.323 142 gatekeepers; 143 o Resolving H.323 and SIP addresses; 144 o Maintaining the H.323 and SIP state machines; 145 o Negotiating terminal capabilities; 146 o Opening and closing media channels; 147 o Mapping media coding algorithms for H.323 and SIP networks; 148 o Reserving and releasing call-related resources; 149 o Processing of mid-call signaling messages; 150 o Handling of services and features. 152 The IWF SHOULD NOT process media. We assume that the same media 153 transport protocols, such as RTP, are used in both the SIP and H.323 154 network. Thus, media packets are exchanged directly between the 155 endpoints. If a particular service requires the IWF to handle media, 156 we assume that the IWF simply forwards media packets without 157 modification from one network to the other, using a media switching 158 fabric (MSF). The conversion of media from one encoding or format to 159 another is out of scope for SIP-H.323 protocol translation. 161 5. Pre-Call Requirements 163 The IWF function MAY use a translation table to resolve the H.323 and 164 SIP addresses to IP addresses. This translation table can be updated 165 by using a H.323 gatekeeper, SIP proxy server or a locally-maintained 166 database. 168 5.1 Registration with H.323 Gatekeeper 170 An IWF MAY provide and update the H.323 gatekeeper with the addresses 171 of SIP UAs. A SIP user agent can make itself known to the H.323 172 network by registering with an IWF serving as a registrar. The IWF 173 creates an H.323 alias address and registers this alias together with 174 its own network address with the appropriate GK. 176 The gatekeeper can then use this information to route calls to SIP 177 UAs via the IWF, without being aware that the endpoint is not a 178 "native" H.323 endpoint. 180 The IWF can register SIP UAs with one or more H.323 gatekeepers. 182 5.2 Registration with SIP Server 184 The IWF can provide information about H.323 endpoints to a SIP 185 registrar. This allows the SIP proxy using this SIP registrar to 186 direct calls to the H.323 end points via the IWF. 188 The IWF can easily obtain information about H.323 endpoints if it 189 also serves as a gatekeeper. Other architectures require further 190 study. 192 If the H.323 endpoints are known through E.164 (telephone number) 193 addresses, the IWF can use IGREP [I-D.ietf-iptel-tgrep] or SLP 194 [I-D.zhao-iptel-gwloc-slp] to inform the SIP proxy server of these 195 endpoints. 197 The IWF only needs to register with multiple SIP registrars if the 198 H.323 terminal is to appear under multiple, different 199 addresses-of-record. 201 6. General Interworking Requirements 203 The IWF SHOULD use H.323 Version 2 or later and SIP according to RFC 204 3261 [RFC3261]. The protocol translation function MUST NOT require 205 modifications or additions to either H.323 or SIP. However, it may 206 not be possible to support certain features of each protocol across 207 the IWF. 209 6.1 Basic Call Requirements 211 6.1.1 General Requirements 213 The IWF SHOULD provide default settings for translation parameters. 214 The IWF specification MUST identify these defaults. 216 The IWF MUST release any call-related resource at the end of a call. 217 SIP session timers [I-D.ietf-sip-session-timer] MAY be used on the 218 SIP side. 220 6.1.2 Address Resolution 222 The IWF SHOULD support all the addressing schemes in H.323, including 223 the H.323 URI [RFC3508], and the "sip", "sips" and "tel" URI schemes 224 in SIP. It SHOULD support the DNS-based SIP server location 225 mechanisms described in [RFC3263] and H.323 Annex O, which details 226 how H.323 uses DNS and, in particular, DNS SRV records. 228 The IWF SHOULD register with the H.323 Gatekeeper and the SIP 229 registrar when available. 231 The IWF MAY use any means to translate between SIP and H.323 232 addresses. Examples include translation tables populated by the 233 gatekeeper, SIP registrar or other database, LDAP, DNS or TRIP. 235 6.1.3 Call with H.323 Gatekeeper 237 When an H.323 GK is present in the network, the IWF SHOULD resolve 238 addresses with the help of the GK. 240 6.1.4 Call with SIP Registrar 242 The IWF applies normal SIP call routing and does not need to be aware 243 whether there is a proxy server or not. 245 6.1.5 Capability Negotiation 247 The IWF SHOULD NOT make any assumptions about the capabilities of 248 either the SIP user agent or the H.323 terminal. However, it MAY 249 indicate a guaranteed-to-be-supported list of codecs of the H.323 250 terminal or SIP user agent before exchanging capabilities with H.323 251 (using H.245) and SIP (using SDP [RFC2327]). H.323 defines mandatory 252 capabilities, SIP currently does not. For example, the G.711 audio 253 codec is mandatory for higher bandwidth H.323 networks. 255 The IWF SHOULD attempt to map the capability descriptors of H.323 and 256 SDP in the best possible fashion. The algorithm for finding the best 257 mapping between H.245 capability descriptors and the corresponding 258 SDP is left for further study. 260 The IWF SHOULD be able to map the common audio, video and application 261 format names supported in H.323 to and from the equivalent RTP/AVP 262 [RFC3550] names. 264 The IWF MAY use the SIP OPTIONS message to derive SIP UA 265 capabilities. It MAY support mid-call renegotiation of media 266 capabilities. 268 6.1.6 Opening of Logical Channels 270 The IWF SHOULD support the seamless exchange of messages for opening, 271 reopening, changing and closing of media channels during a call. The 272 procedures for opening, reopening, closing, and changing the existing 273 media sessions during a call are for further study. 275 The IWF SHOULD open media channels between the endpoints whenever 276 possible. If this is not possible, then the channel can be opened at 277 the MSF of the IWF. 279 The IWF SHOULD support unidirectional, symmetric bi-directional, and 280 asymmetric bi-directional opening of channels. 282 The IWF MAY respond to the mode request, to the request for reopening 283 and changing an existing logical channel and MAY support the flow 284 control mechanism in H.323. 286 6.2 IWF H.323 Features 288 The IWF SHOULD support Fast Connect, i.e., H.245 tunneling in H.323 289 Setup messages. If IWF and GK are the same device, pre-granted ARQ 290 SHOULD be supported. If pre-granted ARQ is supported, the IWF MAY 291 perform the address resolution from H.323 GK using the LRQ/LCF 292 exchange. 294 6.3 Overlapped Sending 296 An IWF SHOULD follow the recommendations outlined in 298 [I-D.ietf-sipping-overlap] when receiving overlapped digits from the 299 H.323 side. If the IWF receives overlapped dialed digits from the 300 SIP network, it MAY use the Q.931 Setup, Setup Ack and Information 301 Message in H.323. 303 The IWF MAY support the transfer of digits during a call by using the 304 appropriate SIP mechanism and UserInputIndication in H.245 (H.323). 306 6.3.1 DTMF Support 308 An IWF SHOULD support the mapping between DTMF and possibly other 309 telephony tones carried in signaling messages. 311 7. Transport 313 The H.323 and SIP systems do not have to be in close proximity. The 314 IP networks hosting the H.323 and SIP systems do not need to assure 315 quality-of-service (QOS). In particular, the IWF SHOULD NOT assume 316 that signaling messages have priority over packets from other 317 applications. H.323 signaling over UDP (H.323 Annex E) is optional. 319 8. Mapping between SIP and H.323 321 8.1 General Requirements 323 o The call message sequence of both protocols MUST be maintained. 324 o The IWF MUST NOT set up or tear down calls on its own. 325 o Signaling messages that do not have a match for the destination 326 protocol SHOULD be terminated on the IWF, with the IWF taking the 327 appropriate action for them. For example, SIP allows a SIP UA to 328 silently discard an ACK request for a non-existent call leg. 329 o If the IWF is required to generate a message on its own, IWF 330 SHOULD use pre-configured default values for the message 331 parameters. 332 o The information elements and header fields of the respective 333 messages are to be converted as follows: 334 * The contents of connection-specific information elements, such 335 as Call Reference Value for H.323, is converted to similar 336 information required by SIP or SDP such as the SDP session ID 337 and the SIP 'Call-ID'. 338 * The IWF generates protocol elements that are not available from 339 the other side. 341 8.2 H.225.0 and SIP Call Signaling 343 o The IWF MUST conform to the call signaling procedures recommended 344 for the SIP side regardless of the behavior of the H.323 elements. 345 o The IWF MUST conform to the call signaling procedures recommended 346 for the H.323 side regardless of the behavior of the SIP elements. 347 o The IWF serves as the endpoint for the Q.931 Call Signaling 348 Channel to either an H.323 endpoint or H.323 Gatekeeper (in case 349 of GK routed signaling). The IWF also acts as a SIP user agent 350 client and server. 351 o The IWF also establishes a RAS Channel to the H.323 GK, if 352 available. 353 o The IWF SHOULD process messages for H.323 supplementary services 354 (FACILITY, NOTIFY, and the INFORMATION messages) only if the 355 service itself is supported. 357 8.3 Call Sequence 359 The call sequence on both sides SHOULD be maintained in such a way 360 that neither H.323 terminal nor SIP UA is aware of presence of the 361 IWF. 363 8.4 State Machine Requirements 365 The state machine for IWF will follow the following general 366 guidelines: 368 o Unexpected messages in a particular state shall be treated as 369 "error" messages. 370 o All messages which do not change the state shall be treated as 371 "non-triggering" or informational messages. 372 o All messages which expect a change in state shall be treated as 373 "triggering" messages. 375 For each state, an IWF specification MUST classify all possible 376 protocol messages into the above three categories. It MUST specify 377 the actions taken on the content of the message and the resulting 378 state. Below, is an example of such a table: 380 State: Idle 382 Possible Messages Message Category Action Next state 383 ------------------------------------------------------------------- 384 All RAS msg. Triggering Add Reg.Info. WaitForSetup 385 All H.245 msg. Error Send 4xx Idle 386 SIP OPTIONS Non Triggering Return cap. Idle 387 SIP INVITE Triggering Send SETUP WaitForConnect 389 9. Security Considerations 391 Since the IWF whose requirements have been described in this document 392 combines both SIP and H.323 functionality, security considerations 393 for both of these protocols apply. 395 The eventual security solution for interworking MUST rely on the 396 standard mechanisms in RFC3261 [RFC3261] and H.323, without extending 397 them for the interworking function. Signaling security for H.323 is 398 described in H.235 [H.235]. 400 Since all data elements in SIP or H.323 have to terminate at the IWF, 401 the resulting security cannot be expected to be end-to-end. Thus, 402 the IWF terminates not only the signalling protocols but also the 403 security in each domain. Thus, users at the SIP or H.323 endpoint 404 have to trust the IWF, like any other gateway, to authenticate the 405 other side correctly. Similarly, they have to trust the gateway to 406 respect integrity of data elements and to apply appropriate security 407 mechanisms on the other side of the IWF. 409 The IWF MUST NOT indicate that a user on one side has achieved a 410 certain level of trust without the ability to verify that. For 411 example, if the SIP user was not authenticated, it would be 412 inappropriate to use mechanisms on the H.323 side, such as H.323 413 Annex D, that indicated that the user identity had been 414 authenticated. 416 An IWF MUST NOT accept 'sips' requests unless it can guarantee that 417 the H.323 side use equivalent H.235 [H.235] security mechanisms. 418 Similarly, the IWF MUST NOT accept H.235 sessions unless it succeeds 419 in using SIP-over-TLS (sips) on the SIP side of the IWF. 421 10. Examples and Scenarios 423 10.1 Introduction 425 We present some examples of call scenarios that will show the 426 signaling messages received and transmitted. The following 427 situations can occur: 429 o Some signaling messages can be translated one-to-one. 430 o In some cases, parameters on one side do not match those on the 431 other side. 432 o Some signaling messages do not have an equivalent message on the 433 other side. In some cases, the IWF can gather further information 434 and the signal on the other side. In some cases, only an error 435 indication can be provided. 437 10.2 IWF Configurations 439 Below are some common architectures involving an IWF: 441 Basic Configuration: H.323 EP -- IWF -- SIP UA 442 Calls using H.323 GK: H.323 EP -- H.323 GK -- IWF -- SIP UA 443 Calls using SIP proxies: H.323 EP -- IWF -- SIP proxies -- SIP UA 444 Calls using both H.323 GK and SIP proxy: H.323 EP -- H.323 GK -- IWF 445 -- SIP proxies -- SIP UA 446 SIP trunking between H.323 networks: H.323 EP -- IWF -- SIP network 447 -- IWF -- H.323 EP 448 H.323 trunking between SIP networks: SIP EP -- IWF -- H.323 network 449 -- IWF -- SIP UA 451 10.3 Call Flows 453 Some call flow examples for two different configurations and call 454 scenarios are given below. 456 10.3.1 Call from H.323 Terminal to SIP UA 458 H.323 SIP 459 EP Setup IWF UA 460 |------------>| INVITE | 461 | |------------>| 462 | | 180 RINGING | 463 | Alerting |<------------| 464 |<------------| 200 OK | 465 | Connect |<------------| 466 |<------------| | 467 | H.245 | | 468 |<----------->| ACK | 469 | |------------>| 470 | RTP | 471 |<.........................>| 473 10.3.2 Call from SIP UA to H.323 Terminal 475 SIP H.323 476 UA IWF EP 477 | | | 478 | INVITE | | 479 |------------>| Setup | 480 | |------------>| 481 | | Alerting | 482 | 180 RINGING |<------------| 483 |<------------| Connect | 484 | |<------------| 485 | | H.245 | 486 | 200 OK |<----------->| 487 |<------------| | 488 | ACK | | 489 |------------>| | 490 | RTP | 491 |<.........................>| 493 11. Acknowledgments 495 The authors would like to acknowledge the many contributors who 496 discussed the SIP-H.323 interworking architecture and requirements on 497 the IETF, SIP and SG16 mailing lists. In particular, we would like 498 to thank Joon Maeng, Dave Walker and Jean-Francois Mule. 499 Contributions to this document have also been made by members of the 500 H.323, aHIT!, TIPHON and SG16 forums. 502 12. Contributors 504 In addition to the editors, the following people provided substantial 505 technical and writing contributions to this document, listed 506 alphabetically: 508 Hemant Agrawal 509 Telverse Communications 510 1010 Stewart Drive 511 Sunnyale, CA 94085 512 USA 513 hagrawal@telverse.com 515 Alan Johnston 516 MCI WorldCom 517 100 South Fourth Street 518 St. Louis, MO 63102 519 USA 520 alan.johnston@wcom.com 522 Vipin Palawat 523 Cisco Systems Inc. 524 900 Chelmsford Street 525 Lowell, MA 01851 526 USA 527 vpalawat@cisco.com 529 Radhika R. Roy 530 AT&T 531 Room C1-2B03 532 200 Laurel Avenue S. 533 Middletown, NJ 07748 534 USA 535 rrroy@att.com 537 Kundan Singh 538 Dept. of Computer Science 539 Columbia University 540 1214 Amsterdam Avenue, MC 0401 541 New York, NY 10027 542 USA 543 kns10@cs.columbia.edu 544 David Wang 545 Nuera Communications Inc. 546 10445 Pacific Center Court 547 San Diego, CA 92121 548 USA 549 dwang@nuera.com 551 13. References 553 13.1 Normative References 555 [H.235] International Telecommunication Union, "Security and 556 encryption for H-Series (H.323 and other H.245-based) 557 multimedia terminals", Recommendation H.235, February 558 1998. 560 [H.323] International Telecommunication Union, "Packet based 561 multimedia communication systems", Recommendation H.323, 562 July 2003. 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 568 Protocol", RFC 2327, April 1998. 570 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 571 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 572 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 574 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 575 Protocol (SIP): Locating SIP Servers", RFC 3263, June 576 2002. 578 [RFC3508] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme 579 Registration", RFC 3508, April 2003. 581 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 582 Jacobson, "RTP: A Transport Protocol for Real-Time 583 Applications", STD 64, RFC 3550, July 2003. 585 13.2 Informative References 587 [I-D.ietf-iptel-tgrep] 588 Bangalore, M., "A Telephony Gateway REgistration Protocol 589 (TGREP)", draft-ietf-iptel-tgrep-03 (work in progress), 590 March 2004. 592 [I-D.ietf-sip-session-timer] 593 Donovan, S. and J. Rosenberg, "Session Timers in the 594 Session Initiation Protocol (SIP)", 595 draft-ietf-sip-session-timer-15 (work in progress), August 596 2004. 598 [I-D.ietf-sipping-overlap] 599 Camarillo, G., "Mapping of ISUP Overlap Signalling to the 600 Session Initiation Protocol", 601 draft-ietf-sipping-overlap-03 (work in progress), August 602 2002. 604 [I-D.levin-iptel-h323-url-scheme] 605 Levin, O., "H.323 URL scheme definition", 606 draft-levin-iptel-h323-url-scheme-04 (work in progress), 607 November 2001. 609 [I-D.zhao-iptel-gwloc-slp] 610 Zhao, W. and H. Schulzrinne, "Locating IP-to-Public 611 Switched Telephone Network (PSTN) Telephony Gateways via 612 SLP", draft-zhao-iptel-gwloc-slp-06 (work in progress), 613 February 2004. 615 Authors' Addresses 617 Henning Schulzrinne 618 Columbia University 619 Department of Computer Science 620 450 Computer Science Building 621 New York, NY 10027 622 US 624 Phone: +1 212 939 7042 625 EMail: hgs@cs.columbia.edu 626 URI: http://www.cs.columbia.edu 628 Charles Agboh 629 Viables Industrial Estate 630 Basingstoke, UK RG22 4PD 631 UK 633 EMail: cagboh1@motorola.com 635 Intellectual Property Statement 637 The IETF takes no position regarding the validity or scope of any 638 Intellectual Property Rights or other rights that might be claimed to 639 pertain to the implementation or use of the technology described in 640 this document or the extent to which any license under such rights 641 might or might not be available; nor does it represent that it has 642 made any independent effort to identify any such rights. Information 643 on the procedures with respect to rights in RFC documents can be 644 found in BCP 78 and BCP 79. 646 Copies of IPR disclosures made to the IETF Secretariat and any 647 assurances of licenses to be made available, or the result of an 648 attempt made to obtain a general license or permission for the use of 649 such proprietary rights by implementers or users of this 650 specification can be obtained from the IETF on-line IPR repository at 651 http://www.ietf.org/ipr. 653 The IETF invites any interested party to bring to its attention any 654 copyrights, patents or patent applications, or other proprietary 655 rights that may cover technology that may be required to implement 656 this standard. Please address the information to the IETF at 657 ietf-ipr@ietf.org. 659 Disclaimer of Validity 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 664 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 665 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 666 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Copyright Statement 671 Copyright (C) The Internet Society (2004). This document is subject 672 to the rights, licenses and restrictions contained in BCP 78, and 673 except as set forth therein, the authors retain all their rights. 675 Acknowledgment 677 Funding for the RFC Editor function is currently provided by the 678 Internet Society.