2.8.11 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-29

Chair(s):

Joerg Ott <jo@acm.org>
Colin Perkins <csp@csperkins.org>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: mmusic@ietf.org
To Subscribe: mmusic-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mail-archive/web/mmusic/index.html

Description of Working Group:

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was
chartered to develop protocols to support Internet teleconferencing
and multimedia communications. These protocols are now reasonably
mature, and many have received widespread deployment. The group is
now focussed on the revisions of these protocols in the light of
implementation experience and additional demands that have arisen
from other WGs (such as AVT, SIP, SIPPING, and MEGACO).

Multimedia communications protocols use a common platform to express
media and session descriptions: the Session Description Protocol, SDP.
The many uses of SDP have led to (requests for) numerous extensions
and have led to recognition of several flaws in the protocol design.
In spite of these, it is widely deployed.

- To support this current deployment, MMUSIC will revise SDP
suitable for publication as a Draft Standard RFC. This will
involve correcting minor bugs and clarifying the current
specification.

- Various extensions to SDP will be pursued to remedy the most
urgent of SDP's shortcomings. These will be limited to use of
SDP in conjunction with connection-oriented media such as TCP
and SCTP, offering support to work with NATs and firewalls
(e.g. via the ICE methodology), and exchange of media session
security keys.

With the exception of these specific items, only extensions within
the existing SDP framework will be done (e.g. registering new codecs
and defining parameters for them extending SDP to include new address
families).

To address the more fundamental issues with SDP, a next generation of
SDP, referred to as SDPng, will be needed. An initial proposal is now
available, and will be progressed to Experimental RFC while we gain
experience with implementations. An informational document will be
produced describing how the transition to a new session description
protocol can be managed, to prepare implementors for such a future
change.

MMUSIC will maintain and revise the specification of the Real Time
Streaming Protocol (RTSP), including fixes and clarifications based
on implementation experience. The revised RTSP specification will be
re-issued as a Proposed Standard RFC. We will also document how RTSP
can be used in the presence of NAT boxes.

An Internet Media Guide (IMG) is a collection of multimedia session
descriptions expressed using SDP or some other session description
format. It is used to describe a collection of multimedia sessions
(e.g. television programme schedules). The IMG must be delivered to
a potentially large audience, who use it to join a subset of the
sessions described, and who may need to be notified of changes to the
IMG.

MMUSIC will investigate delivery mechanisms for IMGs, generalizing
our work on session announcement and discovery protocols (SAP, RTSP,
SIP). We will investigate and document requirements for IMG delivery
mechanisms, and identify the requirements that these delivery
mechanisms impose on the session description formats used by the IMG.
We will then work to produce a framework document outlining the use
of (existing) protocols to create an IMG delivery infrastructure.
After successful completion of these initial milestones for IMG
delivery, the MMUSIC working group will decide whether or not MMUSIC
is the proper place to pursue any needed mechanisms for IMGs, and if
so, recharter accordingly

The MMUSIC work items will be pursued in close coordination with other
IETF WGs related to multimedia conferencing and IP telephony (AVT, SIP,
SIPPING, SIMPLE, XCON, MEGACO and, where appropriate, MIDCOM and NSIS).
Where appropriate, new separate working groups may be split off (as has
happened with the SIP WG).

The Working Group is also charged with addressing security issues
related to the protocols it develops.

Goals and Milestones:

Done  Conduct WG Last Call for SAP Internet-Draft
Done  Submit a revised Internet Multimedia Conferencing Architecture I-D.
Done  Submit a revised SIP I-D.
Done  Submit SDP to the IESG for consideration as a Proposed Standard.
Done  Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol.
Done  Conduct WG Last Call for RTSP Internet-Draft.
Done  Submit Internet-Draft on Internet Multimedia Conferencing Architecture.
Done  Submit RTSP to IESG for consideration as a Proposed Standard.
Done  Conduct WG Last Call for SIP Internet-Draft.
Done  Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard.
Done  Conduct WG Last Call for SAP Security Internet-Draft.
Done  Conduct second WG Last Call for SAP.
Done  Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard.
Done  Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard.
Done  Submit IPv6 Extensions to SDP for Proposed Standard
Done  Submit SIP's offer/answer use of SDP for Proposed Standard
Done  Submit SDP4NAT for Proposed Standard (Informational?)
Done  Submit SDP source filter extensions for Proposed Standard
Done  Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG.
Done  Submit SDP security extension for Proposed Standard
Done  Submit IMG requirements and framework for Informational
Aug 04  Submit revised SDP spec for Proposed (or Draft) Standard
Done  Submit SDP Offer/Answer examples for Informational
Aug 04  Review work on IMGs and update charter accordingly
Done  Submit SDP connection-oriented media draft for Proposed Standard
Nov 04  Submit SDPng transition scenarios for Informational
Nov 04  Submit SDPng base specification for Experimental
Nov 04  Submit ICE draft for Proposed Standard
Feb 05  Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)
May 05  Submit RTSP NAT considerations draft
Jul 05  Consider update of SDP specification for draft standard
Dec 05  Submit updated SDP Offer/Answer examples draft for Informational

Internet-Drafts:

  • draft-ietf-mmusic-sdp-srcfilter-06.txt
  • draft-ietf-mmusic-sdp-new-21.txt
  • draft-ietf-mmusic-sdp-comedia-09.txt
  • draft-ietf-mmusic-kmgmt-ext-11.txt
  • draft-ietf-mmusic-sdpng-trans-04.txt
  • draft-ietf-mmusic-rfc2326bis-08.txt
  • draft-ietf-mmusic-rtsp-nat-03.txt
  • draft-ietf-mmusic-sdescriptions-07.txt
  • draft-ietf-mmusic-offer-answer-examples-05.txt
  • draft-ietf-mmusic-img-req-07.txt
  • draft-ietf-mmusic-ice-03.txt
  • draft-ietf-mmusic-img-framework-08.txt
  • draft-ietf-mmusic-anat-02.txt
  • draft-ietf-mmusic-sdp-media-label-00.txt
  • draft-ietf-mmusic-connection-precon-00.txt
  • draft-ietf-mmusic-rtsp-announce-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC2326 PS Real Time Streaming Protocol (RTSP)
    RFC2327 PS SDP: Session Description Protocol
    RFC2543 PS SIP: Session Initiation Protocol
    RFC2974 E Session Announcement Protocol
    RFC3108 PS Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections
    RFC3259 I A Message Bus for Local Coordiantion
    RFC3264 PS An Offer/Answer Model with SDP
    RFC3266 PS Support for IPv6 in SDP
    RFC3388 PS Grouping of media lines in Session Description Protocol SDP
    RFC3524 PS Mapping of Media Streams to Resource Reservation Flows
    RFC3605 Standard RTCP attribute in SDP
    RFC3890 Standard A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)

    Current Meeting Report

    Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
    61st IETF meeting, Washington DC, November 2004

    Reported by Colin Perkins

    The MMUSIC working group met once at the 61st IETF in Washington DC. The meeting was attended by some 80 participants. Subjects under discussion included application sharing, ICE, Internet Media Guides, SDP and various SDP extensions (for media loopback, BFCP, labels and connection establishment, security and connectivity preconditions).

    Introduction and Status Update

    The meeting started with an introduction and status update from the chairs. The working group has had one RFC published since the last meeting (RFC 3890 on the Session Bandwidth Modifier) and has several drafts are under IESG review: the IMG requirements and framework, SDP source filter extensions and SDP connection oriented media extensions. The draft on Alternative Network Address Types Semantics (ANAT) for the SDP Grouping Framework has been updated in response to IESG comments and is back under review. The SDP key management and security descriptions drafts are being updated in response to review comments from the IESG.

    Several drafts have been discussed on the mailing list, but are not on the agenda for the meeting. Remote camera control will be discussed in AVT (draft-even-avt-h224-00.txt). RTSP (draft-ietf-mmusic-rfc2326bis-08.txt) and the ANNOUNCE extension (draft-ietf-mmusic-rtsp-announce-00.txt) are in progress, but delayed due to lack of review and editing manpower -- help was solicited. The main connection-oriented media specification (draft-ietf-mmusic-sdp-comedia-09.txt) is under IESG review, the TLS extension to comedia (draft-ietf-mmusic-comedia-tls-02.txt) is under development. Symmetric RTP (draft-wing-mmusic-symmetric-rtprtcp-01.txt) is clearly useful, but the chairs suggested it would be better suited to the AVT working group. The draft on tight membership support in SDP (draft-ekim-mmusic-sdp-membership-01.txt) conflicts with work in XCON, and should be discussed there.

    The Internet Media Guide (IMG) requirements and framework are complete and under review by the IESG. We have a milestone to revise our charter to accomodate future work in this area. Work to be considered includes: IMG ANNOUNCE via FLUTE, IMG QUERY/RESOLVE via HTTP, IMG SUBSCRIBE/NOTIFY via SIP, and possibly IMG MIME types and URI/URL formats. The chairs, area director, and parties interested in IMGs will work to develop new milestones are charter text to cover this work, and bring it back to the working group for review.

    ICE: A Methodology for NAT Traversal

    Jonathan Rosenberg presented ICE (draft-ietf-mmusic-ice-03.txt) outlining the changes since the previous version and discussing open issues. Major changes include:

    - In the ABNF, rename the "alt" attribute to "candidate" to avoid a conflict with 3GPP specs, remove the remnents of "derived-from", and change the "username" attribute to "user-frag" to more closely reflect its semantics.

    - The ICE XML schema has been updated to support both IPv4 and IPv6 (the implementation of ICE using ANAT supports this already, this change brings the schema in line with reality).

    - Added implementation hints on masking allocation latency.

    - Updated discussion of use of TURN as an address allocation protocol, making it "SHOULD" strength rather than "MUST" strength, to reflect concerns expressed previously. Added text to explain why TURN is a good thing to implement for address allocation. Noted that other allocation protocol can be used.

    - Clarified that username and password are different for each transport address.

    - Discussed the misrouting scenario raised by Pete Cordell, where STUN keep-alives can be sent to a third party that isn't expecting them. This is a fundamental issue with the non-uniqueness of IP addresses across NAT-realms, not something that can be solved in ICE.

    - Removed mid-session checks. STUN now runs until a media packet is received, then you revert to sending only media packets (and using media-specific means, rather than STUN, as a keep-alive). Enforces a clear separation between the STUN server and the media tool. Added a section on application-layer keep-alives.

    - Add discussion on how to choose a default address.

    - Now use one local transport address for each usable address. This gives a one-to-one mapping between the local address/port pair and the address that goes in SDP, simplifying the protocol and fixing some bugs, but at the cost of opening more sockets.

    - Rewrote the description of re-invite handling. Cullen Jennings noted an issue with this, since reverting to an old address can fail if the NAT binding for that address has timed out. There may be a need to redo the negotiation with a new username and password.

    - TURN has been promoted to a normative reference, however Cullen Jennings is worried that TURN is late and a normative reference may delay ICE. It was agreed to revert this to a reference to "some media relay protocol" using TURN as an example of a protocol with the required properties, to avoid this potential delay. Considerable discussion ensued, covering a number of these issues.

    - Made RTCP information optional in SDP, since many devices don't implement RTCP. Magnus Westerlund suggested it is necessary to set the RTCP bandwidth parameter to zero, in addition to avoiding the ICE check, to inform the other end-point that RTCP isn't used. Jonathan agreed that setting the RTCP bandwidth to zero would be a good thing, but that implementations didn't do it. Rohan Mahy noted that we can say "if you don't do RTCP, you MUST do this with the signalling". After much discussion, the consensus seemed to be to make inclusion of the RTCP address/port optional, but mandate that implementations MUST include a "b=" field of zero if RTCP is not used.

    - Rewrote the security and IANA considerations, and made a number of editorial fixes.

    There are a number of open issues relating to mid-session checks, use of STUN vs. STUN-over-RTP, forcing symmetry, and local-to-derived mapping.

    Mid-session STUN checks serve the purpose of keeping alive NAT bindings, detecting interface and NAT failures, and probing for bandwidth. If they are included, we need to specify frequency of transmission, a definition of failure and protection against flapping. There are two choices for a mid-session keepalive: STUN based and application based. STUN based mid- session checks have the advantage of being codec/transport independent, but require applications to demultiplex STUN and media data, make it hard to specify timers and only provide a partial failure detection/recovery solution. Application based mid-session checks provide a clean handoff between STUN and the media, separating problems and limiting the scope of ICE, and move timers and failure detection to the application.

    Jonathan proposed to keep with the solution in the current, with STUN being used for the initial keepalive check, and application specific solutions being used after the initial check. He noted that his slide saying "Recommentation: keep stun keepalives" is wrong. Joerg Ott and Dave Oran agreed with Jonathan.

    The next open issue was the use of STUN vs. STUN-over-RTP for initial connectivity checks (i.e. the 1st RTP packet's payload data is a STUN packet). The disadvantages of using STUN over RTP are that it's ugly, the request/response nature of STUN isn't well matched with RTP semantics, the RTP timestamp would jump since the STUN packets aren't really media, it doesn't work with SRTP, and it makes ICE specific to RTP. The only advantage is that is avoids a STUN/RTP demultiplex -- although that comes at the cost of embedding STUN into RTP. Dave Oran agreed with all these, provided this is done for RTCP. For RTCP, the issues are not as bad since RTCP APP packets can be used. Magnus Westerlund noted that there are other protocols and making ICE RTP specific is a mistake. The consensus of the room was that STUN-over-RTP is a mistake, especially since we now have a clean handoff between STUN and the media.

    Regarding forced symmetry, the problem is that the current algorithm can result in you sending on a different port than that on which you receive media. This doesn't work if one is depending on application-level keep alives. The suggested fix is MUST send on the port on which you last received a valid RTP packet. Magnus Westerlund noted that there's a potential for flapping, but Jonathan countered that the protocol will settle to a stable state, and there are further rules to ensure one SHOULD use the highest priority address on which you got a STUN request.

    Regarding local to derived mapping, previous versions of the draft allowed a single socket to be used for it's local address, and as a source of STUN and TURN requests used to determine derived addresses. This caused confusion with username-to-address mapping for the STUN and TURN requests, made it hard to determine when to stop the STUN server, and made it difficult to assess which address was used. The latest version of the draft uses distinct ports for the local address, and to run STUN and TURN to derive addresses. This avoids all the multiplexing issues, but at the expense of additional local port usage. Jonathan is worried about the port footprint, and is considering going back to the multiplexing solution (one local address for each derived address), and defining appropriate timeouts for each protocol. Rohan Mahy noted that the folks that have port issues will likely be those who have problem multiplexing, so this may not solve the problem. Dan Wing suggested that the problem is that we're lacking a message to say "STUN packet received" so why not create a stun message to say exactly that? Jonathan considered that, but thought that while it helps you turn off the STUN listener, it doesn't solve the demultiplexing issues. Cullen Jennings asked why we can't do both? The choice of one-to-one or many-to-one mappings between local and derived addresses is a local implementation choice, and which doesn't affect remote clients. Why not document the issue, and let the implementor choose? Jonathan agreed that this is a good way forward.

    Magnus Westerlund noted that ICE could generate a lot of packets, and may cause congestion. It may be better to have some initial delay and to send messages in priority order. Jonathan agreed that this could reduce the amount of data sent, but increased the post-dial delay (which is a hard requirment for some applications). Joerg Ott noted that it's unlikely there are many addresses, so this may not be such a problem: maybe just add a warning note? Jonathan agreed that a discussion of the issue would be appropriate.

    Magnus also worried about switching media between different addresses; we should highlight the potential congestion control issue when changing connection addresses.

    Jonathan committed to revising draft immediately after the meeting, to aim for working group last call before Christmas.

    Internet Media Guides

    Yuji Nomura discussed Internet Media Guides. The IMG requirements and framework are with the IESG for review, so it is now time to identify the specific protocol components that need to be developed. The main items are an IMG transfer envelope, a multicast delivery method, and a subscribe/notify delivery method.

    The groundwork for the unicast subscribe/notify mechanism is defined in draft-nomura-mmusic-img-notify-00.txt. Yuji noted that using HTTP doesn't meet the requirements, so the working assumption is that SIP events will be used for subscribe/notify, and there is a need to define an event package for IMG. Multicast delivery will be via FLUTE: an intial draft defining this has previously been submitted, and will be updated shortly.

    In addition to the transport protocols, and envelope is needed for the data. An initial proposal (draft-walsh-mmusic-img-envelope-01.txt) exists for this and provide a common minimal set of information to manage transfer of IMG data, independent of the transport protocol. The working assumption here is to use an XML format.

    Open issues include the need to define an IMG URI (e.g. img://...) and naming IMG data for encapsulation ("application/envelope+xml"?). It will also be necessary to define versioning and delta descriptions for the IMG data, to support partial transmission.

    Henning Schulzrinne asked if the IMG URI is intended to identify the content or the transport, and wondered how it should be used? There was some confusion on this point, and it isn't clear how to translate from the URI to the retrieval mechanism. Clarifiation is needed.

    Application Sharing

    Henning Schulzrinne discussed draft-schulzrinne-mmusic-sharing-00.txt on requirements for application sharing. This is speculative new work, and it's not clear if it belongs in MMUSIC. Our conferencing architecture is deficient in support for shared applications, and Henning has considered how this can be resolved without reinventing T.120. The presentation and draft outline the problem space and the requirements.

    Rohan Mahy expressed concern that the scope being addressed here is significantly larger than he had imagined. We may want to solve the problem for named categories of application, splitting the problem space rather than "trying to boil the ocean". Dave Oran, Jonathan Rosenberg and Roni Even and also expressed similar concern regarding the scope of the work, compatibility with other systems, the form of the data to be shared, etc. Henning noted that he's raising possible requirements, not suggesting that we'll solve them all immediately. Steve Casner noted that we already have limited RTP payload formats for pointers and text events, which may feed into this work.

    Joerg Ott concluded by noted that this is an intersting problem, and noted that while the negotiation of application sharing sessions is clearly in scope for MMUSIC, the application sharing protocol itself isn't. There doesn't seem to be a natural home for this work in the IETF, although we can think about it here for now.

    SDP

    Colin Perkins outlined the changes to draft-ietf-mmusic-sdp-new-21.txt since the last meeting (see slides for details). There are open issues regarding support for internationalized DNS, layered coding, direction attributes and the placement of the spec in context. Internationalized DNS names did not exist when the original SDP was written, so the draft doesn't indicate how they should be represented. Advice was solicited from the working group and Bernie Hoeneisen gave the suggestion that internationalized DNS names should be conveyed in the ASCII Compatible Encoding (ACE) form defined in RFC 3490, rather than in UTF-8 or some other encoding. This requires no changes to SDP, other than to note that this form should be used.

    Regarding layered coding, the issues are that allocation of consecutive multicast addresses is problematic, and that the "a=rtcp:" attribute is not fully specified for layered encoding. Colin suggested that, since this part of the spec is not widely implemented, it should be left as-is for now, and updated if layered multicast transport becomes popular. No comments were received.

    There was a suggestion that interactions between the direction attributes ("a=recvonly", etc.) and the offer/answer spec should be documented, and offer/answer referenced. More generally, is there need to include more context on how SDP is used with, for example, SIP? Jonathan Rosenberg and Keith Drage suggested that these interactions are defined in other drafts, so there's no need to add anything to the SDP spec.

    SDP Extension for Media Loopback

    Kaynam Hedayat discussed draft-hedayat-media-loopback-01.txt. The goal of this draft is to enable SIP endpoint to initiate calls with media loopback. It introduces two SDP media attributes, giving the type and mode of the loopback and is based on the offer/answer model.

    Colin Perkins and Dave Oran were uncomfortable with the requirement that endpoints MUST support RTCP-XR, and suggested that support for RTCP-XR be OPTIONAL. The loopback attribute is more general than voice over IP applications, so there is no way a particular subset of RTCP-XR support can be mandated.

    Magnus Westerlund expressed concern that the security aspects of this new attribute haven't been fully considered, and that it may introduce potential packet bombing attacks. This issue needs to be documented.

    The consensus of the room was that this a good idea, and should be adopted as an MMUSIC work item.

    SDP Extension for BFCP

    Gonzalo Camarillo presented (draft-camarillo-mmusic-sdp-bfcp-00.txt) on the SDP extensions needed to support the XCON binary floor control protocol. BFCP is defined under the "application/bfcp" media type and runs over TCP. It fits into SDP as a transport protocol with connection establishment is handled by the comedia framework. The "k=" line can be used to convey the shared secret needed by BFCP, and attributes are defined to convey the confid and userid. Mapping between floor IDs and streams can be done using the SDP label attribute. There is an open issue regarding the need for a nonce attribute, which will be discussed in XCON.

    The consensus of the room was to accept this as an MMUSIC work item.

    SDP Label Attribute

    Gonzalo Camarillo presented (draft-ietf-mmusic-sdp-media-label-00.txt) on the SDP label attribute. The main issue at the last meeting was why label media streams, rather than referring to the n'th media stream. It has been clarified that this is so static documents can be created that refer to specific media streams within future SDP files, without having to revise those static documents if the type or order of the media in those future sessions changes.

    The authors asked for the draft to go to working group last call. Colin Perkins raised an issue that the label is defined as "any octet string" but needs to be restricted to octet strings that can be represented in SDP (i.e. printable ASCII). The working group last call will be issued after the meeting, with this comment being fixed as an editorial clarification after the last call.

    SDP Connection Establishment Precondition

    Gonzalo Camarillo presented (draft-ietf-mmusic-connection-precon-00.txt) on SDP connection establishment preconditions, briefly noting that the SIP working group is performing an expert review of the draft.

    SDP Security Precondition

    Flemming Andreasen gave an overview of the SDP security precondition draft (draft-andreasen-mmusic-securityprecondition-02.txt). The problem that it solves is when an offer includes several security descriptions from which the answerer picks one and sends secure media. The media can start to arrive before the answer, but cannot be be decoded since the offerer doesn't know which security parameters were chosen. Hence a new precondition is defined to delay completion of the call until all parties have agred on the security parameters.

    Changes in this version are to clarify the definition of "send" and "recv" security preconditions, add more detail in the example flow, and add security considerations. This is needed by SIP, and there are no known open issues.

    Colin Perkins asked that an example be included using the kgmnt-ext form of SDP signalling, in addition to the sdescriptions examples, but otherwise agreed that the draft was in good shape. The authors were requested to make this change, and submit the draft as a working group draft, then a working group last call could start.

    SDP Connectivity Precondition

    Flemming Andreasen also presented the SDP connectivity preconditions (draft-andreasen-mmusic-connectivityprecondition-01.txt). This draft defines a precondition to ensure there is media stream connectivity between offerer and answerer prior to proceeding with session establishement. It doesn't mandate a particular mechanism to verify connectivity.

    Changes in this version are to clarify the definition of "send" and "recv" preconditions, add more detail in the example flow, and add security considerations. Open issues include adding an explanation of the relationship between this and ICE, and explaining how it will interact with SIP forking.

    Colin Perkins asked that this draft be clearer on the difference between it and the connection precondition, in particular to be careful about the precondition names (i.e. "con" vs. "conn"). Paul Kyzivat noted that we have many preconditions, and worried about use cases and feature interaction. It may be appropriate to consider documenting possible interactions? Henning Schulzrinne raised a general concern that the precondition framework may be covered by IPR?

    It was agreed that this draft should become an MMUSIC work item.

    -- + --




    Slides

    Agenda
    ICE
    Internet Media Guides
    SDP
    SDP Media Loopback
    SDP Format for BFCP Streams
    SDP Media Label
    Connection-Establishment Preconditions
    Security Preconditions for SDP Media Stream
    Connectivity Preconditions for SDP Media Stream