Subject: [MMUSIC] Partial Offer/Partial Answer draft

From: Adam Roach <[email-masked]>
Date: Mon, 14 Oct 2013 17:50:31 -0500

I have submitted a document that formally describes the procedures for 
using partial offers and partial answers within the RFC 3264 framework. 
There were already several comments on the mechanism from its 
description in the unified plan, and I believe that these have all been 
incorporated as either improvements or clarifications. If I missed 
something, please let me know.

As we discussed in Berlin, the real impetus for this work is for use in 
RTCWEB. The document is written in a way that considers its potential 
application to SIP; however, I do not mean to imply that adding a 
partial offer/partial answer mechanism in SIP is by any means a foregone 
conclusion.

There are a number of open issues in the document, all of which should 
be clearly marked with an "OPEN ISSUE:" tag. If time allows, I plan to 
release a -01 version of the document that includes a set of relevant 
examples ahead of the draft deadline next Monday; however, I cannot 
promise that I will have time to do so. If I do, the _only_ changes will 
be in section 6, so any notes that you make should transfer over 
(including section, page, and paragraph number).

If you have time before Vancouver, please post thoughts on the MMUSIC 
mailing list. Thanks.

http://www.ietf.org/id/draft-roach-mmusic-pof-pan-00.txt

/a

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Oct 2013 17:18:40 -0700

> http://www.ietf.org/id/draft-roach-mmusic-pof-pan-00.txt

If I read this correctly, that first open issue is a real humdinger.
It's going to be a deal-breaker if it means that I can't add new lines
to an existing BUNGLE group.

I was tempted to suggest that you include all session-level a= lines,
but that's going to expose you to glare on the same scale as
unmodified 3264 O/A.  I'm going to need to noodle on this for a while,
because until that issue is resolved, this doesn't really solve the
problem.

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Oct 2013 19:22:47 -0500

It's certainly not unsolvable, it's just unsolved. From an information perspective, it can be done unambiguously. We just need to come up with an elegant syntax.

/a

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Oct 2013 17:28:55 -0700

> It's certainly not unsolvable, it's just unsolved. From an information perspective, it can be done unambiguously. We just need to come up with an elegant syntax.

Leaving impossibilities regarding the juxtaposition of the terms
"elegant syntax" and "SDP" aside, I don't disagree.  I'm just
disappointed that you didn't try.

>From an information perspective, would you consider a partial offer
that amends a group to (potentially) generate glare for all of the
lines already in that group?  E.g., I have a group of "a b c" and
generate a partial offer to add "d" to that group.  Does this cause
glare with an offer to amend any of "a", "b", or "c"?

I think that could be made to work, but I don't like the
ramifications.  Without further consideration, all I can envisage is
the creation of a new grouping semantic.  Maybe I'm just being a
little pessimistic.

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Oct 2013 22:27:46 -0500

> disappointed that you didn't try.

The issue here was actually having too many ideas, not lacking any; and 
spelling all of them out in formal detail would have made the "open 
issue" much larger than was reasonable. I briefly considered putting 
several of them into an appendix, but writing out these approaches at 
the level of formality worthy of a document would have delayed things by 
another day or two, and I already was running much later delivering this 
than I was happy with.

I'll sketch out three of the more interesting ways you can skin this cat 
below.

> glare with an offer to amend any of "a", "b", or "c"?

I would hate that.

> the creation of a new grouping semantic.  Maybe I'm just being a

I think so. Either that or just a bit unimaginative.

For the trivial case where we care *only* about being able to put new 
lines into bundles, we could very easily specify that any new media 
section that contains the same port as one or more other media sections 
is implicitly added to the same bundle as those media sections. It's an 
easy, clean, "done and done" solution. It's also very specific to 
solving the BUNDLE case (which is the must-have here) which means that 
it leaves any other grouping (LS, FID, SRF, ANAT, FEC, DDP) out to dry. 
For that reason, I don't think this is the approach we want.

The other two solutions that I would propose, which solve the general 
grouping case, are somewhat less elegant syntactically (all sniping 
aside), and vary primarily in how they choose to identify group lines. 
In the first case, you identify the a=group lines at the session level 
by the order in which they appear (the first one has an index of 1; the 
second has an index of 2; and so on).

Then, we could do something like define a new attribute, valid only in 
sdpfrag, and stripped out between partial processing and incorporation 
into the overall session, that indicates "this media section is also 
added to the indicated group."

For example, if you had an ongoing session that looked like this (yeah, 
I'm just grabbing from RFC 5888 because it's the easiest way to 
demonstrate my point, although I've changed the MIDs to match the notion 
of randomness that pof/pan calls for):

v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
m=audio 30000 RTP/AVP 0
a=mid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
m=video 30002 RTP/AVP 31
a=mid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V

And wanted to add a new video stream to the LS group, you could send a 
partial offer like:

m=video30004 RTP/AVP 31
a=mid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO
a=add-group:1

And that would mean "add this media to the first a=group line that is 
indicated at the session level," resulting in an final session that 
looks like this:

v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO
m=audio 30000 RTP/AVP 0
a=mid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
m=video 30002 RTP/AVP 31
a=mid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
m=video  30004 RTP/AVP 31
a=mid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO

(Note the on the a=group line is different than it had been before; also 
note that the third m-section does not include an "a=add-group" 
attribute, even though one was present in the partial offer).

An alternate approach, if we think that the use of numerical indices to 
point to the group we're talking about, is to instead say "add to the 
group that is uniquely identified as containing at least the following 
MIDs (and probably some others too)." For this example, the end result 
is the same, but the "add-group" attribute would instead look something 
like this:

a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V

Which means "there is only one LS group that contains the MID 
8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V, and this media section should be added 
to it." If the combination of LS and "8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V" 
were not sufficiently unique to identify the group, then the attribute 
would include enough other MIDs until the group were uniquely 
identified; e.g.:

a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V 
ZLSQLQ*YBSYMLZD4ETXME5892052JKRN

And so on. If, by some fluke, you wanted to add a new media section to a 
group that happened to be of the same type as another group whose 
members were a strict superset of the group you wanted to talk about, 
you'd have to fall back to a full offer. This is such an extreme corner 
case, however, that I don't think it bears much hand-wringing to worry 
about the glare that might result from such a situation.

For both of these last two cases, we would probably want to allow a 
partial offer or partial answer to also include an "a=group" at the 
session level, but only if it is defining a completely new group (i.e., 
not expanding an existing group). If we do this, we might choose to 
allow such POFs and PANs to incorporate media sections that aren't 
described in the sdpfrag (that is, existing and otherwise unmodified 
media sections). This does make the index-based approach to indicating 
group lines a bit more fiddly, as we need to define a canonical ordering 
for group lines in the rare circumstance that both sides try to add a 
new group simultaneously. As with this issue itself, it's an eminently 
solvable problem, but it *is* more specification and more code.

Of these three approaches, which I think are the most promising of the 
ones I've been able to come up with, I personally like the last one 
(where you describe a group by its type and the smallest set of MIDs 
required to uniquely identify it). I suspect they could all be refined 
and made slightly more elegant if we had enough people put their minds 
to the issue.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Oct 2013 16:04:49 +0000

Hi,

> glare with an offer to amend any of "a", "b", or "c"?

Well, there are cases where the adding of "d" could implicitly affect "a", "b" and/or "c".

Example:

    - Assume you use BUNDLE, and "a", "b" and "c" have previuosly been added to a BUNDLE group, sharing a single address.

    - Then, Alice sends a POF, which adds "d" to the BUNDLE group, AND also requests the "d" address to become the new BUNDLE address.

    - If the new address is approved by the answerer (Bob), that means that the address of "a", "b" and "c" will implicitly change.

    - Now, if Bob at the same time sends a POF in the other direction, towards Alice, modifying "a", "b" and/or "c", there might be a glare situation, in which Alice should reject the POF.

The easiest way to prevent this would be to say that an Offer/POF, MUST include all m- lines which may be affected (explictily or implicitly) by the Offer/POF.

Maybe change of BUNDLE address isn't the most realistic example, but there are also SDP attributes etc which must be identical for each m- line within a BUNDLE group, etc.

Regards,

Christer

I would hate that.

For the trivial case where we care *only* about being able to put new lines into bundles, we could very easily specify that any new media section that contains the same port as one or more other media sections is implicitly added to the same bundle as those media sections. It's an easy, clean, "done and done" solution. It's also very specific to solving the BUNDLE case (which is the must-have here) which means that it leaves any other grouping (LS, FID, SRF, ANAT, FEC, DDP) out to dry. For that reason, I don't think this is the approach we want.

The other two solutions that I would propose, which solve the general grouping case, are somewhat less elegant syntactically (all sniping aside), and vary primarily in how they choose to identify group lines. In the first case, you identify the a=group lines at the session level by the order in which they appear (the first one has an index of 1; the second has an index of 2; and so on).

Then, we could do something like define a new attribute, valid only in sdpfrag, and stripped out between partial processing and incorporation into the overall session, that indicates "this media section is also added to the indicated group."

For example, if you had an ongoing session that looked like this (yeah, I'm just grabbing from RFC 5888 because it's the easiest way to demonstrate my point, although I've changed the MIDs to match the notion of randomness that pof/pan calls for):

v=0

And wanted to add a new video stream to the LS group, you could send a partial offer like:

m=video 30004 RTP/AVP 31

And that would mean "add this media to the first a=group line that is indicated at the session level," resulting in an final session that looks like this:

v=0

(Note the on the a=group line is different than it had been before; also note that the third m-section does not include an "a=add-group" attribute, even though one was present in the partial offer).

An alternate approach, if we think that the use of numerical indices to point to the group we're talking about, is to instead say "add to the group that is uniquely identified as containing at least the following MIDs (and probably some others too)." For this example, the end result is the same, but the "add-group" attribute would instead look something like this:

Which means "there is only one LS group that contains the MID 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V, and this media section should be added to it." If the combination of LS and "8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V" were not sufficiently unique to identify the group, then the attribute would include enough other MIDs until the group were uniquely identified; e.g.:

a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V ZLSQLQ*YBSYMLZD4ETXME5892052JKRN

And so on. If, by some fluke, you wanted to add a new media section to a group that happened to be of the same type as another group whose members were a strict superset of the group you wanted to talk about, you'd have to fall back to a full offer. This is such an extreme corner case, however, that I don't think it bears much hand-wringing to worry about the glare that might result from such a situation.

For both of these last two cases, we would probably want to allow a partial offer or partial answer to also include an "a=group" at the session level, but only if it is defining a completely new group (i.e., not expanding an existing group). If we do this, we might choose to allow such POFs and PANs to incorporate media sections that aren't described in the sdpfrag (that is, existing and otherwise unmodified media sections). This does make the index-based approach to indicating group lines a bit more fiddly, as we need to define a canonical ordering for group lines in the rare circumstance that both sides try to add a new group simultaneously. As with this issue itself, it's an eminently solvable problem, but it *is* more specification and more code.

Of these three approaches, which I think are the most promising of the ones I've been able to come up with, I personally like the last one (where you describe a group by its type and the smallest set of MIDs required to uniquely identify it). I suspect they could all be refined and made slightly more elegant if we had enough people put their minds to the issue.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Oct 2013 11:13:38 -0500

On 10/15/13 11:04, Christer Holmberg wrote:
> - Then, Alice sends a POF, which adds "d" to the BUNDLE group, AND 
> also requests the "d" address to become the new BUNDLE address.

I think you've simply identified one more class of thing we need to 
prohibit in a partial offer. Either that or:

> The easiest way to prevent this would be to say that an Offer/POF, 
> MUST include all m- lines which may be affected (explictily or 
> implicitly) by the Offer/POF.

Which I think would work, but (for the cases we care about for WebRTC, 
at least) would be approximately as likely to glare as a full offer.

/a

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 09:47:34 -0700

> I'll sketch out three of the more interesting ways you can skin this cat

The solution with no syntax is somewhat tempting, but - at least
academically - it seems nice to be able to negotiate the inclusion of
new m-sections in groups.

I think that your other two solutions are the same solution, and both
do what I had hoped to avoid, which is create another way to get to
a=group.  I concede that the general approach is sound hough.  I've a
third way of doing that, which commits the cardinal sin of ignoring
RFC5888 and replicates functionality.  But your two options kinda did
that anyway (and so did similar things I came up with).

m=whatever ...
a=mid:cnp2346987
a=rgroup:BUNDLE w3nv567890 <- same
m=something ...
a=mid:5709gw78v45
a=rgroup:BUNDLE w3nv567890 <- identifier

That fixes a problem that I've had with 5888 for a long time: the lack
of a stable identifier.  Eventually all things need identifiers.
Using indices or references to other members of groups is indirect and
brittle.

This doesn't allow for ordering of groups, which is a good thing, even
if it does make the selection of the bundle address harder, but that
might be achieved by the use of a new attribute.

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Oct 2013 12:05:12 -0500

On 10/15/13 11:47, Martin Thomson wrote:
> I've a

True, but this has its own point of brittleness: if a media section is 
part of two groups of the same type, you're back to the issue of not 
being able to clearly indicate which of the groups this rgroup attribute 
applies to.

If we can accept the constraint of each media group only belonging to 
(at most) one group of each type, then any single member of a group is 
sufficient to serve as a unique identifier.

/a

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 10:53:19 -0700

On 15 October 2013 10:05, Adam Roach <[email-masked]> wrote:
> True, but this has its own point of brittleness: if a media section is part
> of two groups of the same type, you're back to the issue of not being able
> to clearly indicate which of the groups this rgroup attribute applies to.

This specifically avoids that brittleness - the identifier in the
a=rgroup: is an identifier for the *group*, so if a media section is
part of two groups of the same type, then it's going to get two
different group identifiers.

m=whatever
a=mid:blah
a=rgroup:LS groupA
a=rgroup:LS groupB

Rather than identify one member of a group in order to identify the
group by proxy, it identifies the group directly.  The cost is that
you can't use 5888 any more.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Oct 2013 18:07:33 +0000

Hi,

In BUNDLE we talk about "adding of media description" and "disabling of media description", rather than adding and removal of streams.

I think it would be useful, and more clear, to use similar terminology in the POF/PAN spec.

It has been commented that the the word "remove" can confuse people, as media descriptions aren't removed (eventhough the associated streams may be).

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Oct 2013 13:20:41 -0500

> you can't use 5888 any more.

Oh, I see. You're throwing 5888 out the window. I specifically didn't 
want to do that. The approaches I described were meant to be a means of 
communicating incremental changes to existing 5888 groups in a way that 
otherwise maintained 5888 processing as-is.

I think this is somewhere that backwards compatibility is actually 
somewhat important.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Oct 2013 19:02:28 +0000

Hi,

> at least) would be approximately as likely to glare as a full offer.

It would be nice to get some input on what people want to do with POF/PANs.

Yes, they want to add streams etc, but exactly what information do they need to be able to modify when doing that.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Oct 2013 14:08:13 -0500

> It would be nice to get some input on what people want to do with 

Paging Justin Uberti...

/a

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 13:25:05 -0700

On 15 October 2013 11:20, Adam Roach <[email-masked]> wrote:
> Oh, I see. You're throwing 5888 out the window. I specifically didn't want
> to do that. The approaches I described were meant to be a means of
> I think this is somewhere that backwards compatibility is actually somewhat
> important.

Yep, intentionally.  I think that the effect of what you have proposed
is the same, or close enough that it doesn't matter I'm just being
more honest about it.

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 15 Oct 2013 13:28:07 -0700

I think this needs to be discussed a bit more

As i see, we have following scenarios

1. Adding a new stream
     ==> This corresponds to adding a new source and hence new m= line

2. Deleting a already existing stream
    ==> This is undoing #1 i.e remove the source altogther from input.
           This is typically implemented by setting Port to Zero for the
corresponding to the m=line

3. Disabling an already Existing stream
    ==> This is where things get little murky and it depends on the
use-case I believe.
            One use-case is if the user wanted to put the stream on hold.
This can be done via direction attribute (preferred) vs setting port to
zero ( not preferred)

4. Enabling a disabled stream
    ==> This again undoes #3.

Having said that, this is what I propose
- Add/Remove stream corresponds to source coming and going away
- Enable/Disable corresponds to stream being used or not given that source
still is connected to the session.

Any thoughts ?

Cheers
Suhas

On Tue, Oct 15, 2013 at 11:07 AM, Christer Holmberg <
[email-masked]> wrote:

>   Hi,
>
>
>
> In BUNDLE we talk about "adding of media description" and "disabling of
> media description", rather than adding and removal of streams.
>
>
>
> It has been commented that the the word "remove" can confuse people, as
> media descriptions aren't removed (eventhough the associated streams may
> be).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Oct 2013 20:34:37 +0000

Hi,

In BUNDLE disable means putting the port to zero.

But, again, BUNDLE does not talk about streams, but about media descriptors (m- lines).

Regards,

Christer

________________________________
From: Suhas Nandakumar [[email-masked]]
Sent: Tuesday, 15 October 2013 11:28 PM
To: Christer Holmberg
Cc: Adam Roach; [email-masked]
Subject: Re: [MMUSIC] POF/PAN Editorial: Allign with BUNDLE terminology

1. Adding a new stream

2. Deleting a already existing stream
    ==> This is undoing #1 i.e remove the source altogther from input.
           This is typically implemented by setting Port to Zero for the corresponding to the m=line

3. Disabling an already Existing stream
    ==> This is where things get little murky and it depends on the use-case I believe.
            One use-case is if the user wanted to put the stream on hold. This can be done via direction attribute (preferred) vs setting port to zero ( not preferred)

Having said that, this is what I propose
- Add/Remove stream corresponds to source coming and going away
- Enable/Disable corresponds to stream being used or not given that source still is connected to the session.

Any thoughts ?

Cheers
Suhas

On Tue, Oct 15, 2013 at 11:07 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Oct 2013 15:40:19 -0500

On 10/15/13 15:25, Martin Thomson wrote:
>> Oh, I see. You're throwing 5888 out the window.
>> ...
> is the same, or close enough that it doesn't matter

How so? With what I propose, the resulting SDP that each side has at the 
end of the transaction is identical to that which would result from a 
full offer/answer exchange using RFC5888.

/a

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 13:45:56 -0700

On 15 October 2013 13:40, Adam Roach <[email-masked]> wrote:
> How so? With what I propose, the resulting SDP that each side has at the end
> of the transaction is identical to that which would result from a full
> offer/answer exchange using RFC5888.

That's only true through synthesis.  A process that is more
deterministic with what I propose.

Both rely on synthesis, I just went from a sometimes dependency to an
always dependency.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Oct 2013 17:19:10 -0400

Adam,

I was pretty down on the initial proposal. It seemed like too much of a 
hack. But with this writeup its looking more plausible. Here are 
comments that I collected while reading:

General comments:

I believe it is valid to have multiple mid lines per media section. In 
that case, which one is used for ordering? What if I want to move a mid 
line from one media section to another, or remove one?

Simple answer: doing anything with multiple mids per m-line, changing 
mids, and moving mids from one m-line to another can only be done with a 
full O/A.

The use of the term "remove" to describe setting the m-line port to zero 
(many places) seems inappropriate and confusing, since the m-line 
remains. I suggest using "deactivate" or "reject" instead.

Section 1:

In the following:

    Many of the emerging uses for both SIP and RTCWEB involve sessions
    with a large number of media streams, with streams being added and
    removed frequently.  This kind of session churn increases the
    incidence of glare significantly.

s/incidence of/potential for/

(While the number of changes is relevant, its the likelihood that the 
changes on both ends are synchronized that makes the most difference. 
For unsynchronized changes to glare the fraction of session time spent 
changing streams must be negligible.)

Section 3.2:

I don't understand the open issue. How do stream changes result in glare?

Then, in:

    If the recipient of a partial offer that contains an existing MID has
    also sent a partial offer to change that exact same stream, and
    neither the received nor the sent partial offer contains an
    "a=inactive" attribute, then a legitimate glare condition has arisen.

Why is a=inactive an exception? Where are the special rules for it?

Section 5.2:

The restriction to changing a *single* media section per partial offer 
is intended? What is wrong with changing several media sections in the 
same partial offer? (Other than increasing the possibility of glare.)

I'm bothered by the use of random values for the new mid values. (I just 
hate *depending* on two random values being different.) Instead, how 
about specifying that each end use a unique prefix. We can find some 
method to select the prefix. E.g., userid + sessionid from the o-line. 
(Forbid use of partial offers if those aren't unique.)

Section 5.3:

I think you need to s/less than/less than or equal to/ in:

    The agent then examines the o= line in the received partial offer.
    If the <sess-version> value is less than the most recently
    received full (non-partial) offer or answer, then the partial offer
    is stale and MUST be rejected.

Section 5.4:

The following:

    When a partial answer is received, the offerer matches each media
    section in the partial answer to its corresponding media section
    according to its MID.

doesn't specify the source of the media sections to match against. I 
think you mean "to its corresponding media section in the partial offer".

Section 5.5:

The following:

    Whenever a partial offer or partial answer is processed, the agent
    performs the following steps to ensure that a common view of session
    state is maintained:

doesn't say *when* this will be done. IIUC this is to be done by the 
offerer upon successful receipt of the partial answer, and by the 
answerer upon the sending of the partial answer. Right?

Steps 3 & 4:

Deciding *when* to do this is tricky. I don't know exactly what you have 
in mind. I do have an idea for a simpler way:

For all partial updates following a particular O/A, order *all* the 
added media sections by their mid value. A new O/A then freezes those 
and starts over.

That's all.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 14:32:17 -0700

On 15 October 2013 14:19, Paul Kyzivat <[email-masked]> wrote:
> hate *depending* on two random values being different.)

But I really like that part.  There's more than a little schadenfreude
involved though.  I know that this irritates people.

Tell you what, I'll bet that you won't find a collision.

What annoys *me* is the requirement to use all 79 characters.  The
only way to do that efficiently is to waste good random entropy.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 14:34:34 -0700

> But, again, BUNDLE does not talk about streams, but about media descriptors

I'm sure that you can work this out.

http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-02

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Oct 2013 18:06:54 -0400

> Tell you what, I'll bet that you won't find a collision.

Probably not. But I don't believe in using "probably" when deciding if 
things work. (I'm ok with it when people are satisfied with being told 
that the algorithm "probably" works.)

I'm still expecting to have trouble breathing sometime because all the 
air randomly decided to move to the other side of the room. :-)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2013 06:48:37 +0000

Hi,

Eventhough there might not be a collision, I think there can be ambiguity (as defined in section 3.1 of POF/PAN).

Example:

- Alice sends a POF (mid=x) to Bob. At the same time Bob sends a POF (mid=y) to Alice.
- Bob sends a PAN to Alice's POF.

Now, Alice does not know whether Bob sent his POF before he received Alice's POF.  Alice may make assumptions based on the order she receives the POF and PAN, but that is not necessarily the same order in which they were sent by Bob.

So, Alice and Bob (not to mention possible intermediaries) may have different views on whether there were ambiguity or not, which may affect in which order they add the m- lines to the "session SDP":

- If Alice receives the PAN before the POF, she may assume there was no ambiguity, and assume order x, y.
- If Bob receives Alice's POF before he receives the PAN to his own POF, he will trigger the procedures for ambiguity, which may result in order y, x (based on the lexical comparison).

Please let me know if you didn't understand the use-case, and I'll try to draw a picture :)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 16. lokakuuta 2013 1:07
To: [email-masked]
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft

On 10/15/13 5:32 PM, Martin Thomson wrote:
>> I'm bothered by the use of random values for the new mid values. (I 
>> just hate *depending* on two random values being different.)
>

Probably not. But I don't believe in using "probably" when deciding if things work. (I'm ok with it when people are satisfied with being told that the algorithm "probably" works.)

I'm still expecting to have trouble breathing sometime because all the air randomly decided to move to the other side of the room. :-)

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Oct 2013 03:35:40 -0500

> Now, Alice does not know whether Bob sent his POF before he received Alice's POF.  Alice may make assumptions based on the order she receives the POF and PAN, but that is not necessarily the same o…

Ah, I'd meant to mention that we need to ensure reliable, in-order 
delivery of POFs and PANs, and that the higher-level protocol is 
responsible for doing so. All of the processing is based on this rather 
important assumption.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Oct 2013 10:29:10 -0500

On 10/14/13 17:50, Adam Roach wrote:
> If time allows, I plan to release a -01 version of the document that 
> includes a set of relevant examples ahead of the draft deadline next 
> Monday...

...and, thanks to Suhas, I now have those examples in the document. The 
only changes in this version are in section 6 and later (although I do 
note that adding a second author has changed the pagination slightly):

http://www.ietf.org/id/draft-roach-mmusic-pof-pan-01.txt

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Oct 2013 11:28:15 -0500

On 10/15/13 16:19, Paul Kyzivat wrote:
> I believe it is valid to have multiple mid lines per media section.

I don't think that's right. I'll admit that RFC5888 doesn't specifically 
talk about ordinality, but there is strong implication here that we're 
required to have a one-to-one relationship. Consider the language:

    In a given
    session description, each "m" line is identified by a token, which is
    carried in a "mid" attribute below the "m" line.

We're always talking about these things in the singular when referring 
to their use in a media section. If we need to make this constraint an 
explicit precondition for using partials, than I'm okay doing so -- but 
I don't think it's really a constraint above and beyond what's implied 
by RFC 5888 itself.

> The use of the term "remove" to describe setting the m-line port to 
> zero (many places) seems inappropriate and confusing, since the m-line 

Sure, I'm okay making that editorial change.

> I don't understand the open issue. How do stream changes result in glare?

I send you a partial offer to set a sendrecv stream to sendonly at the 
same time as you send me a partial offer to change that very same stream 
to inactive.

> Why is a=inactive an exception? Where are the special rules for it?

Ah, crap. I missed one. This was copied from unified plan, where I had 
conflated a=inactive (mute stream) with port=0 (remove stream). This 
should read "...contains a port of zero..."

> same partial offer? (Other than increasing the possibility of glare.)

That's the open issue from section 3.2. I just didn't tag it as open in 
both places -- I figured pointing it out the first time we talk about 
the issue would be enough.

And, yes, it's all about glare. After all, the entire raison d'etre for 
this mechanism is glare minimization.

> just hate *depending* on two random values being different.) Instead, 
> how about specifying that each end use a unique prefix. We can find 
> some method to select the prefix. E.g., userid + sessionid from the 
> o-line. (Forbid use of partial offers if those aren't unique.)

Sure, we can consider alternate proposals for this. I'll point out that 
you're more likely to have a collision between {userid,sessionid} of two 
clients than you will from 202 bits of randomness (which is what is 
currently proposed). Consider that sessionid is (supposed to be) derived 
from a notion of the current time, so the chances of colliding are 
exceedingly high. Similarly, the userid for SDP is frequently a fixed 
string rather than some variable string.

Your misgivings aside, I'm pretty much in the camp that believes that 
math works, even the statistics and probability parts of it.

I'd be more interested in entering into a conversation about how many 
bits of randomness are acceptable. I'm pretty sure 202 is massive 
overkill. Version 4 UUIDs, for contrast, use 122 bits of randomness, 
which we would get with 20-character SDP tokens. Given their limited 
scope (just one session), we could probably get away with far less than 
this.

>    is stale and MUST be rejected.

Sure. "Equal to" would only arise from a misimplemented peer, but I'm 
happy to just call it stale.

> think you mean "to its corresponding media section in the partial offer".

Yep, that was the intention. I'll make this clearer.

> answerer upon the sending of the partial answer. Right?

Right; in both cases, after all other processing described in this 
document has taken place.

> Steps 3 & 4:
>
> Deciding *when* to do this is tricky. I don't know exactly what you 
> have in mind. I do have an idea for a simpler way:
>

That occurred to me, mostly because it allows for multiple partial 
offers to be in flight simultaneously in the same direction.

What concerned me was the difficulty in dealing with such freezes 
between sending a full offer and receiving its corresponding full 
answer, since any glare that arises from that exchange requires 
unfreezing the lines, but only back to the point that was created after 
the (now second-) most recent offer/answer exchange.

I also didn't like the way it interacted internally with our own 
implementation, since we would have a pretty hard time re-ordering 
streams after we brought them up and running. It's not too painful to do 
this upon processing of an answer (particularly because we've already 
seen the other side's offer, and know where each line is going to end up).

It's not impossible to fix, but it sure would be more complicated and 
bug-prone. I don't expect we're the only ones who would run into 
difficulty in this arena, especially since I know we share this part of 
our code with a major hardware vendor who is active in the WebRTC space.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Oct 2013 17:39:30 +0000

Hi,

> I don't think that's right. I'll admit that RFC5888 doesn't specifically talk about ordinality, but there is strong implication here that we're required to have a one-to-one relationship. Consider the language:
>
>    In a given
> We're always talking about these things in the singular when referring to their use in a media section. If we need to make this constraint an explicit precondition for using partials, than I'm okay doing so -- but I don't think it's really a constraint above and beyond what's implied by RFC 5888 itself.

Is it allowed to have multiple instances of ANY attribute (in case of a=fmtp, for any given PT value) for any given m- line?

> Sure, I'm okay making that editorial change.

I suggest using "disable", in order to be aligned with BUNDLE (or, we'll change the terminology in BUNDLE).

> this mechanism is glare minimization.

Some time ago, I raised a question related to this, whether it would be allowed to send a POF including ALL m- lines of the session (in other words: sending a POF which is identical to a full Offer).

(Of course, that would defeat the whole purpose of POF/PAN.)

> happy to just call it stale.

I don't think one should reject an equal value. 

WHY one would send a POF with an equal sess-version, I don't know, but perhaps for "auditing"...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Oct 2013 13:48:15 -0400

> I don't think it's really a constraint above and beyond what's implied

My thinking was that when grouping is being used for multiple purposes, 
each might use its own mid values.

The requirement that to use grouping at all every m-line must have a mid 
decreases the motivation to do that. And certainly a single mid is 
*sufficient*. But its hard to contemplate what all possible 
implementations might do.

Rather than *assuming* 5888 forbids multiple mids, or updating to to 
make that explicit, I think its easier to just say that you can't use 
partials if there are multiple mids for any m-line.

Even then, I don't think that 5888 requires that the mids in a 2nd offer 
must be the same, or in the same order, as in the prior offer. I don't 
think you depend on that, but it is worth keeping in mind.

> same time as you send me a partial offer to change that very same stream

OK.

> this mechanism is glare minimization.

I guess this is just a question of whether you want to protect people 
from themselves, or give them enough rope to do good and bad things.

If multiple changes were *permitted*, then an application that wants to 
minimize the glare can restrict itself to one change per pof. Some other 
application, that has special knowledge about the usage may know that 
certain combinations of changes have low probability of glaring.

> string rather than some variable string.

Obviously some other value could be used. All we need is a unique 
designator for each end within the single session. Then all the mids can 
be derived from that. Each one doesn't need to be random.

For instance, we could call the offering end of the most recent O/A "O" 
and the answerer for that "A". And then each side could use that as a 
prefix for all new mids assigned by POFs from that side.

> math works, even the statistics and probability parts of it.

And I'm in the camp that never gambles.

Statistics says that even exceedingly low probability events *can* 
happen. Its ok to count on low probability events not happening if you 
are willing to accept the consequences when they do happen. Even if that 
is only expected to happen once in a trillion years, that doesn't mean 
you have to wait a trillion years for it to happen. It could be tomorrow.

> happy to just call it stale.

Oh. Duh. You are right. Leave as it is.

> the (now second-) most recent offer/answer exchange.

I don't see the problem. After sending a full offer everything *is* 
frozen until the the answer is accepted or rejected. That's true without 
POF/PAN.

Or do you mean that you are accepting and queuing *pending* partial 
updates while waiting for the answer? But that doesn't seem like an 
issue either. Just defer assigning the mids until the POF is to be sent.

> our code with a major hardware vendor who is active in the WebRTC space.

I won't argue with this. But it does need to be traded off against the 
issue in the note. That seems to have similar problems.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Oct 2013 13:58:36 -0400

> Is it allowed to have multiple instances of ANY attribute (in case of a=fmtp, for any given PT value) for any given m- line?

Sure. Some examples:

- label
- candidate
- ssrc

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Oct 2013 13:28:31 -0500

On 10/17/13 12:48, Paul Kyzivat wrote:
> My thinking was that when grouping is being used for multiple 
> purposes, each might use its own mid values. 

Again, that's not really supported by any of the text in RFC5888.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Oct 2013 18:36:33 +0000

Hi,

> purposes, each might use its own mid values.

Why would that be needed? A mid is only a reference, and I see no reason why you couldn't use the same value in multiple groups - as long as the value refers to the same m- line.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Oct 2013 15:00:57 -0400

> Again, that's not really supported by any of the text in RFC5888.

True. But it also doesn't forbid it.

Its pretty clear that it didn't consider the possibility of multiple mid 
lines per m-line.

I won't belabor the point.

	Thanks,
	Paul