At 04:20 PM 7/28/99 +0100, Pete Cordell wrote:
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?
First question: I believe that there are going to be brackets around the encodedDescriptor that could be used to skip over the SDP. Why would an application want to skip the SDP?
If you want to skip a session description within an encodedDescriptor RFC2327 says: When SDP is conveyed by other means, many SDP session descriptions may be concatenated together (the `v=' line indicating the start of a session description terminates the previous description).
For example, below is an add command with the local descriptor shown. The session descriptions for the Local Descriptor are bounded by brackets. You could skip to the right bracket if you don't want to parse the local descriptor session descriptions.
add = TID { ... , L = streamID { SDP , SDPDescription } , ... }
If this is done right you should be able to skip to "} ," to get to the next parameter.
Right now I can't come up with an example in which there are multiple session descriptions for a Local or Remote Descriptor. Perhaps someone else can.
Also, I believe there was a discussion at some point about using IANA-registered MIME types for the encodedDescriptor. I meant to include that in my contribution but forgot. In this case the above would look like: add = TID { ... , L = streamID { application/sdp , SDPDescription } , ... } or add = TID { ... , L = streamID { application/h245, h245Description } , ... }
In this case, the encoding would be defined by the registered MIME type.
Chip
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.
...snip... -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------