Subject: FID Draft - again

From: Joerg Ott <[email-masked]>
Date: Wed, 06 Jun 2001 14:01:01 +0200

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
From: Joerg Ott <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 01 Jun 2001 16:34:20 +0200

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Jun 2001 16:51:55 +0300

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:
>   ------------------------------------------------------------------------
> 
> Reply-To: [email-masked]
> CC: [email-masked]
> Followup-To: [email-masked]
> 

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