1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Network Working Group O. Levin
Request for Comments: 4245 Microsoft Corporation
Category: Informational R. Even
Polycom
November 2005
<span class="h1">High-Level Requirements for Tightly Coupled SIP Conferencing</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document examines a wide range of conferencing requirements for
tightly coupled SIP conferences. Separate documents will map the
requirements to existing protocol primitives, define new protocol
extensions, and introduce new protocols as needed. Together, these
documents will provide a guide for building interoperable SIP
conferencing applications.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. An Overview .....................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. High-Level Requirements .........................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Discovery Phase ............................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Conference Creation ........................................<a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. Conference Termination .....................................<a href="#page-4">4</a>
<a href="#section-3.4">3.4</a>. Participants' Manipulations ................................<a href="#page-4">4</a>
<a href="#section-3.4.1">3.4.1</a>. Participation of a Conference-Unaware User Agent ......<a href="#page-5">5</a>
<a href="#section-3.4.2">3.4.2</a>. Dial-Out Scenarios ....................................<a href="#page-5">5</a>
<a href="#section-3.4.3">3.4.3</a>. Dial-In Scenarios .....................................<a href="#page-5">5</a>
<a href="#section-3.4.4">3.4.4</a>. Third-Party Invitation to a Conference ................<a href="#page-6">6</a>
<a href="#section-3.4.5">3.4.5</a>. Participants' Removal .................................<a href="#page-6">6</a>
<a href="#section-3.4.6">3.4.6</a>. Participants' Privacy .................................<a href="#page-6">6</a>
<a href="#section-3.5">3.5</a>. Conference State Information ...............................<a href="#page-7">7</a>
<a href="#section-3.5.1">3.5.1</a>. Description ...........................................<a href="#page-7">7</a>
<a href="#section-3.5.2">3.5.2</a>. Dissemination of Changes ..............................<a href="#page-7">7</a>
<a href="#section-3.5.3">3.5.3</a>. On-demand Information Dissemination ...................<a href="#page-8">8</a>
<a href="#section-3.6">3.6</a>. Focus Role Migration .......................................<a href="#page-8">8</a>
<span class="grey">Levin & Even Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
<a href="#section-3.7">3.7</a>. Side-bar Conferences .......................................<a href="#page-8">8</a>
<a href="#section-3.8">3.8</a>. Cascading of Conferences ...................................<a href="#page-9">9</a>
<a href="#section-3.9">3.9</a>. SIMPLE and SIP Conferencing Coordination ...................<a href="#page-9">9</a>
<a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Contributors ...................................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. References .....................................................<a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. Normative References ......................................<a href="#page-10">10</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document examines a wide range of conferencing requirements for
tightly coupled SIP (<a href="./rfc3261">RFC 3261</a> [<a href="#ref-2" title=""SIP: Session Initiation Protocol"">2</a>]) conferencing.
The requirements are grouped by subjects in various areas allowing
solutions to progress in parallel.
Separate documents will map the requirements to existing protocol
primitives, define new protocol extensions, and introduce new
protocols as needed.
Together, these documents will provide a guide for building
interoperable SIP conferencing applications.
The terms "MAY", "SHOULD", and "MUST" are to be interpreted as
described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. An Overview</span>
A SIP conference is an association of SIP user agents (i.e.,
conference participants) with a central point (i.e., a conference
focus), where the focus has direct peer-wise relationships with the
participants by maintaining a separate SIP dialog with each.
The focus is a SIP user agent that has abilities to host SIP
conferences including their creation, maintenance, and manipulation
using SIP call control means and potentially other non-SIP means.
In this tightly coupled model, the SIP conference graph is always a
star. The conference focus maintains the correlation among
conference's dialogs internally.
The conference focus can be implemented either by a participant or by
a separate application server.
In the first case, a focus is typically capable of hosting a simple
ad hoc conference only. We envision that such basic conference can
be established using SIP call control primitives only.
<span class="grey">Levin & Even Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
A dedicated conference server, in addition to the basic features,
offers richer functionality including simultaneous conferences, large
scalable conferences, reserved conferences, and managed conferences.
A conferencing server can support any subset of the advanced
conferencing functions presented in this document.
The media graph of a SIP conference can be centralized,
decentralized, or any combination of both, and potentially differ per
media type. In the centralized case, the media sessions are
established between the focus and each one of the participants. In
the de-centralized (i.e., distributed) case, the media graph is a
(multicast or multi-unicast) mesh among the participants.
Consequently, the media processing (e.g., mixing) can be performed
either by the focus alone or by the participants.
Conference participants and third parties can have different roles
and privileges in a certain conference. For example, conferencing
policy can state that the rights to disconnect from and to invite to
a conference are limited to the conference chair only.
Throughout the document, by conference policies we mean a set of
parameters and rules (e.g., maximum number of participants, needs
chair-person supervision or not, password protected or not, duration,
or a way of media mixing) that are defined at the onset of a
conference. Typically, conference policies would be specified by a
conference creator and need special privileges to be manipulated.
Throughout the document, by a conference state we mean a set of
information describing the conference in progress. This includes
participants' information (such as dialog identifiers), media
sessions in progress, the current loudest speaker, the current chair,
etc.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. High-Level Requirements</span>
In addition to the requirements presented in this document,
supplementary requirements for conferencing policy, media mixing and
other manipulations, floor control, privilege control, etc. will be
discussed in separate documents.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Discovery Phase</span>
Some of the requirements presented in this section can be met either
by configuration means or by using proprietary conventions.
Nevertheless, there is consensus that standard means for implementing
these functions by automata MUST be defined.
<span class="grey">Levin & Even Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
REQ-1: Discovery of a location of an arbitrary SIP conferencing
server(s).
REQ-2: Given a SIP Address-of-Record (AOR) of a certain entity,
resolution whether the SIP entity has focus capabilities.
REQ-3: Given a global identifier of a particular conference, locating
the conference focus.
REQ-4: Given a global identifier of a particular conference,
obtaining the conference properties.
REQ-5: Given a global identifier of a particular conference,
obtaining the conference state information.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Conference Creation</span>
Given a focus location, a means MUST be defined for an interested
entity (including a user agent) to implement the procedures below:
REQ-1: Creation of an ad-hoc conference identifier and the conference
with specified properties.
REQ-2: Creation of a reserved conference identifier for a conference
with specified properties.
REQ-3: Specifying properties upon conference creation in any of the
following ways: default, profiles, and explicitly.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Conference Termination</span>
REQ-1: Given a conference identifier, a means MUST be defined for a
user agent to disconnect all participants from the conference
and terminate the conference including the release of the
associated resources.
REQ-2: A means MAY be defined for requesting a focus to revert a
two-party conference to a basic SIP point-to-point session
including the release of the associated conferencing resources.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Participants' Manipulations</span>
Some of the requirements presented in this section can be met by
human intervention, configuration means, or proprietary
conventions. Nevertheless, there is consensus that standard
means for implementing these functions by automata MUST be
defined.
<span class="grey">Levin & Even Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Participation of a Conference-Unaware User Agent</span>
REQ-1: Focus MUST be able to invite and disconnect an <a href="./rfc3261">RFC 3261</a>
compliant only SIP user agent to and from a SIP conference.
REQ-2: An <a href="./rfc3261">RFC 3261</a> compliant only SIP user agent MUST be able to
dial-in to a particular SIP conference. In this case, only the
human knows that he/she is connected to the conference.
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Dial-Out Scenarios</span>
REQ-1: A means MUST be defined for a focus to invite another user
agent to one of the focus' conferences. This procedure MUST
result in the establishment of a single SIP dialog between the
two.
REQ-2: Given an existing SIP dialog between two user agents, if at
least one user agent has focus capabilities, a means MUST be
defined for the conference focus to invite the other user agent
to one of the focus' conferences without additional SIP dialog
establishment.
REQ-3: An invitation to a user agent to join a conference MUST
include a standard indication that it is a conference and the
conference identifier.
<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>. Dial-In Scenarios</span>
REQ-1: A means MUST be defined for a user agent to create an ad hoc
conference with default properties (as per "Conference Creation"
REQ-1 above) and to become a participant using a single SIP
dialog.
REQ-2: Given a reserved conference identifier, a means MUST be
defined for a user agent to activate the conference and to
become a participant using a single SIP dialog.
REQ-3: Given a conference identifier of an active conference, a means
MUST be defined for a user agent to dial-in the conference and
to become a participant using a single SIP dialog between the
two.
REQ-4: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to
dial-in the conference and to become a participant.
<span class="grey">Levin & Even Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
<span class="h4"><a class="selflink" id="section-3.4.4" href="#section-3.4.4">3.4.4</a>. Third-Party Invitation to a Conference</span>
REQ-1: Given a conference identifier, a means MUST be defined for a
user agent to invite another user agent to this conference.
REQ-2: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to
invite another user agent to this conference.
EQ-3: Given a conference identifier, a means SHOULD be defined for a
user agent to invite a list of user agents to this conference (a
so-called "mass invitation").
<span class="h4"><a class="selflink" id="section-3.4.5" href="#section-3.4.5">3.4.5</a>. Participants' Removal</span>
REQ-1: A means MUST be defined for a conference focus to remove a
conference participant from the conference.
REQ-2: Given a conference identifier, a means MUST be defined for a
user agent to remove a participant from the conference.
REQ-3: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to
remove a participant from the conference.
REQ-4: Given a conference identifier, a means MUST be defined for a
user agent to remove all the participants from the conference.
REQ-5: Given a conference identifier and a sub-list of participants,
a means MAY be defined for a user agent to remove the specified
participants from the conference (a so-called "mass ejection").
<span class="h4"><a class="selflink" id="section-3.4.6" href="#section-3.4.6">3.4.6</a>. Participants' Privacy</span>
A conference focus SHOULD support the procedures described in this
section. A conference participant MAY support the procedures
described in this section. The requirements imply that "anonymizing"
operations MUST be performed on all: the call control, the media
control, and the media content when appropriate.
REQ-1: A conference participant joins the conference "anonymously";
that is, his/her presence can be announced but without
disclosing his/her identity.
REQ-2: A conference participant requests a focus for anonymous
participation in the conference.
<span class="grey">Levin & Even Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
REQ-3: A conference participant joins a conference in a "hidden
mode"; that is, his/her presence and identity are not to be
disclosed to other participants.
REQ-4: A conference participant requests a focus for participation in
the conference in a hidden mode.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a> Conference State Information</span>
<span class="h4"><a class="selflink" id="section-3.5.1" href="#section-3.5.1">3.5.1</a>. Description</span>
By a conference state, we mean a virtual database describing the
conference in progress. This includes different conference aspects:
participants' information (such as dialog identifiers and state),
media sessions in progress (such as current stream contributing
sources and encoding schemes), the current loudest speaker, the
current chair, etc. Conference state is the latest conference
snapshot triggered by changes in participants' state, conference
policy changes, etc.
REQ-1: A conference state virtual database MUST have a modular
definition that is, it MUST be possible to access different
conference aspects independently.
REQ-2: It MUST be possible to aggregate information relating to
different conference aspects in a single report.
REQ-3: A mechanism for extensible definition and registration of
conference state evolving aspects MUST be present.
REQ-4: A default conference state report MUST be defined. It SHOULD
contain a minimal useful set of information (e.g., a list of
current conference participants).
<span class="h4"><a class="selflink" id="section-3.5.2" href="#section-3.5.2">3.5.2</a>. Dissemination of Changes</span>
REQ-1: A means MUST be defined for reporting the conference state
changes to interested parties (including non-conference
participants) in a timely manner.
REQ-2: A means MUST be defined for a SIP user agent to express its
interest in selected state changes only.
REQ-3: A means MUST be defined for a SIP user agent to express the
minimum interval between receiving state change reports.
REQ-4: It MUST be possible to aggregate recent changes in a single
reporting event.
<span class="grey">Levin & Even Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
REQ-5: Default conference state change reports MUST be defined. They
SHOULD contain minimal useful to the participants information
(e.g., participants' joining and leaving the conference).
<span class="h4"><a class="selflink" id="section-3.5.3" href="#section-3.5.3">3.5.3</a>. On-demand Information Dissemination</span>
REQ-1: A means MUST be defined to disseminate any conference state
information to interested parties (including SIP user agents)
on-demand.
REQ-2: A means MUST be defined for an interested party (including a
SIP user agent) to request conference state information of a
particular conference defined by the conference identifier.
REQ-3: A means MUST be defined for an interested party (including a
SIP user agent) to specify the subset of the conference state
information it wants and is capable of receiving.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Focus Role Migration</span>
REQ-1: A procedure for delegating a focus role by the current focus
to another participant MUST be defined.
REQ-2: A procedure for requesting a conference focus to transfer its
role to another participant MUST be defined.
REQ-3: A procedure for on-demand unconditional transfer of the focus
role to a different participant MUST be defined.
REQ-4: A detection procedure for a focus failure condition MUST be
defined.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Side-bar Conferences</span>
A standard means MUST be defined in order to implement the operations
defined in this section below.
REQ-1: A user agent (not a conference participant) joins a side-bar
within the conference by SIP means.
REQ-2: A user agent (not a conference participant) is invited to a
side-bar within the conference by SIP means.
REQ-3: A conference participant creates a side-bar conference with
one or more participants in a conference by SIP means.
REQ-4: A conference participant joins a side-bar within the
conference by SIP means.
<span class="grey">Levin & Even Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
REQ-5: A conference participant is invited to a side-bar within the
conference by SIP means.
REQ-6: A conference-unaware user agent (a participant or not) creates
and participates in side-bar conferences. It MAY be achieved by
non-SIP means.
REQ-7: A conference participant creates side-bar conferences within
the conference without establishing any additional SIP dialogs
with the focus. It MAY be achieved by non-SIP means.
REQ-8: A conference participant joins any number of side-bars within
the conference without establishing any additional SIP dialogs
with the focus. It MAY be achieved by non-SIP means.
REQ-9: A conference participant is invited to any number of side-bars
within the conference without establishing any additional SIP
dialogs with the focus. It MAY be achieved by non-SIP means.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Cascading of Conferences</span>
"Cascading of Conferences" is a term that has different meanings in
different contexts. Some examples are listed below:
- Peer-to-peer chaining of signaling. (Many ways exist to
build the media graph in this case.)
- Conferences have hierarchal signaling relations. (Many ways
exists to build the media graph in this case.)
- "Cascading" is used to distribute the media "mixing" only.
The distribution of signaling is not required.
As it can be seen from the examples, each will define a different set
of requirements.
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>. SIMPLE and SIP Conferencing Coordination</span>
REQ-1: SIMPLE-based Presence and Instant Messaging architecture
SHOULD fit into the general SIP Conferencing architecture.
REQ-2: A scenario where a multimedia SIP conference and a multiparty
instant messaging conversation take place among the same group
of participants MUST be addressed.
REQ-3: A scenario where a side-bar and/or a sub-IM-conference is
being held as a part of SIP conference MUST be addressed.
<span class="grey">Levin & Even Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document discusses high-level requirements for SIP conferencing.
Conferencing has some specific security requirements, which will be
summarized here at a very high level.
All of the operations and functions described in this document need
to be authorized by a focus or a participant. It is expected that
conferences will be governed by a set of authorization rules defined
as a part of the conference policy. In order for the conference
policy to be implemented, the focus needs to be able to authenticate
potential participants. Normal SIP mechanisms including Digest
authentication and certificates can be used [<a href="#ref-2" title=""SIP: Session Initiation Protocol"">2</a>]. These conference-
specific security requirements will be discussed in detail in the
protocol documents.
Conferencing also has privacy implications. Some of these are
discussed in this document. Standard SIP mechanisms for a user agent
to request privacy should be utilized by a focus and will be detailed
in the protocol documents.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Contributors</span>
This work is based on the discussions among the members of the SIP
Conferencing design team.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-2">2</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
<span class="grey">Levin & Even Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
Authors' Addresses
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: oritl@microsoft.com
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva, Israel
EMail: roni.even@polycom.co.il
<span class="grey">Levin & Even Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4245">RFC 4245</a> Conferencing Requirements November 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Levin & Even Informational [Page 12]
</pre>
|
