Subject: RE: [MMUSIC] Protocol Action: 'SDP: Session Description Protocol' -resolution declaration for video stream

From: "Even, Roni" <[email-masked]>
Date: Mon, 27 Mar 2006 08:42:58 +0200

Osher,

The resolution of the video stream is not in the SDP but in the payload
specification. The reason is that the resolution specification is codec
dependent. H.261 supports only QCIF and CIF while H.264 does not have a
pure resolution definition.
Look in AVT at the updated specification for H.261 and H.263

Roni Even

> -----Original Message-----
> From: Osher Hmelnizky [mailto:[email-masked]]
> Sent: Sunday, March 26, 2006 5:56 PM
> Cc: Yuval Nissan; mmusic mailing list; Oren Kudovitzky
> Subject: RE: [MMUSIC] Protocol Action: 'SDP: Session Description
Protocol'
> -resolution declaration for video stream
> 
> Hi, I'm looking for the resolution declaration for video stream in
SDP.
> 
> I didn't find anything standard for declaration of video resolution -
> like "CIF", "QCIF",...
> 
> SHALL be it a part of the "a=fmtp" line of SDP?
> 
> Is it any other standard option exists?
> 
> Best regards
> 
> Osher
> 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of The IESG
> Sent: Wednesday, February 15, 2006 12:06 AM
> To: IETF-Announce
> Cc: mmusic chair; Internet Architecture Board; mmusic mailing list;
> mmusic chair; RFC Editor
> Subject: [MMUSIC] Protocol Action: 'SDP: Session Description Protocol'
> to Proposed Standard
> 
> The IESG has approved the following document:
> 
> - 'SDP: Session Description Protocol '
>    <draft-ietf-mmusic-sdp-new-26.txt> as a Proposed Standard
> 
> This document is the product of the Multiparty Multimedia Session
> Control
> Working Group.
> 
> The IESG contact person is Jon Peterson.
> 
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-26.txt
> 
> Technical Summary
> 
> This memo defines the Session Description Protocol (SDP). SDP is
> intended
> for describing multimedia sessions for the purposes of session
> announcement,
> session invitation, and other forms of multimedia session initiation.
> 
> In particular, this document provides a new version of SDP that
> incorporates
> fixes and extensions that have been designed in the MMUSIC WG since
the
> publication of the original SDP specification, RFC2327. This document
is
> not
> SDPng, which fundamentally re-examines the problem space of SDP and
> arrives
> at a new solution. Rather, this document collects increment fixes to
SDP
> that are critical to its proper operation, and merit inclusion in the
> core
> standard.
> 
> Working Group Summary
> 
> The MMUSIC working group supported publication of this document.
> 
> Protocol Quality
> 
> This document was reviewed by Allison Mankin and Jon Peterson.
> 
> RFC-Editor Note
> 
> Please append to the start of Section 9:
> 
> OLD:
> 
> 9.  SDP Grammar
> 
> NEW:
> 
> 9.  SDP Grammar
> 
>    This section provides a grammar for SDP.  It uses a variant of
>    ABNF [4].  In this variant, contrary to section 2.3 of [4], strings
>    are *not* case-insensitive, and must match exactly the case
> specified.
> 
> Security Considerations, last paragraph:
> 
> OLD:
> 
>    Use of the "k=" field poses a significant security risk, since it
>    conveys session encryption keys in the clear.  SDP MUST NOT be used
>    to convey key material, unless it can be guaranteed that the
channel
>    over which the SDP is delivered is both private and authenticated.
> 
> NEW:
> 
>    Use of the "k=" field poses a significant security risk, since it
>    conveys session encryption keys in the clear.  SDP MUST NOT be used
>    to convey key material, unless it can be guaranteed that the
channel
>    over which the SDP is delivered is both private and authenticated.
>    Moreover, the k= line provides no way to indicate or negotiate
>    cryptographic key algorithms, and as it provides for only a single
>    symmetric key, rather than separate keys for confidentiality and
>    integrity, its utility is severely limited. Use of the k= line is
>    NOT RECOMMENDED, and any usage of the k= line MUST address these
>    shortcomings.
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic