Opening HTTP channels
Pete Cordell
pete at TECH-KNOW-WARE.COM
Wed Jul 28 12:06:22 EDT 1999
Chip,
A quick question,...
With your encoding is there a convenient way to find parameters after the
SDP without parsing the entire SDP message? Similarly, what rule do you use
to decide whether you are starting to parse a new SDP message? Do you look
for a new v=0 line, or is there an empty line? Or are these sorts of
details not relevant at this time?
Pete
=============================================
Pete Cordell
pete at tech-know-ware.com
=============================================
-----Original Message-----
From: Chip Sharp <chsharp at CISCO.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: 28 July 1999 05:23
Subject: APC-1630 ("SDP Encoding for H.248") uploaded/enclosed
>I have uploaded APC-1630 for potential consideration at the upcoming
>rapporteur's meeting. It is also enclosed below.
>
>Warning: This contribution is text encoded. ;-)
>Chip
>
>------------------------------------------------------------------
>| |
>| ITU Telecommunication Standardization Sector Document APC- 1630 |
>| Study Group 16 |
>| Q.12-14/16 Rapporteur Meeting 27 August, 1999|
>| Berlin, 2-6 August 1999 |
>| |
>| SOURCE*: Cisco Systems, Inc. |
>| TITLE : SDP Encoding for H.248 |
>| PURPOSE: Proposal |
>| |
>| _________________________ |
>| |
>| |
>| |
>| *Contact: Chip Sharp, chsharp at cisco.com |
> ------------------------------------------------------------------
>
>Abstract:
>The use of SDP encoding has been proposed for H.248. This
>contribution proposes the following:
>
>1) The SDP encoding that has been proposed since the March
>compromise should be maintained at least as an option.
>
>2) The encodedparameter should refer to RFC2327 for the SDP encoding.
>
>3) The package names and event names should be text encoded and
>registered with IANA for extensibility.
>
>4) An IANA considerations section needs to be added to provide
>guidelines for registering with IANA.
>
>
>Session Description Protocol:
>---------------------------
>The Session Description Protocol (SDP) is described in RFC2327
>(ftp://nis.nsf.net/internet/documents/rfc/rfc2327.txt). It is a
>standards-track protocol in the IETF. Refer to the current edition of
>the "Internet Official Protocol Standards" (STD 1,
>ftp://ftp.isi.edu/in-notes/std/std1.txt) for the standardization state
>and status of this protocol.
>
>From the abstract of RFC2327:
> "SDP is intended for describing multimedia sessions for the
> purposes of session announcement, session invitation, and
> other forms of multimedia session initiation."
>
>SDP Proposal:
>------------
>
>The encodedDescriptor should maintain the option for SDP encoding.
>
>The encodedDescriptor production should be changed to:
>
>encodedDescriptor = (SDPToken COMMA *SDPinformation) |
> (H245Token COMMA quotedOctetString ) |
> (extensionParameter COMMA quotedOctetString )
>
>Add the following production:
>
>SDPinformation = announcement ;Normative: <announcement> is
> ;defined in Appendix A of RFC2327
>
>In addition, an extension mechanism should be defined. It is
>recommended that a similar mechanism to that defined in
>http://search.ietf.org/internet-drafts/draft-huitema-megaco-mgcp-v1-
>00.txt be used.
>
>
>Package and Event Proposal:
>--------------------------
>Various Packages are currently being defined for H.248. It is
>expected that a certain number of packages will be included in the
>base standard. However, it is also expected that more packages will
>need to be defined as more applications are defined.
>
>This contribution recommends that the package names and event names be
>text acronyms that are registered with IANA. This will allow new
>packages and events to be added in an extensible manner.
>
>This mechanism is already used for many applications on the Internet.
>For example, MIME types are registered with IANA. This practice
>allows extensions to the base capabilities without having to rev the
>base specification every time a new capability is added.
>
>The ITU in general and SG16 in particular already have established
>precedence in using IANA registration in ITU Recommendations. This is
>a well-established practice in SG16. All the TCP/UDP ports used in
>the H.323 series recommendations are registered with IANA. Therefore,
>there should be no procedural problem with using IANA registration.
>
>The following text should be added:
>
>In Section 7.2.2.6 Packages, add the following sentence:
>"Package names, referred to in this document as PackageName, will be
>registered with IANA."
>
>The following changes should be made to the packageName and
>eventParameterName productions:
>
>packageName = NAME ;Normative - The values this production takes are
> ; registered with IANA as defined in Section ???
>
>
>eventParameterName = NAME ;Normative - The values this production takes
are
> ; registered with IANA as defined in Section ???
>
>
>
>A Section should be added defining the guidelines for registering events
and
>packages with IANA.
>
>For example, the following text could be used (taken from SIP):
>" When registering a new SIP option, the following information MUST be
> provided:
>
> o Name and description of option. The name MAY be of any length,
> but SHOULD be no more than twenty characters long. The name
> MUST consist of alphanum (See Figure 3) characters only;
>
> o Indication of who has change control over the option (for
> example, IETF, ISO, ITU-T, other international standardization
> bodies, a consortium or a particular company or group of
> companies);
>
> o A reference to a further description, if available, for
> example (in order of preference) an RFC, a published paper, a
> patent filing, a technical report, documented source code or a
> computer manual;
>
> o Contact information (postal and email address);
>
>This procedure has been borrowed from RTSP [4] and the RTP
> AVP [26]."
>
>However, this is not sufficient. Guidelines similar to those defined in
>RFC2327 should be developed.
>
>
>CONCLUSION
>----------
>
>In conclusion:
>1) The SDP encoding that has been proposed since the March
>compromise should be maintained at least as an option.
>
>2) The encodedparameter should refer to RFC2327 for the SDP encoding.
>
>3) The package names and event names should be text encoded and
>registered with IANA for extensibility.
>
>4) An IANA considerations section needs to be added to provide
>guidelines for registering with IANA.
>
>
>
>--------------------------------------------------
>Chip Sharp Consulting Engineering
>Cisco Systems Telco Bio-region
>Reality - Love it or Leave it.
>--------------------------------------------------
>
More information about the sg16-avd
mailing list