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

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2001 16:08:26 -0400

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.

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.) 

- 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.

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. 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..."

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.

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.

	Paul Kyzivat
	Cisco Systems