Subject: RE: New version of FID. WAS (Re: FID Draft - again)

From: Orit Levin <[email-masked]>
Date: Thu, 21 Jun 2001 12:23:03 -0500

I will have some pure editorial comments on the draft that I hope sending to
the authors later today.
In regards to Jonathan's comments:
1. I fully agree that the description of "how MID attribute may be used
within SIP" should be defined and standardized. It can be done, it would be
a useful thing to have, but it is not a part of SDP. Hence I suggest to
remove the "SIP use" chapter from the draft itself. (BTW I support 1b as a
part of "SIP use" draft). The draft itself should define the standard
meaning of the attributes to the applications, not when and how SDP
descriptors are conveyed using protocols such as SIP.
2. I also see the DTMF case as a separate application which does not fall
into FID category.
3. In the example (which is really just an example) only a single audio
stream (the native language of the speaker) is coupled with the media stream
by using MID. All the rest should not be synchronized.

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

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[email-masked]] 
Sent:	Thursday, June 21, 2001 11:17 AM
To:	'Gonzalo Camarillo'; Joerg Ott
Cc:	Orit Levin; [email-masked]; [email-masked]
Subject:	RE: New version of FID. WAS (Re: FID Draft - again)

A few comments:

1. Some more information on usage with SIP is needed. Specifically, a few
things need to be added:

  a. how is the response constructed? Does the mid value for a stream need
to be the same as in the INVITE? Does the FID/LS groups need to be the same
in the response as in the INVITE? If I refuse a stream (by stting the port
to zero), do I need to include the mid value? Do I need to include that
stream in any groups?

  b. If the caller doesn't support this stuff, you need to clearly state
that the callee CANNOT insert the mid and FID/LS attributes.

  c. If several streams are alternates (groupe=FID), can you switch between
them mid-call? Or, does the called party have to select one and use that one
for the remainder of the call?

2. In section 4.2, you talk about DTMF in the app components architecture.
Its important to note that app components doesn't depend on FID. In the
cases where a media server needs to receive a DTMF stream for features, this
is a parallel media stream, not an alternate, and so fid is not needed. The
only case its needed is if a media server wants an entire copy of the media
stream, and would like DTMF to go to one port or address, and regular speech
to another.

3. I'm still a bit puzzled about the lip sync. I am still looking for a
concrete example of where a single session has multiple media streams which
are not all lip-synced. Orit provided the following example:

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

OK, so in this case, the SIP session between each participant and the media
server has a single video stream, and multiple audio streams. Each audio
stream has a different MID, and there is an FID group listing all of those
(which means you should choose ONE of those audio streams). Now, whichever
you end up using, the audio and video stream is lip-synced. I don't see why
an additional parameter is needed.

I don't really feel strongly, and will happily agree to having it in there
if its needed. But, I would like to see an example where it is definitely
needed, and can't be done in some other way. 

Thanks,
Jonathan R.

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

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, June 18, 2001 12:51 PM
> To: Joerg Ott
> Cc: Orit Levin; [email-masked]; [email-masked]
> Subject: New version of FID. WAS (Re: FID Draft - again)
> 
> 
> Hello,
> 
> > Gonzalo will submit a draft that generalizes the fid field 
> to allow for
> > 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
> -- 
> 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: Fri, 22 Jun 2001 23:32:22 +0200

> by using MID. All the rest should not be synchronized.

One could argue (I did not do so in my initial reply and I'd be happy not
to fight over this one) that whether or not applying lip-sync here does
not make that big a difference in terms of endpoint requirements (you'd
do it if this was the right stream) or processing (you are getting only
one audio stream anyway).  So why are you worried at all?
The worst thing to happen is that you get your audio at the same time
as all those listening to the original speaker (instead of a translator),
which might be a couple of milliseconds earlier as opposed to waiting for
the video.  Well...

There is one further possible difference though: if you have the original
speaker's audio and video (originating e.g. from the same machine) you
don't have to have NTP wallclock time (or some other synch'ed time)
between all the translators' RTP senders and the original speaker.

(But what if you have different original speakers with different languages?
I suppose your conferencing server is to deal with this kind of nastyness)

I also don't feel strongly about this particular issue.  However, I do on
the overall document and, as Jonathan already pointed out, there is still
some work to do.  More comments to follow.

Joerg