Subject: Idea for sdp

From: Philipp Hoschka <[email-masked]>
Date: Wed, 29 May 1996 17:55:32 +0200

I jotted this on a piece of paper that I finally want to throw
away: is it possible in sdp to transmit a URL that points to a place 
where the binaries for decoding software for a stream can be fetched ?
This info could be given at least for the "most popular" platforms.

Given the proliferation of coders/decoders, and
the frequency with which information on the tool required for 
decoding a stream turns up in the "information" field in recent
announcements in sdr, it might be worthwhile to have a more
formal field for this functionality. This might be extended to also 
allow automatic downloading of the decoder, written e.g. in Java 
(no, I didn't say that :-)). Plus it would spare people to
write and update html pages with titles like "where to get MBone tools
for XXX"

-Philipp Hoschka

----------------------------------------------------------------------
   Philipp Hoschka
   WWW: http://www.inria.fr/rodeo/personnel/hoschka/hoschka.html 
				|   INRIA - WWW Consortium
   [email-masked]      |   2004, Route des Lucioles, BP 93
   Tel:(+33) 93 65 79 84        |   06902 Sophia Antipolis Cedex
   Fax:(+33) 93 65 77 65        |   France
----------------------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 May 1996 19:35:15 +0200

> where the binaries for decoding software for a stream can be fetched ?

Can you say "implosion"?

I'd rather multicast those tools...

Gruesse, Carsten

---

From: Philipp Hoschka <[email-masked]>
Date: Wed, 29 May 1996 19:46:34 +0200

>> where the binaries for decoding software for a stream can be fetched ?

I guess you mean that all people will go to the same server to get 
the binary when decoding the stream, and the server goes to its knees ?

So, if you don't put the URL into the announcement, there will be no
implosion, because people will not get the binary, since they don't
know where to find it ? :-)

Seriously, I don't think implosion is a problem that would be newly
introduced by this proposal - people have to get the tools anyway from
one or more servers, and they have to get the info where to find the
tools somewhere. And if the tool is already installed, there is of
course no need to get it again.

>I'd rather multicast those tools...

Sure, multicast everthing ... however, I'd rather use MBone bandwidth
for audio/video, at least at this point in time. And to get new MBone
users to install decoding tools.

-Philipp

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 May 1996 19:58:29 +0200

> introduced by this proposal

It will be amplified -- people will write conference management
(session control) tools that offer a GUI button "fetch tool", and
(other) people will press that button.

Until we have unique IDs on software releases,

> users to install decoding tools.

2 minutes at 64 kbit/s is a megabyte already.  I don't see a big
problem with multicasting the appropriate tools ahead of an event.
It would be easy to build tools to cache/prune those, *if* we manage
to think a minute about unique IDs (hash sums, whatever).

(Why am I saying all this?  We are ramping up our experimental netnews
multicasting right now.  It's easy to underestimate what you can do in
32 kbit/s of continuous bandwidth.  That's 345 MB per day, probably
more than the total size of all Mbone tools known to mankind today.)

Gruesse, Carsten

---

From: Philipp Hoschka <[email-masked]>
Date: Wed, 29 May 1996 20:41:57 +0200

>Until we have unique IDs on software releases,

Well, a URL is quite unique, if you adopt a version numbering system.
In addition, caching is quite popular on the Web today, and could be
used for avoiding multiple downloads as well (i.e. do a conditional
get request when "fetch tool" is pressed).

>problem with multicasting the appropriate tools ahead of an event.

Why ahead ? What about people learning about/joining the transmission 
when it's already running ? You would probably want to multicast the
tool during for the duration of the session, reducing the bandwidth/
quality available for audio/video.

>to think a minute about unique IDs (hash sums, whatever).

A URL ? Plus caching can also solve the "implosion" problem.

>more than the total size of all Mbone tools known to mankind today.)

I agree. But if I have the choice between adding bandwidth for getting 
better audio/video quality for my transmission or transmitting
the decoder, I know where my preference would be. Plus you need
one channel per platform/binary - I count eight different platforms 
for vic and vat at the moment. Assume that you do the whole transmission
out of one location - that puts quite a heavy bandwidth demand at least on 
the links going out from the sender.

Overall, I think downloading the decoders via the Web/ftp is more practical.
The "hot spot" syndrome usually occurs with servers that maintain
pages that change a lot - Shuttle mission. Even though MBone tools
evolve at a rapid pace, I think it is safe to assume that *most*
of the participants already have the latest version of the decoder 
installed, and so no network traffic/implosion would occur. Multicast
might be used if there has been a recent update - it sounds like a 
cool idea, but a bit weird to "ordinary" Internet users.

-Philipp

---

From: Peter Parnes <[email-masked]>
Date: Wed, 29 May 1996 21:26:15 +0200

> This info could be given at least for the "most popular" platforms.

It's a good idea but I don't think SDP the is the right place. 
Wouldn't that be a lot of wasted bandwidth? Although the tools change quite frequently lately they don't change _that_ often and the creator of a session don't always know what the latest version is.  

> formal field for this functionality. 

I really hope the evolution-speed of the tools will slow down soon so this "extra" information included in the announcements won't be necessary anymore.

> This might be extended to also 
> (no, I didn't say that :-)).

Why not? :-) Well, that might not be so far away!! Is anyone besides working on this? (besides me that is :-) 

> Plus it would spare people to

:-) 

As I said before it's a good idea and I'd like to suggest something like the following:
We allocate a special info-multicast-channel where clients can ask what the latest version is and every creator of a tool is responsible to have a server running (either a server on their own site or in collaboration with someone else) that is capable of answering the question. The traffic on this channel could be transmitted using RTP/SRM or some other reliable multicast transport protocol. 
???!!! :-)

/P

---

From: Philipp Hoschka <[email-masked]>
Date: Wed, 29 May 1996 22:14:48 +0200

>It's a good idea but I don't think SDP the is the right place.
Given that it describes a session, and that you need a decoder
for joining the session, why not ?
 
>Wouldn't that be a lot of wasted bandwidth? 

So now I have someone saying "you have the bandwidth, so just
multicast the binary", and another one saying "making the
sdp announcement bigger by adding URLs for the decoder wastes
too much bandwidth". Hmm ... note that the field can be made
optional, so that when you use a tool that "everybody has", just
leave out the information.

Actually, it might make the sdp announcemnt too big (>>512 byte),
leading to IP fragmentation and the related problems. But I'm not
sure that sdp does not already have this problem.

>Although the tools change quite
> frequently lately they don't change _that_ often and the creator of a sessi
>on don't always know what the latest version is. 

Yes, but he knows which tool he uses to encode the sesssion, and thus
the compatible decoder. This might actually be even more correct than
using "the latest version" - which might not work with some older version
that the sender uses. And if the sender doesn't know the latest version, 
how would the even less "MBone experienced" receiver know it ? 
(this is assuming that the MBone will be used for TV/radio like
broadcasts, where a number of "stations" provide content, and
many listeners with low tech knowledge "channel surf").

Plus, the information where to get the binary could be automagically 
added to the announcement when the sender sets up the session ...
requiring a linkage between binary and URL, not sure how to do this in
a practical way -  unless, of course, the binary was downloaded using 
the announcement from a previous session, where the current sender was
the receiver.

>I really hope the evolution-speed of the tools will slow down soon so this 
>"extra" information included in the announcements won't be necessary anymore
>.

Quite in contrast, I hope that the speed will pick up even more :-) -
in particular, better, more Internet-fit video coders are required.
Plus commercial adoption of MBone will almost certainly mean an increase 
in available binaries ...

On the other hand, the effect of giving the URL for the decoder
might lead to more proprietary solution - "the binary is the standard".
But if it gives MBone a boost, and diminishes the number of RealAudio
-unicast downloads, resulting in bandwidth saving - why not ?

>We allocate a special info-multicast-channel where clients can ask what the
>latest version 

Be careful with "latest version" - this might not be the version needed
to decode the stream !

>The traffic on this chan
>nel could be transmitted using RTP/SRM or some other reliable multicast tran
>sport protocol.

Why does it have to be reliable ? To me this sounds like an "announcement
channel" similar to what sdp addresses.

You would have to make the match between the announcement "this is a PCM
stream using the RTP protcol", your machine-type, and the binary-announcement -
yes, that should work, also for an announcment like "this is a RealerAudio
stream using version 2-14.4Kbit/s" - might require some "abuse"
of sd fields, but who cares ? :-)

But the proposal requires the cooperation of the tool authors to set
up these servers - the sender is more interested in having many
listeners, so he will put the info where to get the decoder into
the announcement. The tool author is mostly interested in selling servers -
decoders are free, so less incentive to run announcement servers.

Anyway, I seem to remember that sdp has gone down the IETF standards
track already, so it's probably too late for changes. As I said, 
I just cleaned up my desk :-)

-Philipp

---

From: Mark Handley <[email-masked]>
Date: Wed, 29 May 96 22:48:14 +0100

Peter Parnes writes:

>We allocate a special info-multicast-channel where clients can ask what the la
>test version is and every creator of a tool is responsible to have a server ru
>nning (either a server on their own site or in collaboration with someone else
>) that is capable of answering the question. The traffic on this channel could
> be transmitted using RTP/SRM or some other reliable multicast transport proto
>col. 
>???!!! :-)

You have to be a careful here - you don't always want the latest
version of a tool - you want the version of the tool that is
appropriate for receiving this session, and the appropriate version
may depend on the group of users amongst other things.  It isn't
necessarily the same as the latest version for a number of reasons,
including the fact that tools don't always become available on all
platforms simultaneously.

Of course, platform independant formats such as java may help with
this, but it's likely to be a little while before I want my video
codecs in Java...

As for rate of tool development - I suspect we're just about to see an
explosion in the number of new experimental formats and (possibly)
tools...  

You certainly can't assume homogeneity of tool in a session - I
counted five different audio tools (not counting different releases)
listening to the shuttle audeo (vat, rat, QTC, precept, sudha's).  So
putting the URL of a *tool* in an *SDP* message seems broken to me.
What SDP conveys is a description of the media format/protocol.  So,
unless we have a single java codec for a format (which I won't rule
out, but certainly don't want to assume), what do I put as a URL for
the format?  Surely this is dependant on the tool I wish to run (which
may be different at each host), and, on each host, the tool I wish to
run is dependant on the format.  Hmmm - think I just went in a circle
there...

It seems to be that what I want is a way of obtaining a codec list for
each version of each tool.  Assume I have multiple tools available at
each host, and multiple codecs on each tool.  Possibly codecs are
downloadable without changing tool version, but that doesn't really
change anything in the decisions a session directory has to make - I
think that's up to the tool to perform - such downloads.  Again, what
the session directory requires is a list of formats/protocols that
each tool-version can support.  This is what the sdr plugin mechanism
does.

This mapping information could be directly multicast.  The sdr plugin
format is getting close to such a format already, though currently it
lacks a tool version number field.  It could trivially be extended to
carry URLs for codecs or even the tools themselves - this was one of
the original motivations for going to this plugin mechanism, but I
have currently stopped short of automating tool download for obvious
reasons.

The sdr plugin format is described in the built-in help in sdr, though
it's not the format itself that's interesting, but rather the idea of
a declaration of formats/protocols supported.

Mark

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 30 May 1996 09:34:13 +0200

> platforms simultaneously.

[Stuff deleted]

I agree that it should not be a part of SDR (or any other SD protocol implementation)
to download and install newer versions of tools as needed. This has among other things
possible functionality, stability, backward compability, security and disk usage (multiple
copies of a tool) problems connected to it.

But, it's still a neat idea to use multicast to slowly download software (and new
hardware :) to a box. However, this would preferably be a kind of mirroring of an file
archive rather than pure drop-in replacement. A way to get the file when new files are available, an interuptive rather than polling system. Some of the mentioned problems are
solvable by the way :)

Also consider what you could do with web caching systems if you let them use multicast
mirroring systems instead....

But now we are moveing away from the conference control topic that this list is supposed
to be dealing with :)

Magnus

---

From: Peter Parnes <[email-masked]>
Date: Thu, 30 May 1996 09:56:39 +0200

> But now we are moving away from the conference control topic that this list is supposed
> to be dealing with :)

But I find the discussion very interesting and I just wanted to ask which m-list _is_ appropriate for this? rem-conf is more for conferencing and mbone is for more fundamental  mbone issues, or? Is it time for yet another one? 

/P

---

From: Mark Handley <[email-masked]>
Date: Thu, 30 May 96 11:17:04 +0100

>But I find the discussion very interesting and I just wanted to ask which m-li
>st _is_ appropriate for this? rem-conf is more for conferencing and mbone is f
>or more fundamental  mbone issues, or? Is it time for yet another one? 

My opinion, not necessarily that of my co-chairs:

If we're talking about config download, this is definitely the place.
If it's purely software download by multicast, this probably isn't the
place, and perhaps the wbone list is ([email-masked]).

Some discussion of these issues here won't do any harm, and they are
bordering on session control anyway.

Mark

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 30 May 1996 17:07:39 +0200

> But I find the discussion very interesting and I just wanted to ask which
> m-list _is_ appropriate for this? rem-conf is more for conferencing and mbone
> is for more fundamental  mbone issues, or? Is it time for yet another one? 

Well, I do agree that it is interesting, and I do agree that there is no list
which really feel apropriate. I can add to the list of "almost" m-lists with
idmr and rtp. Maybe mbone is the closest one after all.

An separate IETF WG for Slow Speed Multicast Applications or something migth be
of interest.

Magnus

---

From: [email-masked] (Christian Huitema)
Date: Tue, 4 Jun 1996 10:03:50 -0400

The Session Invitation Protocol as described in
draft-ietf-mmusic-sip-00.ps
uses a <user>@<host> address to identify a user, and an SDP formatted
session description.

Session descriptions can encompass several medias. A typical invitation
may suggest simultaneous use of audio, video and data conferencing. But
I may well want to receive the video on my set-top-box enhanced TV, the
audio in my Internet-connected stereo and the data on my PC. I may easily
program my invitation agent to know that, but how is it supposed to
respond
to a SIP invitation ?  Multiple redirections? Don't tell me "local
forwarding". The TV and the PC may well not even be on the same cable...

-- 
Christian Huitema

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Jun 1996 18:20:30 +0200

Christian Huitema writes:
> But
> audio in my Internet-connected stereo and the data on my PC. 

I don't think people will want to use future conferencing systems
without some program that coordinates the media and their appearance
in the conference, i.e. a conference manager (or session controller,
if you want).  So, the proceedings relating to the invitation will
take place on the host that you use for that control application.
Your media can flow wherever they need to.  And yes, I'm assuming that
there is some way to communicate between your TV (set-top-box, if you
want), your stereo, and your PC.

Now, I don't know if we really understand how to apply SDP session
descriptions in a unicast situation (what happened to the changes we
envisioned for that in Los Angeles?).  Certainly, we need a way to
express different addresses for each media stream to each participant
here.

Gruesse, Carsten

---

From: Mark Handley <[email-masked]>
Date: Tue, 04 Jun 96 17:33:22 +0100

>forwarding". The TV and the PC may well not even be on the same cable...

OK, this is my first pass assumption on what happens...

There are really two cases to consider: multicast and unicast.

Multicast: The distribution is entirely determined by the session
initiator - either you can receive the advertised session streams on
your assorted boxes or you can't.  If you can't you can attempt to
negotiate, but the inviter doesn't have to pay any attention to you.
If it does, then this becomes synonymous with (potentially multiple
instances of) the unicast case.

Unicast: You return a single negotiate reply giving the *destination*
(i.e. your) address (and format, etc) for each media you want to use.
(The original message will have given the source addresses).  In an
earlier private message you suggested a reply format that allows this
to happen in a SUCCESS reply.  Thinking about it some more, this
appears to be necessary with unicast, as you can't match up the source
and destination addresses in (unreliable) SIP if you return a
NEGOTIATE reply, as the sender can't (in this case) reflect your reply
in a subsequent request.

The SDP format doesn't assume all the media are on the same
end-system, or even the same network type (eg. a combined phone, raw
ATM, IP multicast and FM radio session would be perfectly legal if we
had defined all the relevant network types) though it does get ugly
with unicast session descriptions when the end system is not the same
one that received the invitation.  We discussed an alternative SDP
format at the last IETF, but in the end defered it due to insufficient
experience with the limitations of the current format and need to get
code deployed.  There'll probably be an SDP version 3 in the long run,
but we felt that more deficiencies will only show up with use and
alternative implementations.

Mark

---

From: [email-masked] (Christian Huitema)
Date: Tue, 4 Jun 1996 12:42:44 -0400

> express different addresses for each media stream to each participant

Communication between several boxes is not a real problem - they are
indeed connect to the Internet. Having the signalisation terminate on my
PC, and having the necessary magic there to pass info to my various boxes
is fine.
However, I would not like to have to relay the audio packets from my PC to
my stereo, or the video packets to the TV.

For multicast sessions, SDP works just fine. The SDP announcement may
carry connection descriptions (mcast address) for each media in the "c="
lines that may follow each media description (m=). I will just have to
pass the video mcast address and the port number to my TV set-top box, and
tell
it to just listen to that. The set-top will join the mcast group, the
video packets will come nowhere near the PC or the stereo.

I can send similar informations in an SDP message embedded in the initial
sollicitation for a unicast session. If I am calling, I can trust my PC to
pass the unicast address of the TV set-top in the "c=" line that follows
the description of the video media. The only problem is that the responder
cannot do the same -- there is room for only one address in the CH line.
I would suggest that we allow responder to also specify addresses for each
media, maybe by a set of "ME=" line that provide media-specific
information, like selected address, selected media encoding and selected
port.

One more request. I would like to have the option of specifying
domain-names at all the places where the session description and session
invitation protocols use numerical address representations. The possible
locations of users, the device they will use, the access rules are all
likely to be written down in configuration file. We should avoid writing
down addresses in configuration files -- at the very least, we should not
be forced to do it.

-- 
Christian Huitema