idnits 2.17.00 (12 Aug 2021) /tmp/idnits47895/draft-linyi-sipping-invite-with-conf-info-02.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 851. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 875. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (June 26, 2007) is 5442 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: draft-ietf-sipping-uri-services has been published as RFC 5363 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Tian 3 Internet-Draft Q. Sun 4 Expires: December 28, 2007 Huawei Technologies 5 June 26, 2007 7 Session Initiation Protocol (SIP) INVITE with Conference Info 8 draft-linyi-sipping-invite-with-conf-info-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 28, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This specification defines a mechanism that allows a SIP User Agent 42 Client (UAC) to provide a conference server with the initial 43 conference information and policy using an INVITE-contained 44 conference-info. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 5 51 4. INVITE: Sending conference-info to Conference Server . . . . . 6 52 4.1. Conference-Info Format . . . . . . . . . . . . . . . . . . 6 53 4.1.1. Conference-Info Format derived from Conference 54 State Package . . . . . . . . . . . . . . . . . . . . 7 55 4.1.2. Conference-Info Format derived from XCON Data Model . 7 56 4.2. UAC Procedures . . . . . . . . . . . . . . . . . . . . . . 8 57 4.2.1. re-INVITE Request Generation . . . . . . . . . . . . . 9 58 4.3. Conference Server Procedures . . . . . . . . . . . . . . . 9 59 4.3.1. re-INVITE Request Handling . . . . . . . . . . . . . . 10 60 5. INVITE: Sending URI-List with conference-info to 61 Conference Server . . . . . . . . . . . . . . . . . . . . . . 11 62 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 6.1. Creation of Conference with initial conference-info . . . 12 64 6.2. Creation of a Conference with initial URI-List and 65 conference-info . . . . . . . . . . . . . . . . . . . . . 15 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 68 9. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 22 69 10. MIME Information . . . . . . . . . . . . . . . . . . . . . . . 23 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 72 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 73 Appendix A. History of change . . . . . . . . . . . . . . . . . . 25 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 75 Intellectual Property and Copyright Statements . . . . . . . . . . 27 77 1. Introduction 79 Section 5.4 of RFC 4579 [1] describes how to create a conference 80 using ad-hoc SIP methods. The client sends an INVITE request to a 81 conference factory URI and receives the actual conference URI, which 82 contains the "isfocus" feature tag, in the Contact header field of a 83 response - typically a 200 (OK) response. 85 This specification extends the above mechanim to allow UAC to be able 86 to provide the Conference Server with the initial conference 87 information and policy (referred as conference-info below). 89 This specification further provides a mechanism for Conference Server 90 to distribute the conference-info generated from ad hoc conference 91 creation request as the history information to invitees. 93 The mechanism defined in this specification can be used either 94 standalone or together with other mechanisms, e.g. URI-List 95 conferencing mechanism defined in RFC XXX {URI List Conferencing} [2] 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [3] 103 This document uses the conferencing terminology defined in RFC 4353 104 [9] "conferencing Framework". 106 3. Requirements Analysis 108 RFC 4579 [1] defines a mechanism to provide the conference server 109 with the initial set of participants in a single operation during the 110 ad hoc conference creation. In addition the invoker may want to 111 provide simple conference information and policy referred as 112 conference-info below, for example the subject and maximum numbers of 113 participants, for an ad hoc conference in the same operation. In ad 114 hoc conference scenario they rarely desire to manipulate the 115 conference policy, whether before the conference is created or during 116 the conference. 118 RFC XXX {URI List Conferencing} [2] defines a mechanism for 119 Conference Server to provide URI-List history to invitees by 120 including a 'recipient-list-history' body which contains the 121 manipulated list of invitees. The same principle could be applied to 122 conference-info. When Conference Server sends INVITE to invitees, 123 e.g. triggered by REFER request or URI-List conference creation, the 124 Conference Server can provide them with the conference-info as 125 history information. This will help invitees to determine whether to 126 join this conference which may fall into their interest. 128 In current art when the invitees get an INVITE request with 'isfocus' 129 feature tag they may subscribe to the conference event package as 130 defined in RFC 4575 [4] and get notification before joining. 131 Consider the fact that the main criteria for invitees to determine 132 whether to join a conference may be some simple information, e.g. 133 subject, it is more efficient and convenient for invitees to get 134 information from the incoming INVITE rather than using subscription 135 to the Conference Event Package. This mechanism could be considered 136 as complementary to conference event package subscription mechanism. 137 Invitees can also use confernce event package subscription mechanism 138 to get more detail information. 140 The requirements to support invitation with conference-info may be 141 summarized as follows: 143 REQ 1: The conference mechanism MUST allow the invoker to provide 144 the Conference Server with the initial conference information and 145 policy in order to create an ad-hoc conference via one operation. 147 REQ 2: The conference mechanism MUST allow the Conference Server 148 to distribute the conference information and policy to invitees 149 contained in the URI-List. 151 4. INVITE: Sending conference-info to Conference Server 153 RFC 4575 [4] defines a Conference Event Package for tightly coupled 154 conferences using the Session Initiation Protocol (SIP) events 155 framework, along with a data format used in notifications for SIP 156 specific conferencing. RFC XXX {XCON Data Model} [5] extends the 157 data format to support more call signaling protocols besides SIP and 158 cover the functionality defined in the XCON conferencing framework. 159 A sub-set of both data formats can be used to represent conference- 160 info, e.g. and . 162 The conference-info can be included in the body of initial SIP INVITE 163 request to create an ad-hoc conference. Hence it can be included in 164 the follow-up SIP INVITE requests so that invitees are aware. 166 4.1. Conference-Info Format 168 The sub set of data format defined in RFC 4575 [4] and extended in 169 RFC XXX {XCON Data Model} [5] can be used to represent the 170 conference-info which could be carried in SIP INVITE method. The 171 amount of data MUST be limited to avoid overload of SIP messages. 173 The element has three attributes 'entity', 'state' 174 and 'version'. The 'entity' and 'version' attributes MUST be 175 included. The 'state' attribute is MAY be included and the default 176 value is "full". 178 In this specification, there are some restrictions for attributes of 179 element as follow: 181 o 'entity': In initial INVITE request from invoker the value MAY be 182 any URI and MUST be ignored by Conference Server. In subsequent 183 INVITE requests from Conference Server the value MUST be the 184 conference URI that identifies the conference created by the 185 Conference Server. The invitees can subscribe this URI for 186 receiving Conference Event Package. 188 o 'state': This attribute MAY not be present in all INVITE requests. 189 If it is present, it MUST be ignored by the Conference Server and 190 invitees. 192 o 'version': This attribute MAY contain any version number and MUST 193 be ignored by the Conference Server and invitees. 195 4.1.1. Conference-Info Format derived from Conference State Package 197 Following is the sub set of data format defined in RFC 4575 [4] 198 representing the conference-info. Other elements or attributes 199 defined in RFC 4575 [4] SHOULD NOT included in initial INVITE request 200 and subsequent INVITE requests to invitees. 202 203 | 204 |-- 205 | |-- 206 | |-- 207 | |-- 208 | |-- 209 | | 210 | |-- 211 | | |-- 212 | | | |-- 213 | | | |-- 214 | | | |-- 215 | | 216 | |-- 218 Figure 1: Conference-Info Format derived from Conference State 219 Package 221 4.1.2. Conference-Info Format derived from XCON Data Model 223 Following is the sub set of data format defined in RFC XXX {XCON Data 224 Model} [5] representing the conference-info. Other elements or 225 attributes defined in RFC XXX {XCON Data Model} [5] SHOULD NOT 226 included in initial INVITE request and subsequent INVITE requests to 227 invitees. 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 | | | |-- 264 Figure 2: Structure of Conference-Info derived from XCON Data Model 266 4.2. UAC Procedures 268 A UAC that wants to include the initial conference-info in its 269 initial INVITE request MUST add a body whose disposition type is 270 'conference-info' as defined in section xxx of this specification. 271 Additionally, the UAC MUST include the 'conference-info-invite' 272 option-tag, which is registered with the IANA in Section xxx in a 273 Require header field. The UAC sends this INVITE request to the 274 conference factory URI. 276 A 200 (OK) response means that the conference was created 277 successfully, that the UAC that generated the INVITE request is in 278 the conference, and that the server understood the conference 279 information. 281 4.2.1. re-INVITE Request Generation 283 The previous section has specified how to include the conference 284 information in an initial INVITE request to a conference server. 285 Once the INVITE-initiated dialog between the UAC and the Conference 286 Server has been established, the UAC can send re-INVITE requests to 287 the conference server to, modify the characteristics of the media 288 exchanged with the server. 290 There are no semantics associated with conference-info bodies in re- 291 INVITE requests. Therefore, UACs MUST NOT include conference-info 292 bodies in re-INVITE requests sent to a conference server (although it 293 may become useful at some future time and future extentions may 294 define them). 296 4.3. Conference Server Procedures 298 Conference Server that is able to receive and process INVITE requests 299 with a 'conference-info' body MUST include a 'conference-info-invite' 300 option-tag in a Supported header field when responding to OPTIONS 301 requests. 303 On reception of an INVITE request containing a 'conference-info' body 304 as described in Section 3, a conference server MUST follow the rules 305 described in RFC 4579 [1] to create ad-hoc conference. 307 If element is present, the Conference Server 308 MUST reject the requests to add new participants to the conference 309 when the number of participants has reached the number specified in 310 this element. The Conference Server MUST ignore 'state' attribute if 311 it is present. The Conference Server MUST ignore 'version' 312 attribute. 314 The Conference Server MUST include the same conference-info from 315 incoming INVITE request to the invitees as the history information 316 using an INVITE-contained conference-info request. The Conference 317 Server MUST NOT add new elements to history information. 319 If the Conference Server includes conference-info history in an 320 outgoing INVITE request, it MUST include a Content-Disposition header 321 field (which is specified in RFC 2183 [6] ) with the value set to 322 'conference-info-history' and a 'handling' parameter (as specified in 323 RFC 3204 [7] ) set to "optional". 325 4.3.1. re-INVITE Request Handling 327 There are no semantics associated with conference-info bodies in re- 328 INVITE requests. Therefore, a Conference Server receiving a re- 329 INVITE request with a conference-info body and, consequently, a 330 'conference-info-invite' option-tag, following standard SIP 331 procedures, MUST reject it with a 420 (Bad Extension), which carries 332 an Unsupported header field listing the 'conference-info-invite' 333 option-tag. 335 This is because the resource identified by the conference URI does 336 not actually support this extension. On the other hand, the 337 resource identified by the conference factory URI does support 338 this extension and, consequently, would include the 'conference- 339 info-invite' option-tag in, for example, responses to OPTIONS 340 requests. 342 5. INVITE: Sending URI-List with conference-info to Conference Server 344 The mechanism defined in section 4 of this specification can be used 345 together with other mechanisms, e.g. URI-List conferencing mechanism 346 defined in RFC XXX {URI List Conferencing} [2] . The initial INVITE 347 request can carry a 'multipart/mixed' body composed of three bodies: 349 o 'application/sdp' body: describes the session; 351 o 'application/resource-lists+xml' body: describes the list of 352 target URIs; 354 o 'application/conference-info+xml' body: contains the conference 355 information. 357 The UAC and Conference Server MUST follow the procedures defined in 358 RFC XXX {URI List Conferencing} [2] and section 4 of this 359 specification respectively. In addition, the UAC MUST ensure the 360 number of URIs in the URI-List will not exceed the number specified 361 in element when it is present. A Conference 362 Server receiving a INVITE request with a URI-List body and a 363 conference-info body where the number of URIs exceed maximum user 364 count, consequently, rejects it with a 403 (Forbidden). 366 6. Example 368 6.1. Creation of Conference with initial conference-info 370 Figure 3 shows an example of ad-hoc conference creation with initial 371 conference-info. A UAC sends an INVITE request F1 that contains SDP 372 body and conference-info to the Conference Server. The Conference 373 Server answers with a 200 (OK) response. Then Conference Server is 374 requested to add new participant Bob to the specified conference 375 using REFER method. The UAC sends a REFER request F3 to the 376 conference URI with a Refer-To containing the URI of Bob. The 377 Conference Server sends an INVITE request F7 to Bob containing the 378 conference-info history. Then Bob knows the conference-info of this 379 specific conference, such as subject, directly when he receives the 380 INVITE request F7 and decides to join it. 382 Alice Conference Server Bob 383 | | | 384 | F1:INVITE sip:Conf-Factory with initial conference-info | 385 |----------------------------->| | 386 | F2:200 OK Contact:Conf-ID;isfocus | 387 |<-----------------------------| | 388 | | | 389 | F3:REFER sip:Conf-ID Refer-To:Bob | 390 |----------------------------->| | 391 | F4:202 Accepted | | 392 |<-----------------------------| | 393 | F5:NOTIFY (Trying) | | 394 |<-----------------------------| | 395 | F6:200 OK F4 | | 396 |----------------------------->| | 397 | | F7:INVITE | 398 | |------------------------------>| 399 | | F8:200 OK | 400 | |<------------------------------| 401 | | | 403 Figure 3: Creation of a conference with initial conference-info using 404 ad-hoc SIP method 406 Figure 4 shows an example of the INVITE request F1, which carries a 407 'multipart/mixed' body composed of two other bodies: 409 o 'application/sdp' body: describes the session; 411 o 'application/conference-info+xml' body: contains the initial 412 conference-info. 414 INVITE sip:32132219811205@conf.example.com SIP/2.0 415 Via: SIP/2.0/TCP beijing.example.com 416 ;branch=z9hG4bKa38ssa8s 417 Max-Forwards: 70 418 To: "Conference Factory" 419 From: Alice ;tag=13323 420 Call-ID: b01766e67c4b48af234 421 CSeq: 1 INVITE 422 Contact: 423 Allow: INVITE, ACK, CANCEL, BYE, REFER 424 Allow-Events: dialog 425 Accept: application/sdp, message/sipfrag 426 Require: conference-info-invite 427 Content-Type: multipart/mixed;boundary="boundary1" 428 Content-Length: ... 430 --boundary1 431 Content-Type: application/sdp 433 (SDP not shown) 435 --boundary1 436 Content-Type: application/conference-info+xml 437 Content-Disposition: conference-info 439 440 444 445 Agenda: This month's goals 446 447 448 http://www.example.com/salesgroup/ 449 web-page 450 451 452 10 453 454 456 Figure 4: Initial INVITE request received at the Conference Server 458 Figure 5 shows an example of the INVITE request F7, which carries a 459 'multipart/mixed' body composed of three other bodies: 461 o 'application/sdp' body: describes the session; 463 o 'application/conference-info+xml' body: contains the conference 464 info history. 466 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKt34932hw 467 Max-Forwards: 70 468 To: 469 From: 470 Call-ID: 849392fklgl43 471 CSeq: 1 INVITE 472 Contact: ;isfocus 473 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 474 Accept: application/sdp, message/sipfrag 475 Require: conference-info-invite 476 Supported: replaces, join 477 Content-Type: multipart/mixed;boundary="boundary1" 478 Content-Length: ... 480 --boundary1 481 Content-Type: application/sdp 483 (SDP not shown) 485 --boundary1 486 Content-Type: application/conference-info+xml 487 Content-Disposition: conference-info-history; handling=optional 489 490 494 495 Agenda: This month's goals 496 497 498 http://www.example.com/salesgroup/ 499 web-page 500 501 502 10 503 504 506 6.2. Creation of a Conference with initial URI-List and conference-info 508 Figure 6 shows an example of ad-hoc conference creation with initial 509 URI-List and conference-info. A UAC sends an INVITE request F1 that 510 contains initial participants list and conference-info to the 511 Conference Server. The Conference Server answers with a 200 (OK) 512 response. Then Conference Server generates an INVITE request to each 513 of the participants identified by the URIs included in the URI-list. 515 The Conference Server includes a manipulated URI-list and conference- 516 info history in each of the outgoing INVITE requests. 518 Alice Conference Server Bob Alice Carol 519 | | | | | 520 | F1:INVITE with URI-List and conference-info | | 521 |---------------------->| | | | 522 | F2:200 OK | | | | 523 |<----------------------| | | | 524 | Conference Server distributes URI-List and confernce info history 525 | | F3:INVITE | | | 526 | |---------------->| | | 527 | | F4:200 OK | | | 528 | |<----------------| | | 529 | | F5:INVITE | | | 530 | |------------------------->| | 531 | | F6:200 OK | | | 532 | |<-------------------------| | 533 | | F7:INVITE | | | 534 | |---------------------------------->| 535 | | F8:200 OK | | | 536 | |<----------------------------------| 537 | | | | | 539 Figure 7: Creation of a conference with initial URI-List and 540 conference-info 542 Figure 8 shows an example of the INVITE request F1, which carries a 543 'multipart/mixed' body composed of three other bodies: 545 o 'application/sdp' body: describes the session; 547 o 'application/resource-lists+xml' body: contains the list of target 548 URIs 550 o 'application/conference-info+xml' body: contains the conference 551 information. 553 INVITE sip:32132219811205@conf.example.com SIP/2.0 554 Via: SIP/2.0/TCP beijing.example.com 555 ;branch=z9hG4bKa38ssa8s 556 Max-Forwards: 70 557 To: "Conf Factory" 558 From: Alice ;tag=13323 559 Call-ID: b01766e67c4b48af234 560 CSeq: 1 INVITE 561 Contact: 562 Allow: INVITE, ACK, CANCEL, BYE, REFER 563 Allow-Events: dialog 564 Accept: application/sdp, message/sipfrag 565 Require: recipient-list-invite, conference-info-invite 566 Content-Type: multipart/mixed;boundary="boundary1" 567 Content-Length: ... 569 --boundary1 570 Content-Type: application/sdp 572 (SDP not shown) 574 --boundary1 575 Content-Type: application/resource-lists+xml 576 Content-Disposition: recipient-list 578 579 581 582 583 585 587 588 590 591 592 593 594 --boundary1-- 596 --boundary1 597 Content-Type: application/conference-info+xml 598 Content-Disposition: conference-info 600 601 605 606 Agenda: This month's goals 607 608 609 http://www.example.com/salesgroup/ 610 web-page 611 612 613 10 614 615 617 Figure 8: Initial INVITE request received at the Conference Server 619 The INVITE requests F3, F5, and F7 are similar in nature. Figure 9 620 shows an example of the INVITE request F3, which carries a 621 'multipart/mixed' body composed of three other bodies: 623 o 'application/sdp' body: describes the session; 625 o 'application/resource-lists+xml' body: contains the list of target 626 URIs manipulated by Conference Server 628 o 'application/conference-info+xml' body: contains the history 629 conference-info. 631 Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKt34932hw 632 Max-Forwards: 70 633 To: 634 From: Conference Server ;tag=234332 635 Call-ID: 849392fklgl43 636 CSeq: 1 INVITE 637 Contact: ;isfocus 638 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 639 Accept: application/sdp, message/sipfrag 640 Require: recipient-list-invite, conference-info-invite 641 Supported: replaces, join 642 Content-Type: multipart/mixed;boundary="boundary1" 643 Content-Length: ... 645 --boundary1 646 Content-Type: application/sdp 648 (SDP not shown) 650 --boundary1 651 Content-Type: application/resource-lists+xml 652 Content-Disposition: recipient-list-history; handling=optional 654 655 657 658 659 661 662 664 665 666 --boundary1-- 668 --boundary1 669 Content-Type: application/conference-info+xml 670 Content-Disposition: conference-info-history; handling=optional 672 673 677 678 Agenda: This month's goals 679 680 681 http://www.example.com/salesgroup/ 682 web-page 683 684 685 10 686 687 689 7. Security Considerations 691 SIP Conferencing generally have authorization rules about who can or 692 cannot join a conference, what type of media can or cannot be used, 693 etc. This information is used by the focus to admit or deny 694 participation in a conference. It is RECOMMENDED that these types of 695 authorization rules be used to provide security for a SIP conference. 696 For this authorization information to be used, the focus needs to be 697 able to authenticate potential participants. Normal SIP mechanisms 698 including Digest authentication and certificates can be used. These 699 conference specific security requirements are discussed further in 700 the requirements and framework documents. 702 This specification defines a mechanism to setup ad hoc SIP 703 conferences using a INVITE-contained conference-info which may 704 contain additional policy for focus to control the conferences. 705 Implementations of conference servers MUST follow the policy 706 contained in conference-info. 708 The mechanism defined in this specification can be used together with 709 URI-List Service. The Framework and Security Considerations for SIP 710 URI-List Services (which is documented in RFC XXXX [8] ) discusses 711 issues related to SIP URI-list services. Given that a conference 712 server sending INVITE requests to a set of users acts as an URI-list 713 service, implementations of conference servers that handle lists MUST 714 follow the security-related policy in RFC XXXX [8] . These rules 715 include mandatory authentication and authorization of clients, and 716 opt-in lists. 718 8. IANA Considerations 720 This document defines the 'conference-info-invite' SIP option-tag. 721 It should be registered in the Option Tags subregistry under the SIP 722 parameter registry. The following is the description to be used in 723 the registration. 725 +------------------------+------------------------------+-----------+ 726 | Name | Description | Reference | 727 +------------------------+------------------------------+-----------+ 728 | conference-info-invite | The body contains the | [RFC XXXX]| 729 | | conference information and | | 730 | | policy for a specific | | 731 | | conference. | | 732 +------------------------+------------------------------+-----------+ 734 Figure 9: Registration of the 'conference-info-invite' Option-Tag in 735 SIP. 737 +------------------------+------------------------------+-----------+ 738 | Name | Description | Reference | 739 +------------------------+------------------------------+-----------+ 740 | conference-info | The body contains the | [RFC XXXX]| 741 | | conference information and | | 742 | | policy for a specific | | 743 | | conference. | | 744 +------------------------+------------------------------+-----------+ 746 Figure 10: Registration of the 'conference-info' Disposition Type. 748 +------------------------+------------------------------+-----------+ 749 | Name | Description | Reference | 750 +------------------------+------------------------------+-----------+ 751 | conference-info-history| The body contains the history| [RFC XXXX]| 752 | | conference information and | | 753 | | policy for a specific | | 754 | | conference. | | 755 +------------------------+------------------------------+-----------+ 757 Figure 9: Registration of the 'conference-info-history' Disposition 758 Type. 760 9. Acknowledges 762 Henning Schulzrinne, Spencer Dawkins, Even Roni, Oscar Novo and Peili 763 Xu provided useful comments on this document. 765 10. MIME Information 767 The MIME type for the conference-info is: application/ 768 conference-info+xml as defined in RFC 4575 [4] 770 11. References 772 11.1. Normative References 774 [1] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 775 Call Control - Conferencing for User Agents", RFC 4579, 776 August 2006. 778 [2] Camarillo, G. and A. Johnston, "Conference Establishment Using 779 Request-Contained Lists in the Session Initiation Protocol 780 (SIP)", RFC xxxx, January 2007. 782 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 783 Levels", RFC 2119, March 1997. 785 [4] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 786 Initiation Protocol (SIP) Event Package for Conference State", 787 RFC 4575, August 2006. 789 [5] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference 790 Information Data Model for Centralized Conferencing (XCON)", 791 RFC xxxx, January 2007. 793 [6] Troost, R., Dorner, S., and K. Moore, "Communicating 794 Presentation Information in Internet Messages: The Content- 795 Disposition Header Field", RFC 2183, August 1997. 797 [7] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 798 Watson, M., and M. Zonoun, "Communicating Presentation 799 Information in Internet Messages: The Content-Disposition Header 800 Field", RFC 3204, December 2001. 802 [8] Camarillo, G. and A. Roach, "Framework and Security 803 Considerations for Session Initiation Protocol (SIP) Uniform 804 Resource Identifier (URI)-List Services", 805 draft-ietf-sipping-uri-services-06 (work in progress), 806 September 2006. 808 11.2. Informative References 810 [9] Rosenberg, J., "A Framework for Conferencing with the Session 811 Initiation Protocol (SIP)", RFC 4353, February 2006. 813 Appendix A. History of change 815 This is the first version of this draft. 817 Authors' Addresses 819 Linyi Tian 820 Huawei Technologies 821 Bantian Longgang 822 Shenzhen, Guandong 518129 823 P.R China 825 Phone: +86 755 28780808 826 Email: tianlinyi@huawei.com 828 Qian Sun 829 Huawei Technologies 830 Bantian Longgang 831 Shenzhen, Guandong 518129 832 P.R China 834 Phone: +86 755 28780808 835 Email: sunqian@huawei.com 837 Full Copyright Statement 839 Copyright (C) The IETF Trust (2007). 841 This document is subject to the rights, licenses and restrictions 842 contained in BCP 78, and except as set forth therein, the authors 843 retain all their rights. 845 This document and the information contained herein are provided on an 846 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 847 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 848 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 849 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 850 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 851 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 853 Intellectual Property 855 The IETF takes no position regarding the validity or scope of any 856 Intellectual Property Rights or other rights that might be claimed to 857 pertain to the implementation or use of the technology described in 858 this document or the extent to which any license under such rights 859 might or might not be available; nor does it represent that it has 860 made any independent effort to identify any such rights. Information 861 on the procedures with respect to rights in RFC documents can be 862 found in BCP 78 and BCP 79. 864 Copies of IPR disclosures made to the IETF Secretariat and any 865 assurances of licenses to be made available, or the result of an 866 attempt made to obtain a general license or permission for the use of 867 such proprietary rights by implementers or users of this 868 specification can be obtained from the IETF on-line IPR repository at 869 http://www.ietf.org/ipr. 871 The IETF invites any interested party to bring to its attention any 872 copyrights, patents or patent applications, or other proprietary 873 rights that may cover technology that may be required to implement 874 this standard. Please address the information to the IETF at 875 ietf-ipr@ietf.org. 877 Acknowledgment 879 Funding for the RFC Editor function is provided by the IETF 880 Administrative Support Activity (IASA).