Re: [MMUSIC] UP: Can a partial offer be a full offer?

[Hadriel Kaplan <[e-mail]>]

On Aug 21, 2013, at 1:24 PM, Paul Kyzivat <[e-mail]> wrote:

> On 8/21/13 10:33 AM, Hadriel Kaplan wrote:
>> Backward compatible to what?  There's no POFs/PANs thing today.  You don't even need to use SDP syntax if you don't want to, or you could use some diff-style format of SDP lines, or use what look and act exactly like SDP lines but aren't technically "SDP" to avoid any legacy RFC rules.
> 
> Maybe we are thinking of this differently, but my thinking is that consistency with a full SDP must be maintained. If you start off with an O/A, then some POFs/PANs, eventually you may need to do another O/A. And at that point there needs to be consistency.

Sure, the state changes and the rules that do that must be consistent.  The encoding syntax and rules for mandatory lines in a POF/PAN need not be. (not that I'm seriously proposing a different encoding syntax be created, but just saying "we aren't constrained to SDP offer/answer MUST rules for this POF/PAN piece")


> I think that means that POFs/PANs always contain a subset of a full SDP, and act as deltas, implicitly updating a full SDP. That means everything in the POFs/PANs needs to be valid SDP.

So are you saying it needs to contain an "v=", "s=", and "t=" lines?  Because those are mandatory for "SDP", afaik.  
[In fact afaict, technically "e=" and "p=" were mandatory originally, but RFC 3264 downgraded them to optional. (and then later RFC 4566 did the same for "SDP")]

This POF/PAN thing can pick+choose what pieces of SDP-ish stuff it needs to convey, and how.


> And when that stuff is used in a full O/A, there need to be rules for how those are reconciled.

Sure.

> So, to introduce a media level o-line, it would need to be defined for SDP too.

Or we could keep an o= line above the m= section of the POF/PAN, or define some other attribute altogether to perform the same function for the POFs/PANs and just define that it updates the sess-version value, or whatever.  My only point is we don't need to worry about backwards-compatibility.  We do need to worry about name collision with SDP, since we're using SDP syntax encoding.  But we could, for example, define attributes that are only usable for POFs/PANs and not full SDP O/A.

-hadriel