Subject: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Oct 2013 17:54:28 +0000

Hi,

The OPEN ISSUE in section 3 talks about how to deal with the SDP group attribute, which is a session-level information element (and, for that reason may not be allowed in a POF/PAN).

One of the issues is how to associate an m- line to a specific group, and there are some ideas on how to identity to which group(s) an m- line is added, without having to include the group attribute associated with the group.

However, at least for BUNDLE it is not enough to be able to identity the group: one also needs to specify the location of the m- line mid value in the group:BUNDLE mid value list.

One suggestion is to indciate the group only for new streams, which may solve some issues.. But, at least for BUNDLE that could result in a glare, if there is more than one POF adding a new stream to the BUNDLE group (and therefore updating the group:BUNDLE attribute) at the same time.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 21 Oct 2013 14:29:13 -0500

On 10/21/13 12:54, Christer Holmberg wrote:
> one also needs to specify the location of the m- line mid value in the 
> group:BUNDLE mid value list.

I don't believe that's true.

The only ordering consideration that I'm aware of for group:BUNDLE is 
that the first indicated mid is the one that the transport information 
is taken from. By the time we're into partial exchanges, the transport 
information for all the lines in the same bundle should be identical.

To ensure a common view of groups, we probably want to define things 
such that new lines added to a group are appended to the list. Is there 
any reason you can think this doesn't work for BUNDLE?

To be clear, let's set aside the prospect of changing transport 
addresses for a BUNDLE: I don't think it's unreasonable to require a 
full offer/answer exchange to do that kind of thing.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Oct 2013 15:57:39 -0400

> information for all the lines in the same bundle should be identical.

I guess that could be specified as a requirement for use of POF.

> full offer/answer exchange to do that kind of thing.

In conjunction with limiting to groups with all m-lines/ports the same, 
that does simplify things.

There remains the problem of indicating *which* (if any) group a newly 
added m-line joins.

There could be many group lines, even multiple with the same semantics. 
In particular there could be several independent bundles. There is 
nothing that is guaranteed to uniquely identify one of them.

The best I can see is to invent some new media-level attribute. For 
example, a=groupref. This could have the same syntax as a=group, but 
different usage. The 'semantics' and 'identification-tag's in it would 
be used to query a=group lines in the full SDP. Any that match would get 
the mid of this new m-line added. (This would allow you to say "I want 
this m-line bundled the same as this other m-line.) We might allow "*" 
to wildcard the semantics so you could add the m-line to different kinds 
of groups.

Of course there could be an error if this groupref didn't match 
anything. That could be defined to either fail, add to no group, or 
define a new group.

This would be a funny kind of SDP attribute, because it might not have 
meaning in a full SDP. (Or I guess it could be defined to work in a 
similar way. There would be some differences.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Oct 2013 20:00:48 +0000

Hi,

> is taken from.

If, for whatever reason, the Answerer does not/cannot choose the first in the list, it shall try the next in the list, etc.

But, that only becomes an issue when the BUNDLE address has yet not been negotiated - or when one tries to re-negotiate it (discussed below).

> By the time we're into partial exchanges, the transport

...assuming we don't also want to re-negotiate the BUNDLE address with the POF, in which case the POF might contain that new address.

But, as we discussed earlier, and as you also indicated at the end of your e-mail, maybe using POF for transport re-negotiation is something we can disallow.

> any reason you can think this doesn't work for BUNDLE?

I need to think about it, but nothing comes to my mind at the moment.

And, if both endpoints add a new m- line to the BUNDLE group at the same time, I guess the order in which they mids are appended to the list could be based on the order in which the m- lines themselves are added to the SDP state.

> full offer/answer exchange to do that kind of thing.

I agree.

Regards,

Christer

---

From: John Leslie <[email-masked]>
Date: Mon, 21 Oct 2013 17:53:45 -0400

> There remains the problem of indicating *which* (if any) group a newly 

   Not only don't I see an _answer_ to this -- I don't even think we have
a common understanding of the _question_.

   :^(

--
John Leslie <[email-masked]>

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 21 Oct 2013 15:05:01 -0700

On Mon, Oct 21, 2013 at 1:00 PM, Christer Holmberg <
[email-masked]> wrote:

> If, for whatever reason, the Answerer does not/cannot choose the first in
> the list, it shall try the next in the list, etc.
>
>
>
> But, that only becomes an issue when the BUNDLE address has yet not been
> negotiated - or when one tries to re-negotiate it (discussed below).
>
>
>
> ...assuming we don't also want to re-negotiate the BUNDLE address with the
> POF, in which case the POF might contain that new address.
>
>
>
> But, as we discussed earlier, and as you also indicated at the end of your
> e-mail, maybe using POF for transport re-negotiation is something we can
> disallow.
>
+1. Another side affect with this is, if the POF corresponds to m=line
whose mid is the first entry in the a=group:BUNDLE and this POF changes the
C= and Port field. Even in this, the BUNDLE draft might want to add a
requirement that it is disallowed for POF/PAN scenario.

> And, if both endpoints add a new m- line to the BUNDLE group at the same
> time, I guess the order in which they mids are appended to the list could
> be based on the order in which the m- lines themselves are added to the SDP
> state.
>

The draft discusses on the rules to append the m=lines based on the
lexically ordering of their mid values and the same rules applies here as
well. This would form common view in this case.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Oct 2013 18:29:10 -0400

> a common understanding of the _question_.

Here is an example:

a=group:bundle A B
a=group:bundle C D
m=audio ...
a=mid:A
m=audio ...
a=mid:B
m=video ...
m=mid:C
m=video ...
a=mid:D

Then we do a POF

m=video ...
a=mid:E

We want to add this to the 2nd bundle. How do we say that?
I'm suggesting:

m=video ...
a=mid:E
a=groupref:bundle C

The only a=group that matches that is the second one, so this implicitly 
updates that one to:

a=group:bundle C D E

Make sense? Its all a hack of course. But everything that is done to SDP 
is a hack.

	Thanks,
	Paul

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 21 Oct 2013 15:38:26 -0700

> Make sense? Its all a hack of course. But everything that is done to SDP

I think even this case can break if you use FEC based grouping mechanism

a=group:FEC-XR a b c
a=group:FEC-XR a d

now if we want to add the new "mid e" to the list where i have mid a listed
, we end up at the same point.

How about  we can extend groupref to include the entire group line as below

m=video ...
a=mid:E
a=groupref:FEC-XR a d

==> this would end up as
a=group:FEC-XR a b c
a=group:FEC-XR a d e   // new one added to the right line

>
>         Thanks,
>         Paul
>
>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 21 Oct 2013 17:47:08 -0500

On 10/21/13 17:38, Suhas Nandakumar wrote:
>
>
>
> On Mon, Oct 21, 2013 at 3:29 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         Paul Kyzivat <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>
>     The only a=group that matches that is the second one, so this
>     implicitly updates that one to:
>
>     a=group:bundle C D E
>
>     Make sense? Its all a hack of course. But everything that is done
>     to SDP is a hack.
>
>
> now if we want to add the new "mid e" to the list where i have mid a 
> listed , we end up at the same point.
>

This is giving me a strong sense of deja vu.

http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html

/a

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 21 Oct 2013 15:49:58 -0700

On Mon, Oct 21, 2013 at 3:47 PM, Adam Roach <[email-masked]> wrote:

> On Mon, Oct 21, 2013 at 3:29 PM, Paul Kyzivat <[email-masked]>wrote:
>
Completely agreed. It is the same solution.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Oct 2013 19:13:59 -0400

> http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html

Oops! You are right. I remember seeing that mail, but not reading it 
thoroughly. So either I remembered more than I thought, or else I 
reinvented it.

	Sorry,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Oct 2013 08:09:54 +0000

Hi,

I have to say that I don't like the idea of copy/pasting the group attribute, including the values, into the m- line (as a groupref attribute), just in order to indicate to which group an m- line shall be added.

It sounds very hacky to me. In addition, it would require string comparison just to identify the group. And, if a group contains multiple mid values (people have sometimes talked about tens, even hundreds, of mid values within a BUNDLE group), where the length of each mid value is 32 bytes, it will become a very heavy and clumsy procedure.

As Adam suggested in one e-mail, for BUNDLE one option could be to find the group based on the address properties (which must be identical for each m- line within a BUNDLE group, and identical for each BUNDLE group), ie there would be no need to explicitly indicate the group.

For other groups that may not work. But, again, POF/PAN does not have to be a mechanism which allows people to do "anything" - we need to collect the use-cases for which POF/PAN is required.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 22. lokakuuta 2013 2:14
To: Adam Roach; Suhas Nandakumar
Cc: mmusic WG
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?

> http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html

Oops! You are right. I remember seeing that mail, but not reading it thoroughly. So either I remembered more than I thought, or else I reinvented it.

	Sorry,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Oct 2013 10:58:59 +0000

"and unique for each BUNDLE group", that is.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 22. lokakuuta 2013 11:10
To: Paul Kyzivat; Adam Roach; Suhas Nandakumar
Cc: mmusic WG
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?

Hi,

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 22. lokakuuta 2013 2:14
To: Adam Roach; Suhas Nandakumar
Cc: mmusic WG
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?

	Sorry,
	Paul