Subject: RE: Action items from MMUSIC meeting for comedia-01

From: "David Yon" <[email-masked]>
Date: Thu, 13 Dec 2001 08:03:52 -0500

Inline

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

My implicit assumption is that a connection can carry the exact same
media that can be carried between two endpoints using UDP.  So for
example, it is my understanding (correct me if I'm wrong) that RTP can
carry two different types of streams (i.e., G.729 audio, H.261 video) to
the same UDP port without the endpoint getting confused.  In theory, the
same should be possible in an RTP-over-TCP scenario.

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

How is this solved in RTP/UDP?  The above can be said for traditional
RTP-based media, could it not?  To paraphrase the above: "after having
handed out some SDP containing a UDP port number, I must be prepared to
accept media on the specified port for some period of time...  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."  

This is similar to the "how long do I reserve this DSP for a codec"
problem, yes?  The only difference is that you are also holding a
listener open.  The lifetimes match exactly, at least in the scenario
you describe.

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

Why is this true for TCP and not UDP?

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

I certainly agree that mediaversion:NNN is not a clean solution.  And
I'm still having trouble understanding why you need to tag media streams
with an additional descriptor for TCP but not UDP.  And I'm also having
trouble understanding why this isn't just FID reinvented, but I'll admit
that I'm not intimately familiar with FID.  :-)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Dec 2001 10:53:10 -0500

More responses inline.

	Paul

> same should be possible in an RTP-over-TCP scenario.

I don't disagree with what you say, but I don't understand what it has
to do with "endpoints are free to send new media streams over a
connection that has already been established". As far as I know, a media
stream is whatever is specified by an m= line. It could involve packets
encoded according to a variety of codecs as long as they were all
specified on the m= line. However that would exclude combining audio and
video because they cannot be specified on a single m= line.

The only way that I can imagine interpretting "endpoints are free to
send new media streams over a connection that has already been
established" is that a new media stream, specified by a new exchange of
SDP, can reuse a connection established previously by some other
exchange of SDP.

But I don't know how to make that work in practice. Does that mean that
once I have published some SDP using the comedia TCP transport, that I
must be prepared to accept an arbitrary number of connections to that
port and then merge the data received over all of them?

> RTP-based media, could it not? 

No it can't. With UDP there are no connections. I just have a single
socket over which I receive packets. If there is a reinvite where the
same port is passed, it doesn't matter whether the recipient believes
this is new or old - they just send packets to the port. I don't see any
difference whether they are sending according to the old or new sdp.

> To paraphrase the above: "after having

No. In the udp case, I have to keep one receiver active receiving
packets on a port I have published. That is all.

In the comedia tcp case, I have to keep a listener active listening for
new connections on the port. Then for each connection, I have to keep a
receiver active receiving packets. So in thread based implementation,
instead of one thread for receiving, I need a minimum of two - possibly
more if I receive multiple connections. This will make using comedia
*significantly* more expensive than using UDP, over and above the
inherent extra cost of a TCP connection.

This may be exactly the right thing to do if you are publishing the SDP
to a crowd using SAP, or are multicasting it to a crowd using SIP. But
in the normal sip invitation model it really makes life difficult. What
I believe ought to happen is that at most one connection should be
established at a time per new media session direction. Once this session
is established, there should be no obligation to listen for other
connections. A request for a new connection establishment should require
an exchange of new (i.e. changed) SDP. If this is done, then there is
only a need to wait for one thing - initially for a connection, and once
a connection is established then one stops waiting for new connections
and starts waiting for packets arriving over the connection.

> Why is this true for TCP and not UDP?

I explained this above.

> that I'm not intimately familiar with FID.  :-)

In principle it might be useful to tag udp media streams as well as
comedia streams. It is just that the need isn't as compelling. 

If the receiver is required to accept new connections at any time then
tagging of media streams isn't useful. But if the connection
establishment process only is to occur under certain circumstances, then
the tagging is required to indicate when that is. This is something that
doesn't occur for UDP and so the tagging isn't required there.

One way to determine when to do connection establishment is when a new
SDP media description is sent or received. But the definition of "new"
needs to be clarified. A media description is clearly new if:
- it is contained in the first SDP in a new invite;
- this is a reinvite and a media description has been added where
  none was before;
- this is a reinvite and this is a replacement media description
  with a port number different from the prior one.

It is not so clear whether a new connection should be established in the
following cases:
- this is a reinvite and the media description is identical to that
  in the prior invitation
- this is a replacement media description in a reinvite, the media type,
  transport and port are unchanged, but something else is changed.

Under normal circumstances you certainly don't want to establish a new
connection if an identical media description is exchanged, because this
is what will happen in a reinvite intended to refresh a session timer or
to revise a different media description. But there needs to be some way
to indicate that you want to establish a new connection even though you
don't want to change anything else. 

Introducing versioning of the media description is one way to indicate
this. 

I suppose another way would be to say that you have to use two reinvites
to achieve that: one to drop the media session by setting the port
number to zero; then another to establish a new media session. (Or you
could do both in one reinvite by establishing your new session at a new
position within the SDP.)

In any case, there need to be rules for what is permitted in reinvites,
and what impact it has on connection establishment. For instance,
suppose I send a reinvite with a media description that is identical to
what was previously used, expecting that we will continue to use the
connection we have already established. But you return a corresponding
media description that is different. Do we always establish a new
connection, or does it depend on the changes you made? This is more
complex in the comedia case because each side's sdp can affect transport
in both directions.

	Paul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 13 Dec 2001 21:55:54 -0500

>same should be possible in an RTP-over-TCP scenario.

That's not really correct. RTP should not be used to transport different
media on the same port, since those will be different sessions. It can
send different media which form part of the same session (e.g. voice +
DTMF codecs).

Colin