Subject: [MMUSIC] Semantics of an "m=" line

From: Emil Ivov <[email-masked]>
Date: Mon, 15 Jul 2013 20:44:28 +0200

Hey all,

Just submitted a new draft that should server as a basis for discussion 
on "m=" line semantics in offer answer:

http://tools.ietf.org/html/draft-ivov-mmusic-multiple-sources-00

The goal of the draft is to discuss the use of "m=" lines by 
Offer/Answer according to their original design in SDP: as envelopes for 
RTP sessions with any number of SSRCs.

In many ways, this new document describes the basis of "No Plan" but in 
a generic way, not related to WebRTC.

Feedback is welcome and hopefully we will be able to also discuss this 
in Berlin.

Cheers,
Emil
-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2013 16:01:33 -0400

Emil,

This is a useful draft. It makes some good point. I have some 
comments/questions:

Section 1:

    o  the addition or removal of simulcast or layered streams must be
       possible without the need for Offer/Answer exchanges beyond the
       initial declaration of such capabilities for either direction.

ISTM that simulcast needs more discussion - it is nuanced. E.g. the 
following are all things one might like to say about simulcast:
- I am sending the same thing in multiple formats. You can pick
   the one(s) you want to receive. (Especially for broadcast/multicast)

- I am preparted to send the same thing in multiple formats.
   You can pick the one(s) you want me to send.

- I want to receive a single source in multiple formats.

Certainly there is need for the simulcast indication in SDP for the 
multicast case. And probably in some of the others. But I am not 
convinced it is always necessary for simulcast to be indicated in SDP. 
In some cases, there may be no need for the receiver to know that two 
streams it is receiving happen to be simulcasts on one another. And in 
other cases it will already know by some means. (Which is your point.)

Also Section 1:

    o  application specific signalling should be used to cover most
       semantics following call establishment, such as adding, removing
       or identifying SSRCs;

I think this is the controversial point. In *some* cases, where the 
semantics are complex and dynamic, this makes sense. But there are no 
doubt many cases that are relatively simple, where its much more 
convenient to do something in SDP than it is to define a new application 
channel to negotiate this.

Section 4: Demuxing and Identifying Streams

The demux based solely on PT is fine if bundling is only used to combine 
m-lines with different media types. In that case there will be at most 
one bundled m-line per top level mime type. And this satisfies my 
requirement that it always be possible to map a packet to an m-line.

But if bundling is used for any other reason, then the number of likely 
m-lines goes up, and the acceptability of unique PTs goes down. Then the 
discussion changes.

I don't think the description of what must be done is quite right. You 
don't quite say what a depacketizing/decoding/processing chain *is*. Do 
you intend this as a *type* of chain, or an *instance* of a chain? I 
think it has to be *instance*. E.g. there may be two VP8 chains, with 
all the same settings, but processing different flows. Simplistically, 
you might say that the *type* of chain can be determined by the PT, and 
the *instance* of that chain can be determined by the SSRC.

But typically such chains would be assigned based on where they are 
intended to be rendered. (Equal number of chains and renderers.) So when 
a new SSRC is received, and there is no matching chain, then either it 
must be dropped, or else some existing chain must be reconfigured to 
process this SSRC. This may need to happen without any additional out of 
band info to help. How do you imagine this being done? (In simple cases 
this might be done by *policy*. But I don't know if that is enough.) Is 
it your position that if this can't be done by policy then there must be 
some application-specific signaling mechanism to do it?

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Tue, 16 Jul 2013 23:52:01 +0200

Hey Paul,

On 15.07.13, 22:01, Paul Kyzivat wrote:
> ISTM that simulcast needs more discussion - it is nuanced.

Completely agreed.

> E.g. the

Yes.

> channel to negotiate this.

I agree and the draft doesn't try to argue against this. I suppose in 
these cases SDP can be viewed as *the* application specific signalling.

When doing this however, it would make sense to have a fallback 
strategy. That is, unless I know that the remote party supports these 
stream control semantics, I most not rely on them and I stick to the 
basic offer/answer exchange. That's what we generally do with new 
Offer/Answer features, right?

> m-lines goes up, and the acceptability of unique PTs goes down. Then the

I agree, with the same comment as above: you should only use multiple 
"m=" lines for the same media type if you know that your peer would 
understand what this means. If not then you stick to one "m=" line per 
type and add an option indicating you support a multi-line mechanism.

This multi-line mechanism, like for example Plan A (a.k.a. "unified 
plan"), will then define demux procedures that work with it.  Does this 
make sense?

> you intend this as a *type* of chain, or an *instance* of a chain?

I am not sure I understand how you define type and instance. Do you get 
one chain type per media type? If so, then I meant type.

> I

Yes agreed. The point of the draft is that you use PT to find a chain 
type. You can then use whatever you want (e.g. SSRC) to map to a 
specific instance. That part does  not need to happen in SDP though.

> some application-specific signaling mechanism to do it?

Yes exactly. Note in this case application-specific does not have to 
mean SIP or XMPP. It can also be RTP header extensions, a semi-dynamic 
policy downloadable over http or even SDP (although, as Roni mentioned, 
you can have the same problem there).

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

-- 
https://jitsi.org