Subject: RE: draft-rosenberg-mmusic-sdp-offer-answer-00

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 16:19:27 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 4:20 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: draft-rosenberg-mmusic-sdp-offer-answer-00
> 
> > Actually, lets get specific here. Besides tcp 
> initialization, what kind of
> > initialization needs to happen that is not provided itself 
> within the codec
> > (i.e., an H.263 encode could send all intra frame to 
> reinitialize the state
> > of the frame at the decoder)? No need to solve a theoretical problem
> > only.....
> 
> Any kind of connection oriented transport can have this problem:
> TCP, SCTP, SSL, and possibly specialized ones like SIP MESSAGE,
> BXXP, etc.

Right, but if all of these are connection oriented transports, then the
comedia draft would work for all. The question is if there are other pieces
of initialization that need to be conveyed outside of the media stream?

> > So, lets say you have a system that has two separate audio 
> sources. You
> > invite someone else, and you include an SDP with two media 
> streams, each for
> > audio. In that case, you would send each source as a 
> different stream. A
> > device with multiple sources knows to offer multiple 
> sources and therefore
> > knows how to map those sources to streams.
> 
> Technically, the offer is what you are willing to receive, not send,

That used to be the case some time ago, but the text for some time now
indicates that for a sendrecv stream, it lists what you are willing to
receive and send. Without that, there is no hope for the same codec in both
directions. Also, there is no way to know whether there has been an error
because there are no codecs that overlap. Here's an example. Lets say the
offerer says "I can receive with G.729 and G.711" - note that they can't
send with G.711. The answerer says "I can receive with G.711". However, this
is really a failure - no media will go from the offerer to the answerer. If
you just list what you receive, these cases are not detected.

> though with the offer/answer model there is some implication that you
> might want to send as well. So the most important thing in your offer
> is the number of audio sinks you have. You may have two sinks and one
> source, or two sinks and two sources. Absent FID (or maybe even with
> FID) you have no way to say which.

See above; it would indicate that you have two sinks/sources if there are
two sendrecv streams offered.

> 
> > 
> > However, lets say you have a device that only has a single 
> audio source. You
> > receive an offer with two audio streams. The spec is trying 
> to say that you
> > should accept both, and copy your source to both streams. 
> Now, don't ask me
> > what to do if you are a system with two sources, and you 
> receive an offer
> > with three audio streams; thats what FID is for. Without 
> it, its not clear
> > what to do. We could make it a policy decision, so that an 
> endpoint can
> > choose which of its sources to send on each stream. If 
> there is only one
> > source, there is only one reasonable policy, send that source on all
> > streams.
> 
> I think the more interesting question is what to do if you receive
> an offer with two streams, and you can have as many sources/sinks as
> you choose. How many should you offer back?

That depends alot on the directions of those streams. If they are sendrecv,
I imagine you would accept both, and as I propose above, the mapping of your
sources to those streams is arbitrary, and you should mix what you receive.

> 
> An example of this would be IM streams. You could open up multiple
> windows, one per offered stream, or you could open up one, mix the
> inputs from both, and replicate your output stream to each. Then you
> are faced with how to mix IM streams. You might have to find a way
> to eliminate duplicates received over both streams. Ugh!

It actually works OK if you take "mix the received streams" not literally,
but rather to mean, "present all data received immediately +/- any kind of
media buffering". That would imply mixing for audio, but for IM, would
simply mean that you would display each IM once its received. Now, in terms
of sending, my proposal was that the mapping of sources to streams is a
matter of local policy. In this case, the policy is simple; the mapping of
the source to the stream is clear based on which thread window the user
enters the IM.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com