Subject: Action items from MMUSIC meeting for comedia-01

From: "David Yon" <[email-masked]>
Date: Mon, 10 Dec 2001 19:45:41 -0500

1. I need to make sure that comedia syntax aligns with sdp-new.  I'll go
over the draft and work with Colin to resolve any conflicts.
 
2. Symmetric RTP (UDP?) needs to be added as a transport type.  There
were at least two offers to supply wording as to how that is defined.
Any takers?
 
3. There was one vote to eliminate "direction:reuse", with the implicit
assumption that endpoints are free to send new media streams over a
connection that has already been established.  Any dissent?  Paul
Kyzivat had provided the original motivation for its inclusion.  Paul:
do you have any issues there?  If not, I will remove direction:reuse and
replace with wording that describes the aforementioned assumption.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Dec 2001 13:00:48 -0500

Comments below.

	Paul

> David Yon wrote:
> 
> 1. I need to make sure that comedia syntax aligns with sdp-new.  I'll
> go over the draft and work with Colin to resolve any conflicts.
> 
> 3. There was one vote to eliminate "direction:reuse", with the
> implicit assumption that endpoints are free to send new media streams
> over a connection that has already been established.  Any dissent?
> Paul Kyzivat had provided the original motivation for its inclusion.
> Paul: do you have any issues there?  If not, I will remove
> direction:reuse and replace with wording that describes the
> aforementioned assumption.

I don't know what "endpoints are free to send new media streams over a
connection that has already been established" means. With comedia, the
purpose of the sdp is to define how and when to establish a connection.
As far as I know, once that connection is established, it can be used
for at most one media stream in each direction. (That may not quite be
true for SCTP, but that has its own ID.)

The fundamental issue is that after having handed out some SDP
containing a comedia based media description, I must be prepared to
accept a connection on the specified port for some period of time. But
it is important to be able to bound that period of time. For instance,
once a connection has been accepted, I need the option to stop listening
for new connections, unless there is an exchange of new SDP. And if
there is an exchange of new SDP, I still need to distinguish the case
where there is no intent to change this particular media session from
the case where that is exactly the intent. To achieve that, there needs
to be something in the SDP that permits me to distinguish the two cases.

As I have posted elsewhere, I don't think that direction:reuse is quite
the right solution, because it isn't idempotent. Rather, I think that
there should be something in the SDP that must change in a reinvite as a
precondition to establishing a new connection.

It is a bit difficult to discuss this independently of the context in
which the SDP is distributed and used. I think the usage rules (and
needs) might be different for SDP distributed via SAP than it is for SDP
exchanged via SIP.

The reason this is important is because there is no reliable way to
share the same listening port among multiple SDP media descriptions and
correlate a given connection established to that port with a particular
one of those descriptions. As a result, I am forced to establish a new
listening port, and listener, for each media description. This is an
expensive price to pay, and gets more expensive the longer you have to
keep it.

So the bottom line is that I don't agree with simply removing
a=direction:reuse without replacing it with something else. I have two
alternatived proposals for what could replace it:

1) change the definition of o= in SDP so that it may appear in both the
Session description and in Media descriptions. As with other lines that
can appear in both places, an o= in the session description would serve
as a default for media descriptions that have none of their own. Then,
use changes in the o= to indicate changes in a particular media
description. Checking the o= line for a media description would then be
a way to determine if that has changed between two copies of the SDP.
For comedia, if the media description has changed, then the connection
establishment must be done again, but if it is unchanged, then any
existing media session would continue to be used.

2) add a new a= line to serve the same purpose as (1). For instance,
      a=mediaversion:NNN
Require this line with comedia. Require the value NNN to increase every
time the media description is modified. If NNN increases in a comedia
media description, then do connection establishment again. If NNN is
unchanged, continue to use an existing media session.

I believe (1) to be the cleaner solution. But it requires changes to
SDP. If that is unacceptable, then (2) gets the job done. It is
essentially just a different syntax for (1).

	Paul