Subject: [MMUSIC] Feedback requested on requirements

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Apr 2013 11:30:09 -0400 (EDT)

Here are a few desiderata related to dealing with legacy devices, both
endpoints and intermediate devices:

   DES C3  Avoid using media types in m= lines other than audio and
      video unless required for user media, as some SBCs reject SDP that
      uses other media types.

   This desideratum was suggested by Hadriel Kaplan.

   DES C4  Any additional m= lines prescribed by the bundle mechanism
      should be ordered after the constituent m= lines.

   Many devices that have only one audio or video channel accept the
   first m= line with that media type and reject any further ones

   non-DES C5  SBCs generally pass through attributes that they do not
      understand.  SBCs generally pass through codec specifications that
      they do not understand, even if they are configured to transcode
      certain specific codecs.

   This non-desideratum was suggested by Hadriel Kaplan.

Comments?

Dale

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2013 09:16:58 -0700

C3 and C4 look good.

>       they do not understand, even if they are configured to transcode

I'm not sure how to parse this.  Is that a double-negative or just two
negatives for emphasis?

Do you intend to say that the solution should NOT rely on new
attributes because SBCs will suppress them, or that the solution is
permitted to use new attributes because SBCs are expected to pass
attributes.

Non-requirements and non-constraints are always difficult to get right.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Apr 2013 17:59:00 +0000

Hi,

>   This desideratum was suggested by Hadriel Kaplan.

I am not sure I understand. Why would one use media types unless required for user media?

>      should be ordered after the constituent m= lines.

That is normal Offer/Answer procedure, isn't it?

>   This non-desideratum was suggested by Hadriel Kaplan.

I don't understand this.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Apr 2013 14:58:26 -0400 (EDT)

> From: Martin Thomson <[email-masked]>
> 
> C3 and C4 look good.
> 

I mean the latter.  The intended parsing is:

    (non-DES) C5  SBCs generally pass through attributes that they do not...

That is, the possible requirements "Use only known attributes." and
"Use only known codecs." are not requirements.

> Non-requirements and non-constraints are always difficult to get right.

There needs to be a word for this...

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Apr 2013 15:35:02 -0400 (EDT)

> From: Christer Holmberg <[email-masked]>
> 

The MMT proposal (draft-holmberg-mmusic-sdp-mmt-negotiation-00) and
similar proposals add a separate media description (m= line section)
which describes the transport for the bundle as a whole.  The media
type specified by the m= line in such a media description is largely
arbitrary.  MMT specifies m=anymedia; m=multipart and m=application
have been proposed.

However, for compatibility with intermediate devices that remove media
descriptions other than m=audio and m=video, any "bundle" media
description should use either "audio" or "video" type.

> That is normal Offer/Answer procedure, isn't it?

If a "bundle" media description is to be added, it ought to be added
*after* the m= lines for the constituent media streams, so that the
"bundle" media description doesn't change which media description is
identified as "the first audio media description", "the second audio
media description", "the first video media description", etc.

> >   This non-desideratum was suggested by Hadriel Kaplan.

See my response to Martin Thompson.

I'm considering labeling this item "LATITUDE", meaning a range of
flexibility that the solution may exploit, as contrasted to
"DESIDERATUM", a constraint that we want the solution to obey.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Apr 2013 05:36:19 +0000

What do you mean by "known attribute" and a "known codec"? 

Any defined attribute/codec is "known".

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 23. huhtikuuta 2013 21:58
To: Martin Thomson
Cc: [email-masked]
Subject: Re: [MMUSIC] Feedback requested on requirements

That is, the possible requirements "Use only known attributes." and "Use only known codecs." are not requirements.

Dale
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Apr 2013 05:40:46 +0000

Hi,
 
>>>> Here are a few desiderata related to dealing with legacy devices, 
>>>> both endpoints and intermediate devices:
>>>
> The MMT proposal (draft-holmberg-mmusic-sdp-mmt-negotiation-00) and similar proposals add a separate media description (m= line section) which 
> describes the transport for the bundle as a whole.  The media type specified by the m= line in such a media description is largely arbitrary.  MMT 
> specifies m=anymedia; m=multipart and m=application have been proposed.
>
> However, for compatibility with intermediate devices that remove media descriptions other than m=audio and m=video, any "bundle" 
> media description should use either "audio" or "video" type.

Ok, now I get it :)

So, as we will not move forward with draft-bundle, I guess DES C3 is fulfilled, right?

> *after* the m= lines for the constituent media streams, so that the "bundle" media 
> description doesn't change which media description is identified as "the first audio 
> media description", "the second audio media description", "the first video media description", etc.

And, with "bundle" media description you refer to something like MMT, right? Ie m=anymedia, or something similar?

So, again, based on the decision to move forward with draft-bundle, I guess DES C4 does not apply, as we will not have a "bundle" media description to begin with?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Apr 2013 18:48:42 -0400

>      (non-DES) C5  SBCs generally pass through attributes that they do not...

What evidence do you have to support this assertion?
AFAIK this is far from universally true.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Apr 2013 18:58:30 -0400

> media description", "the first video media description", etc.

So, suppose A makes an offer to B with 4 m-lines to be bundled, with a 
5th "bundle" m-line after those.

But then suppose B needs those split into two bundles with different 
addresses.

B could accept the initial offer but reject m-lines 2 & 4. So then there 
is a bundle consisting of m-lines 1,3,5.

Then it might send another offer back toward A, reactivating m-lines 2 & 
4, and adding m-line 6 as the bundle m-line for the second bundle. 
Assuming A accepts that, then there will be two bundles, 1,3,5 and 2,4,6.

Is that consistent with what you are proposing here?

Or must m-lines 2&4 be abandoned, and the new bundle constructed from 
m-lines 6,7,8.

	Thanks,
	Paul

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 15:33:02 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>

> Is that consistent with what you are proposing here?

Yes, that seems consistent with this desideratum.  The "bundle" m=
lines are 5 (containing 1 and 3) and 6 (containing 2 and 4), and each
of them follows all of the constituent m= lines.  That makes it less
likely that a simple-minded UA considers m= lines 5 and 6 to be usable
media.

In this particular case, B might want to accept 2 and 4, but
disconnect them from the bundle (now containing 1 and 3 only).  Then B
could send a new offer bundling 2 and 4 separately.  That prevents an
interval during which 2 and 4 are inactive, which might not be the
semantics B wants to present to A.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 15:33:22 -0400 (EDT)

> AFAIK this is far from universally true.

That's what I've been told, but I haven't surveyed the market very
thoroughly.

What do you think would be a more accurate statement?

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 15:33:56 -0400 (EDT)

> Any defined attribute/codec is "known".

By "known attribute" I mean, "an attribute that we can expect most or
all SBCs to understand".

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 15:33:39 -0400 (EDT)

> So, as we will not move forward with draft-bundle, I guess DES C3 is

I'm not asking "Does the current proposal have this desideratum?" but
rather "Is this property, which I think we need, actually needed?"

In this instance, I'm trying to assess what the requirements on
MMT-style solutions would be.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Apr 2013 19:58:28 +0000

Hi,
 
> I'm not asking "Does the current proposal have this desideratum?" but rather "Is this property, which I think we need, actually needed?"

Fair enough, but currently we do have the property, no matter whether we think it's needed or not :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Apr 2013 20:00:35 +0000

Hi,

> By "known attribute" I mean, "an attribute that we can expect most or all SBCs to understand".

I'm a little lost. Why do we, in the bundle context, need to talk about which codecs SGCs understand? If the SGCs will process media on a codec level it will indicate in SDP which codecs it support.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Apr 2013 10:31:36 -0400

> What do you think would be a more accurate statement?

I think Hadriel may be better equipped to answer this.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 29 Apr 2013 18:00:16 -0400 (EDT)

> I'm a little lost. Why do we, in the bundle context, need to talk
> about which codecs SGCs understand? If the SGCs will process media
> on a codec level it will indicate in SDP which codecs it support.

If an SBC reprocesses media, then a bundled session can be initiated
through it only if the SBC explicitly supports bundle.

But if the SBC does not reprocess media, but only *edits* what media
descriptions it permits in the SDP that it passes through, then
bundling can succeed as long as the bundling specification does not
require any element that the SBC removes.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Apr 2013 07:31:24 +0000

Hi,

>> about which codecs SGCs understand? If the SGCs will process media on 
>> a codec level it will indicate in SDP which codecs it support.
>
> If an SBC reprocesses media, then a bundled session can be initiated through it only if the SBC explicitly supports bundle.
>
> But if the SBC does not reprocess media, but only *edits* what media descriptions it permits in the SDP that it passes through, 
> then bundling can succeed as long as the bundling specification does not require any element that the SBC removes.

I still don't get it :)

If an SBC needs to reprocess media, it obviously need to support the codecs used. But, that is true no matter whether BUNDLE is used or not.

Regards,

Christer