Subject: New requirements for fid?

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Apr 2001 00:33:39 +0300

Hello,

Orit Levin from Radvision has proposed to extend a little bit the fid
draft to cover, besides a flow consisting of several media streams
(which is the current purpose of fid), lip-sync as well.

The syntax would not be difficult to change. I can think right now of
two ways:

1) asinging a unique identifier to each media steam and adding a session
level attribute that groups them and states the semantics (for example,
m lines 1 and 2 anre grouped for lyp-sync; m lines 2 and 3 are grouped
because they are a single flow).

2) let the fid as it is and define lid is a similar way. m lines with
the same lid are grouped for lip-sync.

I would like to get the opinion of the WG. Do folks think that adding
this funcionality to the fid is appropiate? If so, I can add it and
release the draft again.

If folks think that the fid is OK as it is and that this functionality
should not be added, we can progress with the WG last call.

Independently of the answer of the group, I believe that folks attending
the WG meetings should speak up before, not in the last moment. 

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Joerg Ott <[email-masked]>
Date: Wed, 4 Apr 2001 14:53:34 +0200 (MEST)

Folks,

I think Colin and myself have made it clear over the last two IETFs that
we will not allow any further tweaks to SDP or further extensions but
instead focus on the SDPng work.  This is also where folks looking for
further extensions should put their efforts (contributions are rather
limited at the moment though!).

This has also been established consensus at the last two IETF meetings.

> (which is the current purpose of fid), lip-sync as well.

I is a well known deficiency of SDP that it provides no means to link
different streams to each other.  This is one of the issues to address
with SDPng.

Despite this deficiency I have not heard a pressing argument to fix this
while we have been dealing with SDP revisions over the last year.  Given
that SDPng is coming closer we should not go for further feature creep
into SDP; there has been far too much until now.

But there are technical issues as well.

> because they are a single flow).

This is probably the architecturally cleaner approach (of the two).  But
this also means that the semantics for those session level attributes
have to be defined, including their possisble "feature interactions".
An extension or registration mechanism has to be put into place for this
as well.  There is quite some convincing to be done before I am willing
to go through this kind of hassle for AN INTERIM SOLUTION!

> the same lid are grouped for lip-sync.

This would mean that we are likely to come up with 10 other [a-z]id
attributes in the near future for the same purpose.  This does not sound
like a road I want to go down to.

Apparently, the lip-sync stuff only applies to video conferencing or
other *multi* media applications.  However, I'd like to see the
reasoning why this needs to be done, why this can't be done based upon
assumptions (like so many other things with SDP), why this needs to be
done now (and has not been raised before), and why this can't wait for
SDPng.  Even then, I would still be hesitant to allow further features
into SDP.
> should not be added, we can progress with the WG last call.
We agreed on a WG Last Call at the IETF; given this discussion, I would
liket to postpone this for a moment to give people another chance to
speak up.  But, I would really like to close this and issue a WG Last
Call on the fid document AS IS by the beginning of next week.

Comments?

Cheers,
Joerg

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 05 Apr 2001 01:05:03 +0300

Hi all:

Some thoughts.

It seems to me that the all the standard process we are doing is to allow
interoperability between different vendors solutions. If we stop this,
vendors might implement their own extensions/attribute, and that has no
value at all.

It seems to me that the there are clear market requirements coming from,
at least, three different approaches to allow the SDP to enable different
degrees of synchronization/coupling of a media stream into different flows.

And I see that the proposed solution is quite simple and backwards compatible.

And SDPng is in a very preliminary state.

And an FID draft won't make any interference to the SDPng work.
It won't delayed it, and it won't make any harm

So, having all these thoughts into account, I see no reason why this particular
piece of work must be stopped. 

The proposed fid draft is not an INTERIM solution. There are already enough 
SDP implementations out there requiring this solution, to justify the work.
They can't wait until SDPng is out there, because it will be late. And in 
the event that SDPng would be ready, nobody can force to upgrade all the 
implementations with the latest Session Description Protocol, SDPng, 
SDP New Era or whatever SDP.

My proposal, (if I am allowed to propose something), is to collect the different
ideas and incorporate the suggested changes into the FID draft, so that the 
solution is generic enough to be used by the different proposals, and let the 
draft progress accordingly.

Regards,

       Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002