Subject: RE: FID Draft - again

From: Orit Levin <[email-masked]>
Date: Thu, 14 Jun 2001 15:31:07 -0500

I guess, I have hesitation from providing examples because I dislike
standards built upon examples. In addition to that, everybody is looking for
new exiting applications. Thus, I am not sure that people are willing to
share them publicly.

Nevertheless, here is a familiar application provided by my colleague:
During international videoconference a speech in a certain language is being
translated simultaneously to a number of other languages. One video stream
(that of the speaker) and all the audio streams are transmitted to the
participants. Each participant has the ability to choose a single audio in
his native language to be actually displayed. Lip-synch between video and
audio makes sense and required for one of the audio streams only. For all
the rest it is a burden. The question is: which one is the right one?

Orit. 

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 3:28 PM
To: Orit Levin
Cc: Joerg Ott; [email-masked]; [email-masked]
Subject: Re: FID Draft - again

Hello,

> Are we expected to repeat the reasons again and again?

The mail sent by Joerg did not ask anybody to repeat any reasons. The
mail asked for a "real world" example where you want to use lip-sync.
That is, what application you have in mind when proposing this
extension.

The mail also said that if there is a real world example to resolve,
there is no problem for going with the extended definition.

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: Mon, 18 Jun 2001 09:29:42 +0200

> new exiting applications. Thus, I am not sure that people are willing to

I think this is the point I am trying to make: don't build your next gen
application on yet-to-be-added features of SDP.  Seems that it's always
easier to bug fix around some existing stuff (aka SDP) than to come up
with ideas on how to do it from "kind-of-scratch" (aka SDPng).  Sigh...

> the rest it is a burden. The question is: which one is the right one?
 
Ok, you have a point here.  For this specific example, SDP seems to give
you all you need (even though it might be easier for your endpoint to always
do lip-sync but that's you choice).  I had thought of other examples where
more semantics than just a=lang: would have been needed.

Gonzalo will submit a draft that generalizes the fid field to allow for
both features and we'll go through the review process again.

Please, folks, let this be the last addition to SDP we have to go through
here.

Joerg

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Jun 2001 19:51:21 +0300

Hello,

> both features and we'll go through the review process again.

I have just submitted the new version of the draft to the IETF. It will
appear in the archives soon. In the meantime, you can find it on the URL
below:

http://www.hut.fi/~gonzalo/papers/draft-ietf-mmusic-fid-02.txt

I hope everybody is happy now and we can move on.

Best regards,

Gonzalo

---

From: "Muhammad Mukarram Bin TARIQ" <[email-masked]>
Date: Mon, 18 Jun 2001 14:25:43 -0700

Hi All,

I have a question.

1. How is mid attribute functionally different from the i=* (media title)
{ref: RFC-2327 , pp 7} which is already present in the original SDP. Can we
use a list of Media titles instead of "mid" values in the "groupe" attribute
parameters. How would it be semantically different.

Also I have a suggestion (may be not directly related to this draft). FID
draft addresses quite a few issues listed in ID "Sip For Video"
{http://search.ietf.org/internet-drafts/draft-levin-sip-for-video-00.txt}.
I feel that using a media stream identification tag that is not specific to
FID or LS,
will satisfy more issues pointed out in Levin's draft, like: "2.4.1 An
ability to reference a specific media stream", and others such as abiltiy to
alter/change some parameters of the individual media streams in a running
session, with out specifing the parameters that do not change.

Thanks,

Muhammad Mukarram Bin Tariq
------------------------------------------
DoCoMo Communications Laboratories USA, Inc.
181 Metro Dr, Suite 300, San Jose, CA 95110
Tel: 408-451-4739, Fax: +1-408-573-1090
Email: [email-masked]

----- Original Message -----
From: "Gonzalo Camarillo" <[email-masked]>
To: "Joerg Ott" <[email-masked]>
Cc: "Orit Levin" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, June 18, 2001 9:51 AM
Subject: New version of FID. WAS (Re: FID Draft - again)

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 19 Jun 2001 05:33:00 +0300

Hello,

> parameters. How would it be semantically different.

As you point out, an i line, when used as a media level attribute
contains the media title. Using the i line was one of the first
proposals in order to group lines. I recall a discussion in the mailing
list around two years ago about this.

However, the i line is basically intended for human use. We did not want
to overload a header with more funcionality. This way, if an
implementation adds a mid line, it is clear that group is supported.

> session, with out specifing the parameters that do not change.

Section 2.4.1 of the draft you point out is actually an example of what
you do not want to do with SIP. As you know, SIP design tries to use as
far as it is possible idempotent requests. That's why the whole SDP is
sent every time you re-INVITE the other party. It is not because SDP did
not provide a means for labeling media streams. It is because it avoids
synchronization problems.

Therefore, with the LS semantics defined in the FID draft we cover the
useful cases of the SIP for video draft.

Thanks for your feedback,

Best regards,

Gonzalo