Subject: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Aug 2013 16:14:28 +0000

Hi,

It has been indicated that POFs (partial offers) and PANs (partial answers) form a stand-alone mechanism, instead of being an extension of RFC3264.

Now, assuming that is true, we still need to describe the interaction between POFs, PANs and 3264 Offer/Answers.

Because, if I send a POF, and then receive a 3264 Offer (including the same m- line as the POF),  there is a glare and I need to reject the 3264 Offer.

In the same way, if I send a 3264 Offer, and receive a POF (including the same m- line as the 3264 Offer), there is a glare and I need to reject the POF.

I ASSUME the above is clear to everyone, including the authors of the UP, but IF someone has a different opinion I'd like to hear about it :)

Regards,

Christer

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Aug 2013 18:31:17 +0200

I agree with Christer.

I wonder if Adam is assuming that the Offers, Answers, POFs, and PANs 
used in WebRTC are all serialized over a reliable channel? That would 
simplify things because it will ensure how they relate to one another, 
though it doesn't prevent the glare Christer describes.

If this is totally discarding 3264, then I *guess* you could define that 
O/A is only used once, and after that changes are made exclusively with 
POFs and PANs. But I don't have the sense that is being proposed.

IMO it makes much more sense to analyze this as an extension to 3264.

I also think these POFs and PANs should have the o-line to confirm what 
prior SDP the new one updates. (It is more important than it is with 
regular O/A.)

	Thanks,
	Paul

On 8/6/13 6:14 PM, Christer Holmberg wrote:
>
> Hi,
> It has been indicated that POFs (partial offers) and PANs (partial
> answers) form a stand-alone mechanism, instead of being an extension of
> RFC3264.
>
> Now, assuming that is true, we still need to describe the interaction
> between POFs, PANs and 3264 Offer/Answers.
> Because, if I send a POF, and then receive a 3264 Offer (including the
> same m- line as the POF),  there is a glare and I need to reject the
> 3264 Offer.
> In the same way, if I send a 3264 Offer, and receive a POF (including
> the same m- line as the 3264 Offer), there is a glare and I need to
> reject the POF.
> I ASSUME the above is clear to everyone, including the authors of the
> UP, but IF someone has a different opinion I'd like to hear about it :)
> Regards,
> Christer
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Aug 2013 18:02:28 +0000

Of course, in some cases (e.g. in JSEP) there might not even be a need to distinguish between POFs/PANs and 3264 Offer/Answers.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: [email-masked] [[email-masked]]
Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers
I agree with Christer.

        Thanks,
        Paul

On 8/6/13 6:14 PM, Christer Holmberg wrote:
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com<http://www.nitrodesk.com>)
>
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Aug 2013 18:30:35 -0500

On 8/6/13 11:14, Christer Holmberg wrote:
> answers) form a stand-alone mechanism, instead of being an extension 
> of RFC3264.
>

That is certainly what I had been assuming. Of course, if the POF is a 
new m-line (that is, it doesn't appear in the offer coming the other 
way), then there is no glare condition.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2013 06:39:34 +0000

Hi,
 
> That is certainly what I had been assuming. Of course, if the POF is a new m-line (that is, it doesn't appear in the offer coming the other way), then there is no glare condition.

Correct - assuming that the addition of the new m- lines does not indirectly affect values etc associated with existing m- lines.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Aug 2013 15:27:11 +0200

What about adding a new m-line into a bundle?
IIUC this is likely to be one of the most important use cases.
Can this all be done with POF and PAN?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2013 15:25:02 +0000

Hi,

> Can this all be done with POF and PAN?

I have been thinking about that, because BUNDLE is one example where a change to one m- line may have impacts on other m- lines.

Also, my understanding of the UP is that a PAN can only contain m- line that were present in the POF. So, if the POF triggers additional m- lines to be changed on the remote side, those m- lines cannot be placed into the PAN.

Regards,

Christer

---

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

> It has been indicated that POFs (partial offers) and PANs (partial answers) form a stand-alone mechanism, instead of being an extension of RFC3264.

uh, I don't think so. THey seem sot be an optional extension to 3264

---

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

Hi,
 
> uh, I don't think so. THey seem sot be an optional extension to 3264

Well, that is not what was indicated during the meeting (if we don't count Hadriel :)...

Anyway, I guess that is part of the solution discussions. But, whatever it's an extension or not, I don't think it changes the fact that there will interactions between POF/PANs and 3264 O/As.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Aug 2013 17:02:26 +0200

> Anyway, I guess that is part of the solution discussions. But, whatever it's an extension or not, I don't think it changes the fact that there will interactions between POF/PANs and 3264 O/As.
My impression is that we're defining a new mechanism that contains 
3264-style O/A *and* POF/PAN.

Applications will then either use that mechanism or use 3264 only 
(analogous, kind of, to applications either using RTP/AVP or RTP/AVPF).

So I see no "interaction" as such, but the semantics of the new 
mechanism have to be defined, and, if we intend it for use in SIP, how 
to negotiate its use has to be defined.

---

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

Hi Harald,

>> My impression is that we're defining a new mechanism that contains 3264-style O/A *and* POF/PAN.
>
> Applications will then either use that mechanism or use 3264 only (analogous, kind of, to applications either using RTP/AVP or RTP/AVPF).
>
> So I see no "interaction" as such, but the semantics of the new mechanism have to be defined, and, if we intend it for use in SIP, how to negotiate its use has to be defined.

The problem with SIP is that, in certain situations (e.g. in a (re-)INVITE request or response), you are REQUIRED to send an Offer. Now, whether that Offer must be a 3264 Offer, or if some "type" of Offer is also allowed, I don't know :)

Regards,

Christer