SIPPING Working Group D. Bijwaard Internet-Draft Alcatel-Lucent Intended status: Informational August 20, 2007 Expires: February 21, 2008 Requirements for group sessions using multicast draft-bijwaard-sipping-multicast-requirements-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Bijwaard Expires February 21, 2008 [Page 1] Internet-Draft Multicast session requirements August 2007 Abstract Multicast support in the Offer/Answer Model for SDP is mainly focussed on receiving and not on sending multicast streams, it assumes usage of the service announcement protocol for multicast sessions which is hardly in use. In this document requirements are described to enable multicast sessions with a group of users, switching session parts between unicast and multicast, and sessions containing both unicast and multicast streams. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. High-level requirements . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Bijwaard Expires February 21, 2008 [Page 2] Internet-Draft Multicast session requirements August 2007 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Bijwaard Expires February 21, 2008 [Page 3] Internet-Draft Multicast session requirements August 2007 2. Introduction Multicast support in [RFC3264] is described such that the SDP ([RFC4566]) answer in SIP ([RFC3261]) must match the send / receive of the offerer. This differs from the unicast view, where the directionality refers to the flow of media between offerer and answerer. This behaviour limits the ability to initiate a session as a multicast sender with a number of multicast receivers, since it assumes either an existing multicast source (or sink) from (to) which all multicast traffic is transmitted. When a true offerer/answerer model would be used for multicast streams as well, this would open possibilities to group sessions with one or more senders and receivers, and optionally members that can do both. Such an offerrer/answerrer model would also open the door for changing session parts from unicast to multicast and broadcast in order to optimize resources, and to sessions containing both unicast and multicast streams that would be hard to advertice using the Service Announcement Protocol. For this to work, the node that wants to do these resource optimisations needs to know if the devices are capable to receive multicast. Bijwaard Expires February 21, 2008 [Page 4] Internet-Draft Multicast session requirements August 2007 3. High-level requirements This section describes the high-level requirements for sessions containing multicast streams. The requirements are listed in Table 1 below and most contain background and examples. +-------+-----------------------------------------------------------+ | Req.# | Requirement | +-------+-----------------------------------------------------------+ | 1. | It should be possible to setup a SIP session with an SDP | | | for sending a multicast stream that can be answered with | | | an SDP for receiving a multicast stream. This would allow | | | a SIP UA that controls a multicast source to create SIP | | | sessions with SIP users that are deemed interested in | | | that multicast stream. | | | | | 2. | It should be possible to setup a SIP session with an SDP | | | for receiving a multicast stream that can be answerred | | | with an SDP for sending a multicast stream. Since the | | | offerrer may not know the multicast address in advance | | | (session announcement protocol (SAP) is hardly used), the | | | offerer should be able to indicate in its SDP that it | | | will accept any multicast address in the reply. | | | | | 3. | It should be possible to indicate in an SDP offer to | | | receive a stream independent whether it would be | | | unicasted or multicasted. Of course for the unicast | | | alternative, the IP number (IPv6 and/or IPv4) and port | | | should be specified in the offer, for the multicast | | | alternative the multicast address and port should be in | | | the answer from the anwerer and are not required in the | | | offer (since the offerer may not know this address and | | | port in advance). To be backward compatible with current | | | SDP, an additional field may be added to each media | | | description to indicate that multicast reception is | | | possible or impossible in IPv4 and/or IPv6. | | | Alternatively, a whole range of multicast addresses could | | | be specified in the SDP of the offerer (e.g. for all | | | multicast multimedia conferences c=IN IP4 | | | 224.2.0.1/127/32764) and the answerer could sent back the | | | specific address that is going to be used, or the | | | 224.0.0.0 address (which cannot be used as a multicast | | | address according to [RFC1112]) could be used to indicate | | | that a propper multicast address should be returned. | | | | Bijwaard Expires February 21, 2008 [Page 5] Internet-Draft Multicast session requirements August 2007 | 4. | It should be possible to answer an offer to receive a | | | unicast stream with an answer for sending a multicast | | | stream. This would allow a SIP User Agent that get | | | multiple requests for the same stream, to change this | | | stream to multicast for new requests. Currently, the | | | content provider would need to complete the initial | | | INVITE and then re-INVITE with the multicast address, | | | since it is unlikely for a client to know the multicast | | | address that is to be used for a new session in advance. | | | When the additional field mentioned in req. 2 would | | | default to "multicast reception possible" when this field | | | is not supplied, this requirement would be easy to meet | | | with current SIP UAs as receivers. Else when the field | | | would default to reception impossible, this field should | | | explicitly be set to "multicast reception possible" in | | | order to satisfy this requirement. | +-------+-----------------------------------------------------------+ Table 1 Bijwaard Expires February 21, 2008 [Page 6] Internet-Draft Multicast session requirements August 2007 4. Security Considerations No security considerations have yet been identified. Bijwaard Expires February 21, 2008 [Page 7] Internet-Draft Multicast session requirements August 2007 5. IANA Considerations This document does not require actions by the IANA. Bijwaard Expires February 21, 2008 [Page 8] Internet-Draft Multicast session requirements August 2007 6. Acknowledgements The work described in this Internet-Draft is based on results of IST FP6 Integrated Project DAIDALOS. DAIDALOS receives research funding from the European Community's Sixth Framework Programme. Apart from this, the European Commission has no responsibility for the content of this Internet-Draft. The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. Bijwaard Expires February 21, 2008 [Page 9] Internet-Draft Multicast session requirements August 2007 7. Normative References [RFC1112] Deering, S., "Host extensions for IP multicasting", RFC 1112, August 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4566] Handley, M., Jacobsen, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. Bijwaard Expires February 21, 2008 [Page 10] Internet-Draft Multicast session requirements August 2007 Author's Address Dennis Bijwaard Alcatel-Lucent Capitool 5 Enschede 7521PL The Netherlands Email: bijwaard@alcatel-lucent.com Bijwaard Expires February 21, 2008 [Page 11] Internet-Draft Multicast session requirements August 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, 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, THE IETF TRUST 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 BCP 78 and BCP 79. 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 http://www.ietf.org/ipr. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bijwaard Expires February 21, 2008 [Page 12]