Subject: Session Description Protocol draft available.

From: Mark Handley <[email-masked]>
Date: Mon, 27 Mar 95 19:56:55 +0100

The Session Description Protocol (sd protocol) draft that we talked
about at the San Jose IETF was submitted to the Internet Drafts editor
on Friday.  I haven't heard anything back yet, so this draft is not
yet in the internet-drafts directories, but it is available from our
WWW server.

The temporary URL's are:

http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.txt
and
http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.ps

For those of you that proofread early drafts - many thanks - this version
probably contains quite a number of changes from the versions you've seen.

Comments are of course welcome, but I hope we'll have time to discuss
this properly in the WG meeting in Danvers.

Mark

---

From: Tsokkinen Mikko <[email-masked]>
Date: Wed, 29 Mar 1995 15:30:40 +0300

> this properly in the WG meeting in Danvers.

I read the draft and have some comments.

First I am glad that this kind of draft is finally released, makes it
much easier to understand how sd works, however this draft is does not
contain enough information about how to make session tool (e.g.
address allocation algorithm is missing).

I have some suggestions/questions for consideration:

I suggest changes that would make it possible to have any number of
complex media descriptions inside a session. SDP-tool could be used to
announce besides some conferencing addresses, other resources e.g.
urls as well.

Also the SDP-tool could be constructed in a way that each media 
description can be "opened" independently so that user could
select e.g. between high-bandwidth video vs. low bandwidth or
audio in different langages, fetch some IETF drafts using
ftp URL or see relevant pages using WWW URL.

These suggestions only give ideas about what I mean, they are not
meant to read literally.

Session description

- Remove URL, I suggest URL mediatype, see later

Media description

- Change description so that it contains either u=url or m=media name/transport
  control
  (this would mean that any number of internet resources (URLs) could
   be announced, not just tool parameters.)
- Add format type into m-field
  (This will be reuired in any case for practical tools to work.)
- Add optional information field
  (This would mean that one session could contain e.g. the audio
   media descriptions, e.g. audio in English and in Finnish, and
   each have different comment field.)
- Add optional bandwidth info field
  (This could used by the user too see which mediatypes to "open".)

Here is an example how this suggested system could look like:

s=IETF Meeting
i=AVT group meeting in Denver
o=[email-masked]
c=224.2.42.42/4 127 11111111111 222222222222
u=http://www.mbone.net/avt/
i=Background information
u=ftp://nic.nordu.net/drafts
i=Relevant IETF drafts
m=audio 3456 0 gsm
i=International audio in Esperanto
b=17kbps
m=audio 3457 0 pcm
i=USA audio in English
b=78kbps
m=video 2232 0 h261
b=64kbps
a=size:QCIF
m=whiteboard 4242 0 wb
a=orient:portrait

Would do you think?

Mikko I. Tsokkinen xxxxx Mit                           <[email-masked]>
R & D Engineer
Telecom Finland Ltd./Telegate/Medialaboratory
"The universal language of the Net will be spoken 53 bytes at a time."
 - S.G.Steinberg

---

From: Mark Handley <[email-masked]>
Date: Thu, 30 Mar 95 16:50:53 +0100

>address allocation algorithm is missing).

This is not meant to be a description of sd, just of sdp. Informed
Partitioned Random Address allocation was described at Sigcomm 94.
However, a precise description does not exist to my knowledge.

>Mikko I. Tsokkinen xxxxx Mit                           <[email-masked]

I'll deal with your points one at a time:

- Allowing multiple URL fields

  Why is this necessary?  Links from the first URL can do all you want.
  Henning suggesting it should be a URI rather than a URL and of course
  he's correct.

- Using URLs for media tool descriptions.  eg: audio://224.2.0.1:3456/pcm

  (maybe this wasn't what you meant, but it's an extension of the above)

  This is possible, but personally I believe it's overloading the URL
  syntax somewhat and doesn't shorten the description significantly.

  If you're wondering about using such URLs in WWW documents at a later 
  stage - again we've looked at this, but defining a URL syntax makes
  adding functionality later tricky, and also makes it difficult to
  start media tools with the necessary inter-tool associations for
  conference control, lip synchronisation and so forth.  
  We're recommending the use of a content-type application/x-sd and 
  returning an sdp decription for such usage.

- Adding the media format to the media field.

  This would be possible, but I believe is undesirable.  There's still
  some debate about the use of the a=fmt:* attribute, and no-one
  really believes we'll definitely get this right in the first pass
  (there are interesting new formats being developed that may require
  more information than just a single format entry).  Having it as an
  attribute allows more scope for experimentation.

- Allowing b= fields per media

  I have no great problem with this, and it was in the talk I gave at the
  last IETF.  Van is reluctant to get into bandwidth definitions 
  though, and I can understand why.  I don't believe b= fields
  are relevant with many of the existing audio formats as they're fixed 
  (and known) bandwidth anyway.  It may be relevant for new audio formats
  or for video formats, but there's definitely a problem here getting
  unskilled users to give some sensible figure.  I'd rather have no figure
  than have it wrong often.

- Allowing i= fields per media

  If you only have one media of a particular type, this shouldn't be
  necessary.  If you have more than one video or audio stream, I can
  see why this might be needed.  How often is this likely to be the case?
  In most such cases, I believe there should be multiple announcements.

Session descriptions don't want to be too general or the temptation to
put too much information in them is great.  They must be short.  In
general, we've tried to be pretty minimalist in the SDPv2 definition
(though not quite as minimalist as SDPv1).  Descriptive information
has been omitted to the maximum extent possible as it should all be
reachable via the URI.  Information in SDP descriptions is that which
is needed to start your session, sufficient information for scheduling
and minimal contact data for when all else fails.  I believe we should
attempt to keep to this model.
  
Mark