Subject: RE: FID Draft - again

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

Hi guys!
Are we expected to repeat the reasons again and again?

Rereading version 01, I can see a single purpose: Introduction of "Fid"
allows for switching between different codecs based NOT on RTP payloads (as
in plain SIP today) but on a separate UDP port assignment by the receiver.

May be I am missing something, but does this feature alone justifies the
extension? Do other needs for coupling of media streams (simplest
asymmetrical communications, lip-synch, "comedia" modes, etc.) are less
imperative? May anybody in our industry today take the responsibility for
prioritizing them?

And all this when the more general definition is as simple as the original
one? (I hope that those who implemented the "fid" already would bear this
one.)

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

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 9:52 AM
To: Joerg Ott
Cc: [email-masked]; [email-masked]
Subject: Re: FID Draft - again

Hello Joerg,

Since we have not received any comments during the last week, I guess we
should proceed to WG last call with the 01 version of the draft.

Best regards,

Gonzalo

Joerg Ott wrote:
>
> All:
>
> After the debate on the mailing list, we have exchanged a couple of
further
> messages -- and I have received a few comments privately, in favor of and
> against extending the scope of fid.
>
> I would like to briefly re-examine the issue to come to a conclusion on
this:
>
> The idea present on the table for quite some time now, implemented by
various
> companies, and agreed upon at the last IETF is a single attribute a=fid:
to
> identify different RTP media sessions that belong together and may be used
> to convey the same information.
>
> The extension as proposed by Orit and backed by a number of other is to
> generalize the fid field (and possibly call it "mid") and devote two
> attributes to describe what the semantics are.  As a result, each media
> description can be coupled with one or more other media descriptions.
>
> The purpose to support lip sync has different semantics than purpose of
fid
> for alternate codecs.  While one performs a logical grouping of media
streams
> conveying complementary information (e.g. audio and video) (fid for lip
sync),
> the other defines a way to identify alternative streams to convey the same
> information.  The semantics is to be expressed by means of an a=fpar:
attribute
> (indicating "lip sync" or "application specific" or something else).
> More than one of such groupings shall be allowed per stream.
>
> For basic SIP multimedia calls the problem is currently solved by having
> one m= audio and one m= video lines in the SDP and implicitly assuming
> that those streams belong together.  If you propose multiple media streams
> of a single type, something like the attribute suggested by Orit is needed
> to associate two or more media streams.  This would allow you to have e.g.
> two m= audio and two m= video lines -- and you could tell which ones
belong
> together (but it does by no means support assigning any particular
semantics
> to either of the media streams).
>
> What I have not seen so far, however, is an argument that we are solving a
> real world problem right now by doing the extension.  Whicj kind of
> application (of today or tomorrow, not next week) do you have in mind
> where you convey multiple multimedia stream descriptions between two
> SIP UAs?
>
> I can see a distinction between two cases:
>
> a) Conference Bridge
>
> Assume I have a conference bridge (which seems to be the primary
motivation
> at the moment).  In this case, I may be offering a number of audio and
video
> codecs to each conference participant and let them choose independently.
> Nevertheless, I am offering exactly one peer of media streams to each
> participant, irrespective of the codec chosen.  You would imply that you
> are to correlate those two media streams (similarly to many other implicit
> assumptions of using SDP).  Now if your conference bridge does not perform
> mixing or switching of any kind, you have the CNAME/SSRC identifiers of
the
> various streams to match them at the receiver.  (Note that different
logical
> sources at a single host could well use different CNAMEs.)
>
> What do you need the lip sync field for?
>
> b) Media streams between two gateways
>
> In case you have two media gateways (or two conference bridges) I can only
see
> a potential need if you were carrying several media stream peers as part
of the
> same call.  Again, you have the CNAME/SSRC fields for identification.
>
> In any case, I assume you could use multipart bodies with several SDPs to
> have all the grouping you need for the moment -- if all you want to do is
> lip sync for several simultaneous media streams between two peers.
>
> I don't want to argue this idea to death -- but I want to get a clear
feeling
> that what we are doing here is really necessary.
>
> In the meantime, Gonzalo Camarillo has been so kind to volunteer to
compile
> a merged version of both proposals (if needed) -- but, again, I'd like to
be
> sure that this is needed.
>
> We will move ahead with a consensus either way -- but none of those
speaking
> in favor of the extension on the list have made a clear case so far why
they
> need this very feature and why it can't be done in a different (already
> defined or implied way).
>
> And I would like to repeat that we'd prefer to have people contribute to
SDPng
> instead of arguing that it is prelimenary right now and that they need
INTERIM
> solutions.
>
> Cheers,
> Joerg
>
>   ------------------------------------------------------------------------
>
> Subject: FID Draft - again
> Date: Fri, 01 Jun 2001 16:34:20 +0200
> From: Joerg Ott <[email-masked]>
> Reply-To: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Followup-To: [email-masked]
>
> Here comes a proposed mail for the mailing list.  Please comment.
> (not to be run THROUGH Colin, actually... ;-)
>
> Any comments?
>
> Thanks,
> Joerg
>
>
----------------------------------------------------------------------------
>
> All:
>
> After the debate on the mailing list, we have exchanged a couple of
further
> messages -- and I have received a few comments privately, in favor of and
> against extending the scope of fid.
>
> I would like to briefly re-examine the issue to come to a conclusion on
this:
>
> The idea present on the table for quite some time now, implemented by
various
> companies, and agreed upon at the last IETF is a single attribute a=fid:
to
> identify different RTP media sessions that belong together and may be used
> to convey the same information.
>
> The extension as proposed by Orit and backed by a number of other is to
> generalize the fid field (and possibly call it "mid") and devote two
> attributes to describe what the semantics are.  As a result, each media
> description can be coupled with one or more other media descriptions.
>
> The purpose to support lip sync has different semantics than purpose of
fid
> for alternate codecs.  While one performs a logical grouping of media
streams
> conveying complementary information (e.g. audio and video) (fid for lip
sync),
> the other defines a way to identify alternative streams to convey the same
> information.  The semantics is to be expressed by means of an a=fpar:
attribute
> (indicating "lip sync" or "application specific" or something else).
> More than one of such groupings shall be allowed per stream.
>
> For basic SIP multimedia calls the problem is currently solved by having
> one m= audio and one m= video lines in the SDP and implicitly assuming
> that those streams belong together.  If you propose multiple media streams
> of a single type, something like the attribute suggested by Orit is needed
> to associate two or more media streams.  This would allow you to have e.g.
> two m= audio and two m= video lines -- and you could tell which ones
belong
> together (but it does by no means support assigning any particular
semantics
> to either of the media streams).
>
> What I have not seen so far, however, is an argument that we are solving a
> real world problem right now by doing the extension.  Whicj kind of
> application (of today or tomorrow, not next week) do you have in mind
> where you convey multiple multimedia stream descriptions between two
> SIP UAs?
>
> I can see a distinction between two cases:
>
> a) Conference Bridge
>
> Assume I have a conference bridge (which seems to be the primary
motivation
> at the moment).  In this case, I may be offering a number of audio and
video
> codecs to each conference participant and let them choose independently.
> Nevertheless, I am offering exactly one peer of media streams to each
> participant, irrespective of the codec chosen.  You would imply that you
> are to correlate those two media streams (similarly to many other implicit
> assumptions of using SDP).  Now if your conference bridge does not perform
> mixing or switching of any kind, you have the CNAME/SSRC identifiers of
the
> various streams to match them at the receiver.  (Note that different
logical
> sources at a single host could well use different CNAMEs.)
>
> What do you need the lip sync field for?
>
> b) Media streams between two gateways
>
> In case you have two media gateways (or two conference bridges) I can only
see
> a potential need if you were carrying several media stream peers as part
of the
> same call.  Again, you have the CNAME/SSRC fields for identification.
>
> In any case, I assume you could use multipart bodies with several SDPs to
> have all the grouping you need for the moment -- if all you want to do is
> lip sync for several simultaneous media streams between two peers.
>
> I don't want to argue this idea to death -- but I want to get a clear
feeling
> that what we are doing here is really necessary.
>
> In the meantime, Gonzalo Camarillo has been so kind to volunteer to
compile
> a merged version of both proposals (if needed) -- but, again, I'd like to
be
> sure that this is needed.
>
> We will move ahead with a consensus either way -- but none of those
speaking
> in favor of the extension on the list have made a clear case so far why
they
> need this very feature and why it can't be done in a different (already
> defined or implied way).
>
> And I would like to repeat that we'd prefer to have people contribute to
SDPng
> instead of arguing that it is prelimenary right now and that they need
INTERIM
> solutions.
> Cheers,
> Joerg

--
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: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Jun 2001 22:27:43 +0300

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

---

From: Joerg Ott <[email-masked]>
Date: Mon, 18 Jun 2001 09:11:33 +0200

Orit,

> Are we expected to repeat the reasons again and again?
 
I wasn't specifically asking for the same arguments again.  I went through
a number of scenarios and, as outlined in my email, I did not find anything
that you could not do with SDP *and* implied meaning as opposed to current
SDP *and* stream-sync fid *and* implied meaning.  This is why I explicitly
said that I would like to see a particular case where you need this further
information.

> in plain SIP today) but on a separate UDP port assignment by the receiver.

Not entirely, the intention was to have other transport addresses included
-- which allows for what you describe but also for having a stream sent to
a different location.

> imperative? May anybody in our industry today take the responsibility for

Orit, I am very much in favor of doing general solutions to problems.  But
we are doing fixes here -- and only fixes.  And I would like to keep the
broadness of these, the possible ways of misuse or re-interpretation, etc.
to a minimum.  I don't want to have to maintain implementors guides at some
point that explain how you can do miraculous things with SDP by combining
what is there is weird ways and have to chase off people who come up with
even further ideas.  This is why I am being so conservative.

> one? (I hope that those who implemented the "fid" already would bear this

I agree that, literally, you are asking for a minor change only (but it bears
some risks).  And I pointed out, I am happy to go with consensus either way.
So if there is a real need for a broader extension then I may be convinced. 
But I would like to see the real need first.

Joerg