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@tech-know-ware.com =============================================
-----Original Message----- From: Chip Sharp chsharp@CISCO.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@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@cisco.com |
Abstract: The use of SDP encoding has been proposed for H.248. This contribution proposes the following:
- The SDP encoding that has been proposed since the March
compromise should be maintained at least as an option.
The encodedparameter should refer to RFC2327 for the SDP encoding.
The package names and event names should be text encoded and
registered with IANA for extensibility.
- 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:
- The SDP encoding that has been proposed since the March
compromise should be maintained at least as an option.
The encodedparameter should refer to RFC2327 for the SDP encoding.
The package names and event names should be text encoded and
registered with IANA for extensibility.
- 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.