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