Subject: [MMUSIC] POF/PAN draft update

From: Adam Roach <[email-masked]>
Date: Fri, 14 Feb 2014 15:43:19 -0800

I've updated the partial offer/partial answer draft to reflect the 
conversations we had in Vancouver:
http://tools.ietf.org/html/draft-roach-mmusic-pof-pan-02

Diffs: http://tools.ietf.org/rfcdiff?url2=draft-roach-mmusic-pof-pan-02.txt

Note that this relies on the following draft for group membership 
manipulation:
http://tools.ietf.org/html/draft-roach-mmusic-groupid

Please point out whether you think I've missed any of the Vancouver 
discussions or other feedback. Thanks!

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 16 Feb 2014 18:35:02 -0500

This is one comment about this draft. I've separated it out to keep 
conversation threads distinct.

Many places in this draft refer to attributes of "the SDP". For 
instance, in section 3.2:

    ...  Assuming the recipient does not
    have an outstanding, unanswered partial offer that also modifies that
    exact same stream, this media section is treated as an independent
    renegotiation of that stream.  The SDP version is increased, and an
    answering media section is created for inclusion in the resulting
    partial answer.  ...

In this paragraph, what does "the SDP version is increased" mean? 
Presumably the recipient is retaining some state about the history of 
O/A exchanges, and this means that the state is to be updated. But AFAIK 
this is not explicitly documented. That state might include:

- the last full local SDP sent in an O/A exchange
- the last full remote SDP received in an O/A exchange
- a "current" full local SDP, including PANs sent and POFs sent that
   received good PANs, since the last full local SDP was sent
- a "current" full remote SDP, including PANs received and POFs
   received for which good PANs were sent, since the last full remote
   SDP was received
- some state of POFs outstanding that have not yet received PANs.

Some saved SDP state is identified in rfc3264. There is "previous SDP" 
(of self), and also "previous SDP of the offerer".  A more complex state 
model is needed to support use of POF/PAN, in the procedures of several 
sections.

(I didn't use "previous" in my list above. In order to dovetail with 
3264 I suspect that what I have called "current full local SDP" should 
correspond to "previous SDP" of self, and "current full remote SDP" 
should correspond to "previous SDP of offerer" when a full offer is 
received.)

I think it is important to make a state model explicit, to properly 
support what the procedures are referring to, though the one I sketch 
may not be quite right.

	Thanks,
	Paul

On 2/14/14 6:43 PM, Adam Roach wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 16 Feb 2014 18:38:36 -0500

Another comment on this draft:

While the mechanism described in this draft is strongly motivated by 
BUNDLE, it is conceptually independent of BUNDLE. IMO all the 
BUNDLE-specific behavior should be removed from this draft, and instead 
placed into the BUNDLE draft.

I realize there is a chicken/egg thing here. It would make sense to keep 
the bundle-specifics here, so they don't get forgotten, until they are 
incorporated into the bundle draft.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Sun, 16 Feb 2014 20:49:11 -0800

On 2/16/14 15:35, Paul Kyzivat wrote:
> what does "the SDP version is increased" mean?

Sorry, I mean the <sess-version> from the "o=" line:

    <sess-version> is a version number for this session description.  Its
       usage is up to the creating tool, so long as <sess-version> is
       increased when a modification is made to the session data.

I'll make this more explicit in the next version.

> support what the procedures are referring to

That's a very good point, since it will help us identify where we might 
have some holes in how things need to be handled. I'll make a run at 
defining a state diagram for POF/PAN.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Feb 2014 16:26:15 -0500

> defining a state diagram for POF/PAN.

I'm less concerned with a state *diagram* than I am in specifying what 
state must be retained and which of it is used for each step. But both 
may be useful.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Feb 2014 04:19:45 +0100

On 02/17/2014 12:38 AM, Paul Kyzivat wrote:
> BUNDLE-specific behavior should be removed from this draft, and
> instead placed into the BUNDLE draft.
>
> I realize there is a chicken/egg thing here. It would make sense to
> keep the bundle-specifics here, so they don't get forgotten, until
> they are incorporated into the bundle draft.

If moving the BUNDLE-specific stuff to the BUNDLE draft means that
BUNDLE is dependent on completion of POF/PAN before considered
completed, I'm strongly opposed to this.

BUNDLE should not depend on POF/PAN. If BUNDLE-specific aspects of
POF/PAN need to be broken out, there needs to be a third draft that
references both.

>> Diffs:
>> http://tools.ietf.org/rfcdiff?url2=draft-roach-mmusic-pof-pan-02.txt
>>

-- 
Surveillance is pervasive. Go Dark.