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

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 15:10:42 +0000

Hi,

I realize we are still far from having a working partial O/A solution, and MMUSIC may not even be the place to discuss it, but I think we need to warm up our brains a little, so I'll throw out a ball related to the semantics :)

When reading the UP draft, I can't find any restrictions on how many m- lines a partial offer can contain.

So, I assume that means I can send a partial offer which contains ALL m- lines of my session SDP, i.e. it would look like a vanilla 3264 offer?

Now, WHY would I do that? Well, if we are going to use something more "lightweight" than re-INVITE/UPDATE to send partial offers, that may be a good reason.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 15:17:43 +0000

Note that my re-INVITE/UPDATE example is based on the assumption that one can use partial offers/answers with SIP, on the wire. Not sure if that was part of the agreed scope for the UP.

But, even without that, I think the question on including all m- lines on a partial offer still applies :)

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [[email-masked]]
To: mmusic [[email-masked]]
Subject: [MMUSIC] UP: Can a partial offer be a full offer?

Hi,

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 05 Aug 2013 10:20:21 -0500

On 8/5/13 10:17, Christer Holmberg wrote:
> Note that my re-INVITE/UPDATE example is based on the assumption that 
> one can use partial offers/answers with SIP, on the wire. Not sure if 
> that was part of the agreed scope for the UP.

 From the phrasing the chairs used when asking the question, my 
understanding is that it's not. That doesn't mean that SIPCORE won't 
decide to come along and do it at some point in the future, but it's a 
different question for a different time.

> on a partial offer still applies :)

Yeah, I'm pondering this. I'll try to respond when I have my thoughts 
gathered.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 11:34:21 -0400

> Note that my re-INVITE/UPDATE example is based on the assumption that one can use partial offers/answers with SIP, on the wire. Not sure if that was part of the agreed scope for the UP.

Definitely NOT agreed on.  Doesn't mean it won't happen in the future, but the scope of UP was limited to WebRTC for now.  We can debate which parts of UP are generically applicable, and which not.  For SIP, this isn't the right WG for that debate.

> But, even without that, I think the question on including all m- lines on a partial offer still applies :)

I don't see why WebRTC would restrict itself in any way regarding the number of m-lines in a partial offer/answer.  Nothing "breaks" if all m-lines are in it, does it?  The real question is if it can be greater than *one* m-line.  If it can, and I think it can, then I can't see how the exact quantity of them matters.  The only downside is you increase the chance of glare, I assume.

Afaik, the 'mid' attribute is there to identity which m-lines in the partial offer correspond to which m-lines in the full ordered set. (the 'mid' could have even been an index number, except it's also used to avoid glare when adding m-lines, which a numeric index wouldn't have done)  So what's the issue with one or multiple m-lines?

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 16:35:12 +0000

Hi,

I see no issue with multiple m- lines - just wanted to verify that it would be allowed :)

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: mmusic [[email-masked]]
Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer?

-hadriel

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 13 Aug 2013 22:54:10 +0000

You only want to send the m blocks that have changed because if you send other ones, you up the chances of both sides sending the same m block at the same time and being back into the glare problem. 

It seems to me the options are either 1 or 2 would make sense 

1)  the sender SHOULD only send m m blocks with a change (which might be all of them) and receiver MUST be prepared to receive any number. 

2) you can only send one m block in  a partial Off or Ans - but you can have several outstanding at a time

On Aug 5, 2013, at 10:35 AM, Christer Holmberg <[email-masked]> wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 01:32:32 +0200

A related thing that affects this:

session level attributes that affect each media level. E.g., session 
level c-line.

Do we assume that you must send a full offer to change such things?
(Of course you might choose to avoid this.)

Another thing: ISTM that every POF and PAN whould carry an o-line. That 
will indicate what it updates. And each one then needs to increment the 
sequence number.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Aug 2013 07:35:03 +0000

Hi,

It is ok to only send m- line(s) that are changed.

But, again, when you in a POF/PAN change on m- line explicitly, other m- lines may be changed implicitly. So, if you at the same time explicitly (using a separate POF/PAN) also try to change those other m- line, there will be a collision.

Or, as Paul says, if multiple simultaneous POF/PANs change session level information, there will be collision.

MAYBE we could restrict usage of POF/PANs, and say that they MUST NOT be used to change session level information...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Aug 2013 17:50:30 -0400

> MAYBE we could restrict usage of POF/PANs, and say that they MUST NOT be used to change session level information...

I was assuming it was obvious that this must not be the case.
The POFs and PANs (AFAIK) only contain the media sections they intend to 
change, so they don't contain the session level stuff.
If you change session level stuff, then you should need a real offer.

Or is somebody suggesting to analyze the changes, and discover that some 
session level things don't apply to all media sections (e.g., because 
the media section overrides them, or they just aren't pertinent for that 
kind of media) and so you can send a POF that includes just the session 
level stuff and the media sections that are affected. ???

I don't think much of that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Aug 2013 06:19:32 +0000

Hi,

> The POFs and PANs (AFAIK) only contain the media sections they intend to change, so they don't contain the session level stuff.

Keep in mind that the o- line, which IS session level, IS modified each time a POF/PAN is sent.

Maybe we should use media level o- lines for POFs/PANs....

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Aug 2013 09:34:13 -0400

> Keep in mind that the o- line, which IS session level, IS modified each time a POF/PAN is sent.

Good point.

> Maybe we should use media level o- lines for POFs/PANs....

I don't know how you could do that in a backward compatible way.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Aug 2013 10:33:11 -0400

> I don't know how you could do that in a backward compatible way.

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.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Aug 2013 13:24:30 -0400

> 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 a…

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.

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. And when that stuff is used in a 
full O/A, there need to be rules for how those are reconciled.

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

It might be possible to arrange so that it won't be seen by an endpoint 
that doesn't support POFs/PANs, but that will take some care, and is 
likely to be fragile.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Aug 2013 15:21:44 -0400

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

> 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