APC-1630 ("SDP Encoding for H.248") uploaded/enclosed

Chip Sharp chsharp at CISCO.COM
Tue Jul 27 23:45:50 EDT 1999


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