idnits 2.17.1 draft-petrack-sisp-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-23) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) -- No information found for draft-mmusic-ietf-agree - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-casner-jacobson-crtp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MMusic WG 2 INTERNET-DRAFT Scott Petrack, IBM 3 draft-petrack-sisp-00.txt 4 13 June 1996 Expires: December 1996 6 SISP - Simple Internet Signalling Protocol 8 Status of this Memo 10 This document is a first draft of an Internet-Draft. Internet-Drafts 11 are working documents of the Internet Engineering Task Force (IETF), 12 its areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 This document is truly rough, but it was felt that the timeliness 16 of the ideas justified dissemination in this preliminary form. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or made obsolete by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. 31 Abstract 33 Simple Internet Signalling Protocol (SISP) performs one function: 34 signalling of realtime data streams over IP networks. SISP has 35 several distinguishing features: it is a tiny extension of RTCP, 36 running over UDP or TCP, it can integrate very well with PSTN 37 signalling, and it can run in very low bandwidth situations without 38 disturbing the real time stream. It is completely scalable with 39 respect to number of participants and also with respect to "tightness" 40 of control, and can work with an extremely 41 wide variety of conference models, policies, and standards. 43 SISP differs from other conferencing protocols in that it performs 44 a single essential task completely. It is argued that other protocols 45 solve only parts of several overlapping problems. SISP can serve as the 46 lowest common denominator for signalling of real-time streams. 48 The requirements that SISP fulfills, the features it offers, 49 the fact that it uses RTCP as an encapsulation scheme, and its 50 generally minimalist approach of solving one problem only are 51 more important than the actual state machine it implements or 52 particular format of its messages. 54 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 55 1. Introduction 57 This paper discusses a solution to a one particular aspect of 58 the very large "session/conference control problem": the 59 problem of signalling. It is also an attempt to help resolve a 60 crisis. 62 There are at present two separate groups of applications which 63 perform conferencing over the Internet. One is the suite of MBONE 64 tools. These tools have little or no conference control built in. 65 Separate protocols and tools are used to supply control if it 66 is desired. This is quite a reasonable approach: after all, 67 streaming is streaming and control is control. There is a long 68 list of protocols emerging at present (SIP, SAP, SDP, SCIP, SCCP) 69 which solve an equally long list of problems (location, 70 announcement, setup, session description, scheduling, negotiation 71 of capabilities). The problem is that these protocols have a 72 large overlap, and in many cases they solve overlapping and 73 ill-defined problems. 75 The second group is the plethora of commercial Internet 76 telephones, videophones, and other real time communication 77 applications. These applications often have control built in 78 directly into the real time stream. Of course, these applications 79 are really very immature, and certainly have not done their 80 IETF homework in almost any subject: none use multicast, few 81 use RTP, and none are interoperable in any way, neither for 82 control nor for streaming. Many people consider this a crisis, 83 although oddly enough there are wildly differing views on what 84 the crisis is. 86 Now of course it is very distasteful to have to deal with this 87 second group of applications at all. One has the impression 88 that there are no "real problems" here, certainly none 89 worthy of real research time or thought. It seems clear that 90 if one does some serious work on the first group of applications, 91 then the commercial applications will fall into line as they 92 realize the advantages of standardization. 94 This note argues otherwise: it begins with 95 the question: "what is the absolute minimum infrastructure 96 that must be in place to allow different multimedia conferencing 97 applications to become interoperable?" I claim that there 98 is a very tiny thing which stands out: signalling of realtime 99 streams. This is the mechanism by which 100 one sets up, maintains, and tears down a realtime stream. 102 All of conference control has as object to allow human users to 103 pass real time streams amongst themselves (although of course 104 there will be cases where some or all users are not human). 105 Signalling is what happens at the very last stage, when all 106 decisions about location, announcement, policy, scheduling, 107 have taken place, and you want to setup the real time stream NOW. 108 It also happens when the real time stream is already streaming, 109 and you need to change some shared ephermal state of it NOW. 111 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 113 SISP has no mechanism to perform location queries, or scheduling 114 of future conferences. In fact, it doesn't really 115 know at all about conferences. It knows about a single RTP 116 stream. SISP simply adds some new RTCP SDES items and a packet type 117 to add some control to a single RTP stream. That's all. If you 118 are satsified with the loose control that RTCP gives over 119 a real time stream, then you do not need to use the new packet 120 type. These allow one to scale the currently available loose control 121 across to a very tightly controlled model. It reuses a number 122 of mechanisms that already exist within RTCP, such as SDES 123 and CNAME. In fact, it is better to say that SISP simply uses these 124 mechanisms, not reuses them. 126 One very important feature of RTP is that each real time stream 127 is a separate entity with its own control; in the same way, 128 SISP treats each real time stream as a separate entity. 129 For example, this allows you to transfer the audio stream in an 130 AudioVideo Call, without transferring the Video stream. These sorts 131 of services are very important. Rather than reinventing them, we get 132 them from RTCP. In general, all issues relating to "shared ephermal 133 state" are implemented on a per-stream basis. 135 Of course, it is very desireable to have standard tools and 136 protocols for location, etc., and of course there is overlap 137 between the need to "announce" and "describe" and "invite." 138 Unfortunately, these problems have not been well enough 139 defined and separated yet, and this is the reason that there 140 are many overlapping protocols which are solving many overlapping 141 problems. We avoid this morass by simply not addressing it in any way. 142 We solve the smaller and perfectly well defined problem of 143 signalling. We certainly hope that solving this will help clarify 144 the other higher level issues. 146 This paper is written from a double perspective. 148 On the one hand, it is indeed a "letter from the front." 149 The author is writing to the generals and strategists back home, 150 describing a particular crisis. He has already done something 151 about it, and he thinks that it is important the generals know. 152 He is a bit upset that the guidelines he has from headquarters 153 are a bit confusing and frankly confused. 155 From another point of view, the author believes that the knot of 156 overlapping requirements and protocols is making for bad strategy. 157 He has an alternative solution, and he thinks that at least some 158 of its features are truly superior to what now exists. He hopes 159 that the following will contribute to untangling the problem. 161 The author's goal is thus a contribution both to the "problem" 162 of overlapping protocols and also to the "crisis" of 163 non-interoperable Internet Telephones and VideoPhones. 165 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 167 With all this out of the way, the rest of the paper can be 168 more straightforward. We will describe the the motivation 169 for SISP, the motivation for using RTCP as transport, 170 basic features of SISP, and a few signal flows. 172 For many reasons (including the 173 "shared ephemeral state" of people submitting internet drafts in 174 June 1996 ), a great amount of important detail is missing 175 from this paper. Apart from simply regretting this, the author 176 wishes to state that the two main ideas of this paper, to use 177 RTCP and to separate out signalling from all other multimedia 178 conferencing problems, can be explained without reference to the 179 bit patterns of the new RTCP packets proposed. 181 In a final section, I compare and contrast broadly SISP with 182 various features of SIP, SAP, SDP, SCIP, SCCP. It is important 183 to understand the claim that non-SISP protocols try to do too much 184 on the one hand, and on the other are not quite rich enough. 185 At first we thought to call the new protocol "YACC" - 186 "yet another conference control." We have convinced ourselves 187 that this would not be accurate: SISP separates out one 188 particular, specific, essential problem, and solves it. 190 2. RTCP - a model of what is needed 192 The basic features of SISP stem directly from the decision to use 193 RTCP as a basis. So it makes sense to begin with a discussion of 194 the principles that impelled us to such a decision: 196 As explained above, our motivation was to perform signalling, 197 in the dictionary sense of "an act, event, or watchword that 198 has been agreed upon as the occasion of concerted action." 199 That is, signalling are those messages involved in call setup, 200 tear down, and maintenance which causes an action to happen 201 NOW. In particular, the thing of interest which is acted upon 202 is a real time media stream, which in our world is an RTP [1] stream. 203 So we wish to send messages to control real time streams in real 204 time. 206 Now of course it might be interesting to discuss if we 207 really want to control real time streams, or some higher level 208 thing like a "session" or a "conference." But it should be clear 209 that whatever higher level constructs one makes, at some point this 210 turns into control of some real time stream. When a user joins 211 or leaves a conference, for example, then a real time stream is 212 starts or stops flowing over a portion of the Internet, whatever 213 particular meaning you like to assign to the words "user", "join", 214 "leave," or "conference". Since we have to control these RTP 215 streams, it is natural to see what they are made of, and what 216 already exists to signal them. 218 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 220 Looking at the definition of RTP, one discovers that it contains 221 RTCP, a "control protocol," by definition. In fact, the manual 222 states explicitly that "RTCP may be 223 sufficient for `loosely controlled' sessions" [1,p.2]. Hmmm. 224 It is certainly natural to try to make precise just 225 which signalling and control functions are already in RTCP, 226 before going on to invent something new. In any case, 227 we would certainly like to have a signalling mechanism which 228 can scale from very enabling very loose to very tight control. 229 If RTCP covers one end of the spectrum, it is interesting to 230 see how far it can be pushed, at what point it breaks, and if 231 a continuum can be built with it as one end. 233 One discovers that RTCP is pretty rich already. For example, "by 234 having each participant send its control packets to all the others, 235 each can independently observe the number of participants." [1,p.15] 236 This is certainly some sort of session awareness, of "shared 237 ephemeral state" in the sense of [2]. 239 There is also a great deal of information sent about the sender in 240 the RTCP SDES packet. Although it is not clear at first why one 241 needs to know the email of the person to whom you are talking 242 (I don't know the email address of many of the people I talk to 243 over the telephone), the fact is that *all* the current suggestions 244 within MMUSIC seem to think that this is very important. 245 Luckily for us, then, every RTP stream 246 is already required to have this information transmitted within 247 and SDES packet. So applications already have code to transmit this 248 information. It seems a shame to code it again. 250 In fact, RTCP already solves some other difficult problems in multimedia 251 signalling. Consider the problem of how to define a "session" or 252 "conference." In RTCP, one has the notion of a "Canonical Name" 253 (CNAME). This is used in the RTCP packets so that different RTP streams 254 can be associated. For example, this is how one can know that a 255 particular RTP video stream and a different RTP audio stream are in 256 fact meant to be a synchronized VideoPhone call. 258 What more natural thing to do than to use an RTCP stream to convey all 259 this information which is vital to call signalling? For example, in 260 a very tightly controlled conference (like an ordinary phone call), 261 one might start by sending an RTCP stream with a CNAME and SDES and 262 other necessary information, and when the necessary shared stated 263 has been obtained, the RTP stream itself can begin. If there are several 264 RTP streams that make up a session, one could actually keep one RTCP 265 stream exclusively for signalling, or just add new RTCP and RTP streams 266 as needed. 268 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 270 In fact, just by using RTP one can get a range of loose to tight 271 control models. 272 As one example among many others, if one wishes to have a 273 multicast session, where some parameters can not be announced 274 in advance, then one can send out the required parameters in 275 an SDES packet, and any RTCP monitor looking at the traffic can 276 join the conference. If one wants tighter control, then security 277 and encryption are both a part of RTCP already. 279 Before we come to the bad news, let us continue and see how RTCP 280 solves some problems of signalling simply and naturally. 282 The BYE packet of RTCP is actually a true 283 signal, in that it does indeed constitute a "watchword which has 284 been agreed upon as the occasion of concerted action." (Well, of 285 course in an extremely loosely controlled conference, of course, this 286 may not be true, but in such a case the BYE is not very important). 288 Here is a more sophisticated reason to use RTCP as a 289 signalling mechanism: signalling often involves precise timing 290 considerations. The need for precise timestamps to deal with 291 some aspects of "shared ephemeral state" is carefully discussed in [2]. 292 Indeed, in the public telephone network (PSTN), passing these strict 293 timing requirements is one aspect of the process of homologation. 294 RTCP packets come with timestamps as well. 296 Another advantage of RTCP is that it allows for separate 297 signalling for each real time stream. For example, 298 if I wish to transfer a VideoPhone conversation to someone 299 who is connected only by telephone, I might wish to transfer 300 the audio stream of the call, but not the video stream. 301 It would be unfortunate if the transfer had to fail, just 302 because the third party had no video support. 303 Just as one doesn't want to *force* someone to associate or 304 interleave two separate streams, logically or physically, one 305 shouldn't try to force association of signalling either. 306 Problems that arise because of bandwidth considerations are 307 best dealt with by RTCP compression [3,4], not by forcing 308 users to have reduced functionality. 310 Finally, for those applications which run on very low bandwidth links, 311 using RTCP has two advantages, one of which is perhaps a bit subtle: 313 First, we have seen that many things one needs to send for signalling 314 are required in any case by RTCP. So apart from saving tired fingers 315 the trouble of writing new code, using RTCP can also save bandwidth. 317 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 319 Second, on a very low bandwidth link, merely sending a signal can 320 overload the bandwidth, when an application is sending true RTP. 321 Now there is a small amount of tolerance for when one can send an RTCP 322 packet. In particular, a clever application can arrange to send the RTCP 323 packet during a "silence" period, which for the present purpose just 324 means a period when the RTP stream is not itself transmitting. This is 325 sometimes difficult, but a good application will know how to exploit 326 this. Of course, one can perform similar juggling with the signals, 327 but if one is transmitting signals for an RTP stream along with the 328 RTCP stream, it is obviously easier to coordinate things. 330 I hope that the reader is convinced that RTCP is already well 331 on the way to enable signalling for real time streams that is 332 robust, flexible on the scale of loose/tight control, and 333 very effecient in bandwidth and implementation. 335 3. Extensions to RTCP 337 Unfortunately, there are indeed some needed messages that 338 are missing from RTCP. Not surprisingly, these are needed 339 precisely to fill out the "tightly controlled" end of the 340 scale. What is amazing is that so little is needed. 342 I am sorry to be very informal here, and beg the extreme 343 indulgence of the reader. A committment is made to provide 344 details at a later date. 346 3.1 RDES - receiver description packet type 348 In a tightly coupled conference you clearly need to identify 349 the person you wish to speak to. Now exactly what "identify" 350 means is of course an interesting subject. We can say what 351 we mean quite precisely: It is assumed that the remote 352 machine receiving the RTCP packets has some means of identifying 353 the person you wish to contact. It is the duty of a decent 354 "location service" to provide both the address (IP, port) of the 355 machine to recieve the real time stream, and hence the RTCP 356 signalling, as well as the tag/value information needed to 357 identify the actual remote party. How this location service 358 works is beyond the scope of the signalling-for-RTP-streams 359 considered here. In any case, the RDES message should have 360 exactly the description needed to identify the remote party. 362 Of course, there is no *requirement* that one use the RDES 363 field to tightly control a conference. One could imagine a 364 private multicast to thousands of members of a cult, where 365 the standard methods of RTCP security could be used to control 366 conference membership very tightly. But it is equally obvious 367 that one mechanism for tight control is that an RDES message 368 should be sent at the very beginning of a call to identify the 369 called party. 371 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 373 It should come as no surprise that the suggested format for 374 an RDES message is identical to that of an SDES message. 375 We shall give an example of the use of the RDES message in 376 the appendix. 378 3.2 RCAP item - receiver capabilities, new item in SDES 380 Until now, I have not yet given a single hint of any signal flow. 381 I have given no model of any kind for control. The next item 382 type seems indeed related to the particular model for signal 383 flows. But in fact it does not really forbid any particular 384 model. The "receiver capabilities" items list the RTP payload 385 types that the particular Receiver is willing to accept. 386 Note once again that I make no assumption whatsoever about 387 how this list is obtained. It may be a list of the coders that 388 the receiver's machine can actually decode, or it may be a 389 subset of that list based on such things as available machine 390 resources, hierarchy within an organization, or the phase of the 391 moon. As far as the needs of signalling go, a potential receiver 392 must be able to send out a list of those RTP payload types 393 that it is willing to receive right now. This list can contain 394 any of the accepted standard RTP payload types, or 395 elements of some other list of payload types agreed upon 396 by non-RTP means. 398 An example of setting up a simple call will be given in the 399 appendix, but it may help to state here that the basic mode 400 of call setup is inspired by the H.245 capabilities exchange 401 of ITU-T standard H.323. Namely, the reciever merely lists 402 the payload types that it is willing to accept, and then 403 the transmitter chooses one of those types for transmission. 405 Note that we can agree that the order of payload types within 406 a list describes the order of preference which the receiver has. 407 Note also that we need no special new item in SDES to describe 408 what is actually being sent. This is done in the payload type 409 of RTP. 411 It might be rather confusing that the RCAP item type is found in 412 the SDES packet, and not in the RDES packet. This is pure logic: 413 an RDES packet is sent in order to identify the *remote* 414 party. But one sends a SDES packet to describe "oneself," and 415 part of this description is what one is willing to tolerate 416 receiving. 418 3.3 CP item - call progress, new item in SDES 420 The final item that we need to add is one that allows call 421 progress to occur. Call Progress is the feedback that one 422 obtains during the life of a call from the network system. 423 For example, you hear a particular sound after you dial 424 a remote user, and you know that his or her equipment is ringing. 425 The call progress words currently supported by SISP are 426 the following: Ringing, Accept, Busy, NoAnswer, Reject, 427 Pause, Error, Release, Info. 429 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 431 When the remote party's application is "ringing," it sends an SDES 432 packet with the CP item set to "ringing." The local application 433 receives this and can send the appropriate message ("Drrrrrrrring!") 434 to the local user. 436 These are new items for an SDES packet because we think of the 437 user who is "ringing", or "accepts" a call as describing 438 "himself" in an SDES packet. Unfortunately, this means 439 that even if I am a receiver only, I might send an SDES packet, 440 for example to say that my app is "ringing." 441 This has caused some confusion, even with the author. It is 442 really the "receiver" who is ringing, or busy, or pausing. 443 But it seems to be RTCP convention that an SDES packet is describing 444 "himself". Originally, these call progress items were part of 445 the receiver report. There was no release item, and the BYE 446 packet was used instead. (All this point needs to be clarified). 448 Although the general meaning of each word is clear, there 449 are a few comments to make about some of the CP items: 451 Accept: The application sends an "accept" CP item when it is 452 ready for the other side to start streaming its RTP data. Of 453 course, there are many conference models where this makes no 454 sense. For example, in a loosely defined model, I certainly 455 don't want to wait for an accept message to begin streaming. 457 This is entirely correct. SISP does not *require* that an 458 application send an "accept" message before the remote 459 party begins to stream. Whether or not this is necessary 460 is decided by means totally outside of SISP, and is definitely 461 a part of the conference model being used. This will be 462 decided by a session "announcement" or "description", or 463 some other means. SISP is merely a signaling protocol. SISP 464 claims that RTCP, supplemented with the very few additions 465 here, is rich enough for all Internet Signalling means. 467 One can make a similar comment about every item of type 468 CP (Call Progress). Indeed, we have seen that in the loosest 469 conference model, RTCP suffices (the RTP standard says it does, 470 so this statement is by IETF consensus true). But if one 471 wants to distinguish, for example, between a call that is 472 rejected because there was no answer or because the user 473 made an active choice to reject the call, one can use SISP 474 to do this. 476 We shall see another example of the fact that SISP does not 477 mandate conference policy, but merely allows one to express 478 it, in the appendix. 480 Pause: This SDES item just says that the receiver is stopping 481 recieving "for a while". It is an indication that the receiver has 482 "put you on hold." Note that I did not put a "Resume" item type. 483 When I put you on hold, you really have no way of knowing this in 484 an ordinary call. But one might wish to add the signal. 486 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 488 Release: On the face of it, this is a totally superfluous 489 item, because there is a BYE packet. It was added so that 490 a receiver can also request or announce that s/he will 491 disconnect. It was also added to allow for some more 492 complicated supplementary services. The idea is that 493 many supplementary services end with a simultaneous 494 release, and an instruction for one party to do something 495 else. For example, in a blind call transfer, where 496 A has called B, and after some time, A would like B to 497 speak to C instead, but doesn't need to inform C about it 498 first (this is the "blind" part of the transfer), then 499 A would send an SDES with a release CP item to B, along 500 with an INFO CP item which said "call C." 502 This last example is one of many many supplementary 503 services. The author has checked that the very 504 simple list here is enough to implement the gamut of supplementary 505 services. Signal flows will be given in the next version 506 of this document. 508 The conclusion of this is that by adding only 3 things to 509 RTCP - one packet type and two new SDES items, it is possible 510 to use RTCP to implement the full range of Signalling needed 511 for Internet Conferencing Applications. 513 4. Complaints, complaints. 515 With such a scant description of SISP, it would be highly 516 inappropriate to critisize other attempts to provide for 517 internet signalling in detail. We shall try to 518 list general objections to previous solutions. 520 First, signalling should be totally separate from the location 521 service. Of course, a location server may indeed use SISP if that 522 is appropriate. But that would be signalling for the location 523 server call, not for the actual call one wishes to make. 524 SISP begins its function after the location of the remote 525 party has already been decided. 527 Second, the signalling protocol should be allow for any 528 conference model. For example, a protocol which *forces* 529 an application to distinguish "reject" and "no answer" is 530 flawed: the user may not wish to convey the information that 531 s/he rejected an invitation to confer. Certainly there 532 cannot be a requirement for any centralized statekeeper if 533 one wishes to include loosely controlled multicast 534 conferences. 536 Third, there must be the possibilty of dynamic negotiation 537 of capabilities in real-time, via signalling at the 538 time of connection. This is because one may need to reserve 539 machine resources, and one can only do this "at the last 540 minute." 541 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 543 Fourth, it is important to allow for independent signalling 544 on independent RTP streams. This in itself is a strong 545 motivation for starting with RTCP. 547 Fifth, it is important to be truly scalable, in terms of 548 available bandwidth, number of users in the session, and 549 along the tight-loose control access. This is not 550 an easy problem, and much work has gone into RTCP to this end. 552 Sixth, it is important that the signalling allow for timestamps 553 on signals. 555 Seventh, it is important in some applications that the signalling 556 itself be secure. At the other extreme, for some loosely 557 controlled conferences, it is useful to have "signal monitors" 558 that can "pick up" enough of the required information to 559 join the conference. 561 Eighth, by definition RTCP is everywhere where RTP is. It is 562 far from clear that SMTP, HTTP, etc. will be there. (Imagine 563 very small cheap special purpose communication devices). 565 Ninth, the "global id" problem is quite complicated, and 566 tying down multimedia conferencing to any particular solution 567 of this problem is difficult. In any case, the part of the 568 problem that is location should be treated by a location 569 server, and the part of the global id problem that relates 570 to shared ephemeral state is best treated by the simple 571 CNAME mechanism of RTP. The part of the problem relating 572 to things like dynamic IP or "Integration into Email," for 573 example, is not really a problem that is related to signalling. 575 5. Reliability of SISP messages 577 The reader may have the impression that the author has somehow 578 forgotten that RTCP is not reliable. Indeed, in trials 579 he has simply used TCP for the RTCP flow. Since the RTCP 580 traffic is really very slight, this has not caused problems, 581 even on slow serial links. (In fact, because of TCP/IP 582 compression, TCP is usually a more effecient choice over 583 a dial up link!). Of course in situations where it is 584 not possible to use TCP, some other means must be used 585 to ensure the reliability of the SISP signalling. 587 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 589 6. Signal Flows 591 (These must be written up, but I shall give at least one!) 593 6.1. Of course, the simple open multicast conference is an 594 example of SISP signalling, as is any other conference which 595 relies on some non-RTP means to determine location, and then 596 only RTCP for conference control. But we shall give an 597 example of a simple Internet Telephone Call, using SISP. 598 In the following example A wishes to call B. 599 The precise timings are not given for simplicity, but 600 the packets sent are written in time order. 602 a. A sends B the following RTCP packets, in this order: 603 (RTP is not yet being sent) 605 SDES: identifies the caller. (This is optional) 607 RDES: identifies the callee. The information used in this 608 packet is obtained from some location server or other 609 means. 611 RCAP: identifies the recpetion capabilities of A 612 (remember that if there is more than one RTP stream, 613 then there will be more than one SISP stream as well). 615 b. B receives the three packets, and perhaps it consults with the OS 616 and with some databases. It starts a ringing signal to the user, 617 and sends the following packet to A: 619 SDES: identifies B, and sends the "ringing" CP item 621 c. Perhaps after some consultation 622 with the user, with some databases, and with the operating system, 623 B sends the following RTCP packets, in this order: 625 SDES: identifies B and sends the "accept" CP item 627 d. Upon getting the "accept" message, A knows that it can start 628 streaming. It sends the following packet to B: 630 SDES: identifies A and sends the "accept" CP item 632 And now B knows that it can start streaming as well. 634 draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 636 Acknowledgements: 638 The author wishes to thank Ed Ellesson of IBM for helpful ideas 639 and advice, encouragement, and tolerance. 641 References 643 [1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP: 644 A Transport Protocol for real-time applications." RFC 1889 646 [2] S. Shenker, A. Weinrib, E. Schooler, "Managing Shared Ephemeral 647 Teleconferencing State: Policy and Mechanism." draft-mmusic- 648 ietf-agree-00.ps 650 [3] S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for 651 Low-Speed Serial Links." draft-casner-jacobson-crtp-00.txt 653 [4] S. Petrack, "Compression of Headers in RTP Streams", 654 draft-petrack-crtp-00.txt 656 Author's Location Information 658 Name=Scott Petrack 659 Address=IBM Haifa Research Lab, Haifa 31905, Israel 660 Email=petrack@vnet.ibm.com 661 Telephone=+972 4 829 6290 662 Fax=+972 4 829 6112