Subject: Summary of SDP changes suggested in Danvers

From: Mark Handley <[email-masked]>
Date: Wed, 03 May 95 12:47:11 +0100

I had intended to get a new SDP draft out by now, but I've been a
little delayed - hopefully I'll get it done next week.  In the
meantime, Ruth encouraged me to send out my rough notes from the
meeting.  These are what I typed up on the plane on the way back, not
necessarily what will go into the draft.  

In the meantime, I've been porting sdr (my sd client) to SDPv2 and
started to realise how difficult writing a friendly GUI to the repeat
time fields is :-) Any suggestions are welcome!

Mark

--------

Changes and Omissions from draft-ietf-mmusic-sdp-00

- Need to clarify when two announcements refer to the same session.

- Ross Finlayson raised the issue of hierarchical announcements - sdp
announcements that announce/reference sets of other sdp announcements.

- The issue of having a hierarchical category field was also raised to
aid finding a session.

- It was suggested that either an email or a phone field should be
compulsory.

- It was suggested that email and phone fields should be able to
contain an additional text string (primarily to give the contact's
name).

- the draft should probably state a maximum length for i= fields and
possibly a maximum length for an announcement.

- we should probably state that an sdp client should be prepared to
listen on several multicast addresses simultaneously, rather than the
single well known address.  This is so we can take advantage of
administrative scoping by multicast "subnet" to scope announcements.

- ***Given the inconsistency of start and stop times, we should
probably not care about SDPv2 being a superset of SDPv1.  This allows
most of the possible changes below...***

- we should probably split the current c= field.  This is because we
use c fields to override the conference address and ttl and the start
and stop times are then not relevant.

  - the address and ttl should stay in the c= field
  - the start and stop times should move to the t= field.

- the t= field as currently described cannot cope with changes from
standard to daylight saving time properly.  The proposal is for the
following format (omitting spaces here for brevity):

  tfield ::= start-time stop-time [mins hrs dom mon dow duration corrections]
  corrections ::= "" | compensation c-start [corrections]

compensation is the offset from the times in the repeat interval in
hours (should this be seconds?).  c-start is the NTP start time for
the correction in seconds.

This is pretty ugly, but so far we haven't found anything better.

- If b= fields are to be used to set the slider on the media tool,
then they should be allowed in the media descriptions.  Currently
they're not.

- There was some discussion about whether b= fields as currently
defined apply per source or per conference.  We probably want per
source in the media fields and per conference in the session header.
Doing this without a modifier is overloading the default syntax of the
b= field.

To get arround this, we propose that the syntax of b fields should be:

b=modifier bandwidth-value (bandwidth-value)*

Ie, the modifier is compulsory and multiple bandwidth values can potentially
be supplied for certain modifiers as yet undefined.

Two modifiers are now suggested:

"AS" - application specific.  This is to be used in the media
descriptions along with a single bandwidth-value, which is the
applications peak bandwidth (however the application defines that).

By itself, this doesn't give enough data to figure how much bandwidth
a conference will use as the number of sources is unknown.

The other modifier is:

"CT" - conference total.  This is the sum of the AS fields for each
media times the number of expected simultaneous sources.  It should
only be given when the conference is significantly different in it's
bandwidth usage form the recommended figures in the Mbone FAQ.

- m= field.  The id is now obsolete for most purposes.  We remove it
form the media field.  It it is required by vat, we then use an "id"
attribute field until such time as vat uses RTP.

- no default format is or should be defined for a media.  Thus using
the fmt attribute for media format is wasteful.  We add the format to
the m= field.  Format can either be a single format or the name of a
format group.  (Format groups need defining...)  If two or more formats
are likely and there is no appropriate format group, alternative
formats can be defined using a fmt attribute?  (Is this preferable to
allowing lists on the fmt line?)

Format fields take one of two forms:

 - an RTP AVT profile name.
 - an application specific name for none-RTP applications.

Clearly there should be a mechanism for defining application specific
formats.  For experimentation, the "x-" notation should be used for
none-RTP applications.  The vat formats should probably be used as
"x-pcm2", etc, until vat moves to using RTP.

Using RTP AVT profile names means we don't have any way to specify
packetisation (the number of samples encoded in a packet) for audio
coding schemes.  The RTP AVT profile states that the default
packetisation is on 20ms unless the encoding scheme states otherwise.
If the default packetisation is used for a particular encoding scheme,
no attribute is required.  If a none-default packetisation scheme is
used, the attribute a=pt:<packetisation time> is used, where
packetisation time is in ms.

- The draft states in a number of places "UDP port".  This should be
replaced where appropriate with "transport port".

- The draft should state more clearly it's assumptions about transport
protocols.  Something along the following lines: "RTP applications by
default are RTP in UDP in IP.  For example, if we have a format of
"pcmu" then this is PCM u-law audio in RTP in UDP in IP.  For none RTP
applications, this is dependant on the format concerned.  SDP
descriptions may contain media that are not carried in IP."

- There is much overlap between o=, h= and e= fields.  We should
consider merging the o= and h= fields (o=username@ip-address), and
dropping the binary representation of the IP address from the sd
packet header.  This aids transition to IP6 when necessary.