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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 11:33:25 -0500

Paul - thanks for your read through and comments. Responses inline.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 4:08 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: draft-rosenberg-mmusic-sdp-offer-answer-00
> 
> 
> Jonathan,
> 
> It is good to see this material factored out of the sip rfc.
> 
> I have a few comments after an initial skimming:
> 
> 1) An issue came up in discussions of the comedia draft regarding
> semantics of modifying a session. The latest comedia draft has a
> solution for it, but it seems a more general problem and perhaps it
> deserves a general solution here.

Its not clear that offer/answer is the best place either. After all,
wouldn't the issue arise with a SAP-delivered announcement too (not for TCP
connections, but for initialization of parameters)?

> 
> The problem is that some media streams may require 
> initialization before
> first use. When a session description is modified, there then 
> arises the
> question of whether a particular media stream requires
> re-initialization. (For instance, when negotiating a TCP session with
> comedia, a connection must be established between the two endpoints.)

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.....
 
> 
> - If an entire session description is unchanged, as 
> determined by the o=
> line, then it can be assumed that nothing has changed and
> reinitialization is not required.
> 
> - If the o= line is changed, then it may be assumed that individual
> media sections that have changed require re-initialization. But there
> remains the issue of media sections that have not changed. Since
> modification of a single media section requires a complete description
> of all media to be sent, it follows that any unchanged media sections
> will seem to be unchanged. Presumably these should not be 
> reinitialized.
> 
> - However, there are cases when it may be important to request
> reinitialization without changing any of the information in a media
> section. For instance, if one participant has difficulty 
> sending but not
> receiving, it may believe the other participant is having difficulty,
> and wish to send a reinvite to force reinitialization. But it may
> wish/need to use the same information in its own offer. In this case,
> the other participant will not be able to distinguish that this is a
> request to reinitialize rather than a no-op modification.
> 
> One possible solution to this problem is to permit the use of the o=
> line within individual media descriptions as well as 
> globally. When used
> within a an individual media description, this would have the same
> semantics as globally, but would apply only to the one media
> description. To initiate a reinitialization, one could send a new
> description with only the o= line for the medium in question 
> changed. Of
> course this is a change to SDP. But it seems preferable to one-off
> solutions to this for different media.

If something was needed beyond the a=reuse which is already described in the
comedia draft, I would prefer to simply define an explicit attribute that
conveys what you want, like a=initialize or something. However, I'm not
convinced that this is needed.

> 
> 2) A nit in section 2.1. It starts off with: "The offer MUST contain
> zero or more media sections." This is a pretty rough condition to
> conform to. 

Rough? Actually, its impossible to define an SDP that doesn't comply; maybe
that is what you mean?

It might be said more directly as something like: 
> "The offer
> MAY contain one or more media sections. An offer with no 
> media sessions
> implies..."

OK. I will fix.

> 
> 3) Section 2.1 is also heavily biased towards RTP based media
> descriptions containing payload type descriptions. The descriptions of
> how to process and interpret payload types and codecs really should be
> qualified so it is clear they apply only to the RTP transport. For
> instance, a=rtpmap is only appropriate for RTP transport.

The section is most definitely speific to RTP transport; its hard to
generalize this or talk about other things since not much has been defined
besides RTP. I will try, however, to do that.

> 
> 4) Section 2.1 also discusses the semantics of multiple media 
> streams of
> the same type, and says that the same source should be sent to each of
> these streams. This seems quite restrictive, and covers semantics that
> are the subject of the FID semantics in 
> draft-ietf-mmusic-fid-05. In the
> absence of the notation from that draft, it seems wrong to assume that
> the different media streams will contain the same content.

Thats true. The spec is trying to define behavior in absence of the FID
parameters. I could reference FID to say "FID overrides this behavior", but
that is going to introduce another draft dependency, and its not clear its
needed.

When there are no FID parameters, the distinction, I think, is whether you
offer multiple streams or answer multiple streams offered to you.

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.

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.

-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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2001 16:19:38 -0500

Comments below.

	Paul

> connections, but for initialization of parameters)?

Discussed in another thread.

> of the frame at the decoder)? No need to solve a theoretical problem

Any kind of connection oriented transport can have this problem:
TCP, SCTP, SSL, and possibly specialized ones like SIP MESSAGE,
BXXP, etc.

> convinced that this is needed.

Discussed in another thread.

> Rough? Actually, its impossible to define an SDP that doesn't comply; maybe

Yeah. I should have added a smiley.

> knows how to map those sources to streams.

Technically, the offer is what you are willing to receive, not send,
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.

> source, there is only one reasonable policy, send that source on all

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?

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!

I am not convinced that there is a reasonable default that is right
for all media.