Internet DRAFT - draft-bijwaard-sipping-multicast-requirements
draft-bijwaard-sipping-multicast-requirements
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]
