Subject: RE: New requirements for fid?

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 3 Apr 2001 19:13:08 -0400

This looks like a good idea.  We can't use it in Megaco because we separate
our streams and stream descriptions, but we get the equivalent effect by
saying that streams passing through the same termination are synchronized.
It would be nice if SIP had the matching capability.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 5:34 PM
> To: mmusic
> Cc: Orit Levin; Joerg Ott
> Subject: New requirements for fid?
> 
> 
> 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: Orit Levin <[email-masked]>
Date: Wed, 4 Apr 2001 17:02:55 -0500

Hello all!
First of all I would like to apologize for this late timing, which
(hopefully) may be justified by our exploration of "SIP beyond Voice only"
direction. 

<<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 has also been established consensus at the last two IETF meetings.>>

Following the working group consensus, I am not proposing a new extension to
SDP beyond the current "fid" requirement. Moreover, I don't see the proposed
changes to the latest "fid draft" as addressing new requirements.
Technically, it is an attempt to address the same requirements in a way
allowing standard interoperable applications.

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

The debate over the "fid draft" for the whole last year is the proof for
emergency of this requirement.

<<This is probably the architecturally cleaner approach (of the two). >>

I definitely agree with you. Below is the proposal:

I would define the fid exactly the way it is defined now, but I would use it
for numbering of each m line alone. (Also I would rename it to mid ;-)).
Then I would add a block exactly as in the "simple capabilities" draft:
a=fsqn: <sqn-num>
a=fpar: <semantics>:<list-of-mids>

The values for "semantics" are

LS - for Lip Synch
AS - for Application Specific

There can be more then one fpar line within an "fsqn" block.

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

This doesn't require SIP "Require header" or any other additional procedures
to signal the support or specific behavior. 

<<There is quite some convincing to be done before I am willing
to go through this kind of hassle for AN INTERIM SOLUTION!>>

Current "fid draft" includes SIP examples to explain the meaning of this
extension. Once the examples will be removed from the draft (as agreed
during the meeting because of the incompatibility with SIP procedures), the
"fid" semantics will become absolutely "application specific" which misses
the whole standardization point.   

Best Regards,
Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

-----Original Message-----
From: Joerg Ott [mailto:[email-masked]]
Sent: Wednesday, April 04, 2001 8:54 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: New requirements for fid?

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.

> 1) asinging a unique identifier to each media steam and adding a session
> level attribute that groups them and states the semantics (for example,

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