Subject: RE: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meeting in San Diego)

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 5 Dec 2000 13:11:14 -0500

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Monday, December 04, 2000 10:11 AM
> To: Jonathan Rosenberg
> Cc: Thomas LEVY; [email-masked]
> Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC
> meetingin San Diego)
> 
> > > It's the second case. Consider an application that wants to
> > > receive DTMF
> > > input from the user. Different mechanisms have been 
> proposed for this,
> > > and one of these is the use of an RFC 2833 DTMF media 
> stream. In the
> > > case where DTMF is all you wanted to support for a media 
> stream while
> > > having another media stream at the same time, you want a way
> > > to express
> > > that a given capability only applies to a given media stream.
> >
> > This doesn't require any extensions, so long as the 
> originator always lists
> > all codecs possible in a new stream.
> 
> Yes, but that's the problem with SDP and the point about 
> adding capability
> descriptions that are separate from the media description. 
> You may not be able
> to or want to support all possible codecs simultaneously, 
> e.g. due to DSP
> restrictions or because you cannot express different types of 
> media in a single
> media stream as in the case of T.38.

I just want to make sure we are solving real problems. Seems that we have
been able to survive so far without more complex capability negotiations.
Capability negotiation is one of these things people spend a lot of time
specifying, but which seems is almost never utilized extensively.

The one and only NEED that I have heard about is the "I support many codecs,
but pick one and stick with it for the whole session" capability. This is
important for phones that download the codec into memory once it has been
selected. This can be done much more simply than with the mechanism you
describe.

THis must be also reconciled with the fact that SDPng is coming; so, I see
little need for specifying anything more than critical things now, since a
more complete and less hacked up solution is coming.

-Jonathan R.

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

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 05 Dec 2000 14:00:41 -0500

Jonathan Rosenberg wrote:

> I just want to make sure we are solving real problems.

Point taken.

> Seems that we have

Most protocols go through evolution and extensions. It's not a question of
survival, it's a question of addressing an evolving and changing set of
requirements.

> but pick one and stick with it for the whole session" capability.

Where did you hear that ? I specifically disagree with the "stick with it for
the whole session" part as there today are scenarios that require codec shifts
mid-call but still only want to support one codec at a time. And what about T.38
and similar ?

> This is

I think it's pretty simple as is, but I'm open to other suggestions. However, we
should probably spend time agreeing on the problem scope first. As mentioned
above, I think your description is an oversimplification - at least it doesn't
address the problems I want to solve.

> more complete and less hacked up solution is coming.

As explained in the draft, I agree we should only look at the essential things
right now, however I also feel strongly about adding some simple capability
description to SDP. It is urgently needed for several applications and we can
either all go on and implement proprietary solutions or we can agree on a
limited problem scope and accompanying solution - I am trying to do the latter.

Secondly, even if we had SDPng today (which we don't), there's a substantial SDP
base out there which will not go away anytime soon and there's a big difference
between adding a couple of extra things to SDP and completely replacing it.
However, I agree that a complete and general capability description/negotiation
solution is not what we should strive for here - that's what SDPng is intended
for.

I think we are more or less in agreement here.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Christoph Reichert <[email-masked]>
Date: Tue, 5 Dec 2000 21:41:17 +0100

Another approach might be to let SDP do what it was intended for:
describing sessions with connection information and already chosen
media formats.

In my understanding, describing capability sets and constraints like
"X cannot be used together with Y" is very different from describing a
session.

Two points on that:

* capability descriptions does not contain IP adresses or port numbers or
  address family ids...

* logically, usable capabilities must FIRST be negotiated, and THEN,
  after the negotiation is finished, one or more from the resulting set
  can be used to create an SDP record.

When capability descriptions/negotiation is not mixed with session
descriptions, no changes/extensions to SDP are required.

Maybe it helps to define a MIME type, say application/capabilities, and an
algorithm how these MIME-objects have to be intersected.

The INVITE(REFER) carries only the capability object of user A
(already intersected capability set), the 200 Ok carries only the capability
object of user B.
Now, both users know the capabilities of each other and apply the
algorithm to get the intersection.
Finally, user A sends an INVITE/(REFER) with an SDP record containing only
negotiated capabilities.

This should also work with more than two parties involved in a call,
full mesh and central conference servers.

For complex call graphs, it might be hard to figure out who has seen
all capability sets, though.

cheers, chris

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 05 Dec 2000 16:26:57 -0500

> "X cannot be used together with Y" is very different from describing a

Right - I wasn't looking for that level of expressiveness though.

>   can be used to create an SDP record.

Logically yes, but in practice I'm not sure it's such a good approach. It the path
H.323 took initially and the lessons learned lead to the "fast connect" procedure
where you include both capabilities and media session descriptions.

Also, I would not want to modify the existing procedures, e.g. SIP session
establishment, but rather simply extend them with additional "capabilities".

> descriptions, no changes/extensions to SDP are required.

True, but why invent a new mechanism when there's a perfectly adequate extension
mechanism defined in the protocol already ? Furthermore, by using that extension
mechanism you are guaranteed interoperability with existing implementations,
regardless of whether they support the extension or not. Multipart/MIME is likely to
break more than one existing implementation.

> algorithm how these MIME-objects have to be intersected.

That's an awful lot more work than simply extending SDP with a couple of extra
attributes and again backwards compatibility is an issue. I see this as more
appropriate to the SDPng than a simple and limited "fix" to SDP.

> Finally, user A sends an INVITE/(REFER) with an SDP record containing only

You lost me - can you elaborate ?

> full mesh and central conference servers.

If you are referring to multicast, then I'm willing to sacrifice that (others may
not). If unicast, then it would seem we simply have a bunch of two-party connections
and capabilities just apply to the two endpoints for each (implementation restrictions
may of course imply that you'd prefer everybody to use the same codec which in the
full mesh case at least could be a challenge).

> all capability sets, though.

Right - I would be fine with leaving that out of scope.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Christoph Reichert <[email-masked]>
Date: Tue, 5 Dec 2000 23:21:55 +0100

> where you include both capabilities and media session descriptions.

For the "fast" point to point case, the receiver of a SIP INVITE which carries
the caller capabilities, the callee can already intersect the capsets
of itself and the caller, and the 200 OK can carry the SDP.

> break more than one existing implementation.

Maybe, I don't know what the SIP spec says if an INVITE carries no SDP record.

> appropriate to the SDPng than a simple and limited "fix" to SDP.

Well, maybe it's better to specify an initial SDPng alias
application/capabilities MIME-type than to try to fix SDP.
Again, I proposed neither to fix SDP nor to change SIP.
Encode your caps as a MIME object and carry it within SIP, not SDP. 

> You lost me - can you elaborate ?

Normally, when a caller calls a callee, the caller sends a SIP INVITE
with "Content-Type: application/sdp" and an SDP record as the payload
of the INVITE. The callee changes the SDP record and sends it back in
the response.

The idea is now simply to replace the Content-Type:  application/sdp
with Content-Type: application/capabilities in the initial INVITE sent
from the caller to the callee, and also to replace the SDP record with
the capability information.

In the case of a fast call, the callee can intersect its capset with
the capset received with the callers INVITE message, and generate an SDP
record.  This SDP record would be sent back in the 200 Ok response with
Content-Type: application/sdp and the SDP record as the body of the
response message.

This is as fast as befor, requires neither a change in SDP nor SIP, but
in every implementation which wants to negotiate capabilities.
The latter is also true for your own proposal.

> full mesh case at least could be a challenge).

I did not refer to multicast.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 05 Dec 2000 18:50:45 -0500

> of itself and the caller, and the 200 OK can carry the SDP.

Exactly, hence the suggestion to simply include it in the SDP but to separate it from the
actual media stream description, since otherwise we are back where we started.

<snip>

> Encode your caps as a MIME object and carry it within SIP, not SDP.

I still don't see how you make that backwards compatible and it also seems a lot more
complicated to me than adding a couple of attributes.

What is the problem with adding such attributes to SDP and why would an extra body/MIME-type
be better ?

> in every implementation which wants to negotiate capabilities.

OK - thanks. I see a couple of problems with that:
- The caller doesn't know which IP address and port to send media to
- The callee doesn't know which codec(s) the caller agrees to use (if you assume the caller
will honor whatever the callee sends back, the caller might as well have used SDP "m=" lines
as is as this is the current semantics anyway.)
- The caller doesn't get to know the callee's capabilities.

You may of course argue that this only applies to the "fast" procedure, and can be avoided
by a two-roundtrip setup instead (capabilities followed by actual media description),
however the SDP attribute proposal has none of these drawbacks and allows for the current
single roundtrip.

-- Flemming

<snip>

--
Flemming Andreasen
Cisco Systems