Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 18:11:55 +0000

Hi,

The draft says that one will use the "application/sdpfrag" MIME type value for POFs and PANs.

What about using "application/sdp" - ie the same MIME type value as for "normal" SDP Offers and Answers? From a SDP syntax perspective it should not be a problem - any SDP parser will be able to parse a POF/PAN.

An entity that does not support POF/PAN would probably trigger an error. BUT, maybe that is good: It could be a mechanism to verify that all SDP processing/inspecting entities along the signaling path actually support the mechanism. At least for SIP I can't think of any other mechanism to do that (we can't use Proxy-Require).

Comments?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Oct 2013 14:33:23 -0400

> An entity that does not support POF/PAN would probably trigger an error. BUT, maybe that is good: It could be a mechanism to verify that all SDP processing/inspecting entities along the signaling p…

It isn't the same as SDP. The SDP fragments aren't syntactically valid 
SDP - they are missing some mandatory fields.

Conceivably the POF/PAN stuff could require more, so that they are 
syntactically valid SDP. But do we want to?

And required processing is semantically different. If it were the same 
content type then some other means would be required to indicate that it 
is being used for POF/PAN, not offer/answer. Adam isn't talking about 
that part. In sip, that could be done via content-disposition.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 18:50:36 +0000

Hi,

>> An entity that does not support POF/PAN would probably trigger an error. BUT, maybe that is good: It could be a mechanism to verify that all SDP processing/inspecting 
>> entities along the signaling path actually support the mechanism. At least for SIP I can't think of any other mechanism to do that (we can't use Proxy-Require).
>>
>> Comments?
>
> It isn't the same as SDP. The SDP fragments aren't syntactically valid SDP - they are missing some mandatory fields.
>
> Conceivably the POF/PAN stuff could require more, so that they are syntactically valid SDP. But do we want to?
>
> And required processing is semantically different. If it were the same content type then some other means would be required to indicate that it is being used for POF/PAN, not offer/answer.

Well, for that there are many alternatives: SDP attribute, Content-XXX parameter, etc.

> Adam isn't talking about that part. In sip, that could be done via content-disposition.

Content-Disposition does not apply to intermediaries. So, a proxy that only understands application/sdp (e.g. for gate control purpose) will not even look at the C-D header field value for other bodies. And, unless such proxy understands POF/PAN, there may not be any media passing through...

Regards,

Christer

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Oct 2013 13:55:33 -0500

On 10/18/13 13:33, Paul Kyzivat wrote:
>> What about using "application/sdp" - ie the same MIME type value as 
>> for "normal" SDP Offers and Answers? From a SDP syntax perspective it 
>> should not be a problem - any SDP parser will be able to parse a 
>> POF/PAN.
>>
>> An entity that does not support POF/PAN would probably trigger an 
>> error. BUT, maybe that is good: It could be a mechanism to verify 
>> that all SDP processing/inspecting entities along the signaling path 
>> actually support the mechanism. At least for SIP I can't think of any 
>> other mechanism to do that (we can't use Proxy-Require).
>>
>> Comments?
>

This is exactly my sentiment as well.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Oct 2013 14:10:36 -0500

On 10/18/13 13:50, Christer Holmberg wrote:
> Content-Disposition does not apply to intermediaries. So, a proxy that 
> only understands application/sdp (e.g. for gate control purpose) will 
> not even look at the C-D header field value for other bodies. And, 
> unless such proxy understands POF/PAN, there may not be any media 
> passing through...

Right. A middlebox that doesn't understand application/sdpfrag won't 
know to look at its contents and let the new streams through. And a 
middlebox that sees something marked as "application/sdp" that conveys 
only a tiny fraction of the session will probably be just as 
catastrophic; I would imagine everything but the modified streams would 
be shut off. There's no way to win here.

At some point, we have to come to peace with the fact that any 
middleboxes that aren't primarily in the business of stifling progress 
will need to keep pace with protocol extensions as they get deployed.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 20:44:01 +0000

Hi,

> Right. A middlebox that doesn't understand application/sdpfrag won't know to look at its contents and let the new streams through. And a middlebox that sees 
> something marked as "application/sdp" that conveys only a tiny fraction of the session will probably be just as catastrophic; I would imagine everything but the 
> modified streams would be shut off. There's no way to win here.

I think it would reject the Offer - at least that's what it should do according to 3264.

> At some point, we have to come to peace with the fact that any middleboxes that aren't primarily in the business of stifling progress will need to keep pace with protocol extensions as they get deployed.

I really wish things worked that way :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Oct 2013 16:48:21 -0400

> Well, for that there are many alternatives: SDP attribute, Content-XXX parameter, etc.

Yes, though some more appropriate than others.

> Content-Disposition does not apply to intermediaries. So, a proxy that only understands application/sdp (e.g. for gate control purpose) will not even look at the C-D header field value for other bo…

Why do you say that C-D doesn't apply to intermediaries?
In general I would argue that intermediaries have no business caring 
about SDP at all, but that is now water over the dam.

If intermediaries are making decisions about the body, then they are 
obligated to really understand what the significance of the body is 
before messing with it. They have no business jumping to conclusions 
without considering all the factors that influence that.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Oct 2013 16:53:32 -0400

> I think it would reject the Offer - at least that's what it should do according to 3264.

3264 only talks about how to process offers and answers described in 
SDP. It does not say how those are conveyed in sip. 3261 says that they 
are carried in body parts of content-type application/sdp with 
content-disposition of 'session'. If a body part has content-type 
application/sdp but has a disposition other than 'session' then it isn't 
an offer or answer according to 3261, and so 3264 doesn't apply.

> I really wish things worked that way :)

So progress ends because middleboxes don't permit it?

Maybe you are right. Then sip will go the way of h323 while the world 
moves on to webrtc.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 21:06:13 +0000

Hi,

>>>> Content-Disposition does not apply to intermediaries. So, a proxy 
>>>> that only understands application/sdp (e.g. for gate control 
>>>> purpose) will not even look at the C-D header field value for other 
>>>> bodies. And, unless such proxy understands POF/PAN, there may not be 
>>>> any media passing through...
>>>
>>> middlebox that sees something marked as "application/sdp" that conveys only a tiny fraction of the session will probably be just as catastrophic; I would imagine everything but the modified streams would be shut off. There's no way to win here.
>>
> 3264 only talks about how to process offers and answers described in SDP. It does not say how those are conveyed in sip. 3261 says that they are carried in body parts of content-type application/sdp with 
> content-disposition of 'session'. If a body part has content-type application/sdp but has a disposition other than 'session' then it isn't an offer or answer according to 3261, and so 3264 doesn't apply.

3264 says that all m- line must be present in an Offer - even if they are not modified. So, what I meant was that in case all m- lines are NOT present (in the case of a POF), such Offer would be rejected - unless the middlebox understands the POF/PAN mechanism .
	
> Maybe you are right. Then sip will go the way of h323 while the world moves on to webrtc.

I think that getting explicit rejections, rather than having to try to figure out where things go wrong, is good for progress :)

Anyway, it wasn't really a suggestion - I just wanted to do some brainstorming :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 21:08:51 +0000

Hi,

>> Content-Disposition does not apply to intermediaries. So, a proxy that only understands application/sdp (e.g. for gate control purpose) will not even look 
>> at the C-D header field value for other bodies. And, unless such proxy understands POF/PAN, there may not be any media passing through...
>

I am saying that an intermediary that is only interested in application/sdp bodies (because that is where it assumes all SDP information is going to be carried) is not going to look at the C-D value associated with application/foo bodies.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Oct 2013 16:09:46 -0500

> I think it would reject the Offer - at least that's what it should do according to 3264.

The kinds of middleboxes you're talking about don't, in my experience, 
give much weight to anything written in any RFCs anywhere.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 21:16:13 +0000

Hi,

>The kinds of middleboxes you're talking about don't, in my experience, give much weight to anything written in any RFCs anywhere.

That's why Hadriel should write all our RFCs :)

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Oct 2013 16:17:25 -0500

On 10/18/13 15:53, Paul Kyzivat wrote:
>>> middleboxes that aren't primarily in the business of stifling 
>>> progress will need to keep pace with protocol extensions as they get 
>>> deployed.
>>

That only happens if we don't allow the behavior of deployed SIP 
middleboxes decimate WebRTC's capabilities.

So far, we've done a really bad job at preventing this. Certain parties 
have been taking the SIP SBC albatross and trying really hard to hang it 
on RTCWEB's neck. If we're serious about being able to do anything new, 
we need to push back.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Oct 2013 17:41:04 -0400

Christer,

I think you and I are thinking of this differently.

I'm thinking that the POFs and PANs are something new, different from 
offers and answers. They go on *between* offers and answers.

IIUC you are thinking of POFs and PANs as extended forms of offers and 
answers.

Conceptually the difference is insignificant. But practically the 
difference could be quite large regarding what changes need to be made 
to support it.

And practically it makes a difference regarding the detail of what goes 
inside a POF/PAN. (Do they have to be syntactically correct according to 
application/sdp?)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 21:55:12 +0000

Hi,

> I'm thinking that the POFs and PANs are something new, different from offers and answers. They go on *between* offers and answers.
>
> IIUC you are thinking of POFs and PANs as extended forms of offers and answers.

It's not the way I think - I just wanted to explore how/if things would work IF we were thinking like that, and what the pros and cons would be :)

We have to keep in mind that, no matter how we look at it, the Offers/Answers and POFs/PANs are tightly connected, meaning that they impact the same SDP state, can cause race conditions etc.

Regards,

Christer

On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>>>> purpose) will not even look at the C-D header field value for 
>>>>> other bodies. And, unless such proxy understands POF/PAN, there 
>>>>> may not be any media passing through...
>>>>
>>>> Right. A middlebox that doesn't understand application/sdpfrag 
>>>> won't know to look at its contents and let the new streams through. 
>>>> And a middlebox that sees something marked as "application/sdp" that conveys only a tiny fraction of the session will probably be just as catastrophic; I would imagine everything but the modified streams would be shut off. There's no way to win here.
>>>
>> SDP. It does not say how those are conveyed in sip. 3261 says that they are carried in body parts of content-type application/sdp with content-disposition of 'session'. If a body part has content-type application/sdp but has a disposition other than 'session' then it isn't an offer or answer according to 3261, and so 3264 doesn't apply.
>
> I think that getting explicit rejections, rather than having to try to 
> figure out where things go wrong, is good for progress :)
>

---

From: Emil Ivov <[email-masked]>
Date: Fri, 18 Oct 2013 17:11:18 -0500

I do think that a different MIME type makes more sense here for the reasons
Paul explained.

It might be worth adding that the same MIME type would be used when sending
candidate updates with Trickle ICE for SIP, which to me at least, makes a
lot of sense.

--sent from my mobile
On 18 Oct 2013 16:55, "Christer Holmberg" <[email-masked]>
wrote:

> It's not the way I think - I just wanted to explore how/if things would
> work IF we were thinking like that, and what the pros and cons would be :)
>
> We have to keep in mind that, no matter how we look at it, the
> Offers/Answers and POFs/PANs are tightly connected, meaning that they
> impact the same SDP state, can cause race conditions etc.
>
> Regards,
>
> Christer
>
>
>
>
>
> >>>> And a middlebox that sees something marked as "application/sdp" that
> conveys only a tiny fraction of the session will probably be just as
> catastrophic; I would imagine everything but the modified streams would be
> shut off. There's no way to win here.
> >>>
> application/sdp but has a disposition other than 'session' then it isn't an
> offer or answer according to 3261, and so 3264 doesn't apply.
> >
> > 3264 says that all m- line must be present in an Offer - even if they
> are not modified. So, what I meant was that in case all m- lines are NOT
> present (in the case of a POF), such Offer would be rejected - unless the
> middlebox understands the POF/PAN mechanism .
> >
> middleboxes that aren't primarily in the business of stifling progress will
> need to keep pace with protocol extensions as they get deployed.
> >>>

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Oct 2013 17:39:52 -0500

On 10/18/13 16:16, Christer Holmberg wrote:
> That's why Hadriel should write all our RFCs

You know, there was a point in time at which I would have suspected that 
would work. I would have believed that it would have produced specs that 
would, at the very least, play nicely with middleboxes. And vice-versa. 
Because if there's one person playing in this space who understands 
middleboxes, I would think Hadriel is that person.

But consider the INSIPID effort, which Hadriel did, in fact, author.

At the end of a year and a half of hashing out details, Hadriel 
explained (in a personal, not corporate capacity) that the resulting 
identifier is *unlikely* to make it through middleboxes. Keep in mind 
that the only reason for this work to have occurred is to create an 
identifier that makes it through middleboxes.

Um. What?

 From that, I think the lesson to take away is that middleboxes are 
going to do what middleboxes do, and that we are utter fools for trying 
to appease them. I think it also demonstrates that the Faustian deals we 
cut every time we concede defeat to middlebox behavior are even more ill 
conceived than we first imagined: at least Mephistopheles honored his 
end of the deal.

I think this also tells us that no one can act as an emissary for 
middleboxes, even someone as experienced as Hadriel. Claims about what 
middleboxes do, don't do, can do, or won't do should be viewed with 
extreme skepticism. Any such statements are so heavily caveated as to be 
devoid of meaning.

To be clear, this isn't intended as a smear against Hadriel. When he 
delivered the message that INSIPID was pretty well worthless, he did so 
exactly as a messenger and not as a perpetrator. The failure of 
middleboxes to use this mechanism we designed exclusively for them is 
not his fault. No, this is a criticism leveled at middlebox vendors in 
general. Even where the IETF makes concessions to middleboxes, the 
middleboxes don't play nicely with those concessions. Nothing could have 
been a more direct pander to middleboxes than INSIPID, and its failure 
at their hands is apparently complete and without mitigation.

The writing on the wall is clear. This kowtowing to unknowable and 
infinitely mutable middlebox requirements is both unproductive and 
harmful to innovation. It needs to stop. And it needs to stop now. It's 
done untold damage to SIP's ability to innovate. I have no interest in 
inviting the rampaging bull that gored SIP into WebRTC's home. I'm done 
entertaining arguments that we need to fetter innovation in order to 
accommodate implementations that have no interest in what the IETF has 
to say.

/a

P.S. Yes, I know your comment was meant to be tongue-in-cheek, but it 
threw into vivid relief the reality that the IETF's attempts to play 
nice with middleboxes have been utterly unrequited.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Oct 2013 19:18:11 -0400

Adam,

I'm pretty sure that Hadriel will speak up in a minute and say that the 
SBCs only do what they do because that is what administrators want them 
to do.

So on one hand it is the administrators that we should curse, not the 
vendors of middleboxes.

OTOH, ISTM that the administrators and middlebox vendors are 
codependent. Administrators do stuff because they can, even if it is a 
bad idea.

I guess ultimately it is a competition. Admins want to forbid anything 
they don't fully understand. But that prevents introduction of new stuff.

So ultimately I think we just have to define the new stuff, even if the 
middleboxes will often break it. And then let demand push the admins and 
middlebox vendors to allow it.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Oct 2013 19:24:04 -0400

On 10/18/13 6:11 PM, Emil Ivov wrote:
> I do think that a different MIME type makes more sense here for the
> reasons Paul explained.

In the sip world, we may *also* want a new content-disposition. Using 
'session' as the content-disposition with the new content type implies 
that the the body is just a different representation of an offer or 
answer. (We were once considering exactly that with SDPng.)

We *might* want to think of it that way, or not.

> It might be worth adding that the same MIME type would be used when
> sending candidate updates with Trickle ICE for SIP, which to me at
> least, makes a lot of sense.

I still wonder why trickle ICE needs a *different* mechanism for partial 
offers. Couldn't we just use this one?

	Thanks,
	Paul

> --sent from my mobile
>
> On 18 Oct 2013 16:55, "Christer Holmberg"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>      > I'm thinking that the POFs and PANs are something new, different
>     from offers and answers. They go on *between* offers and answers.
>      >
>     It's not the way I think - I just wanted to explore how/if things
>     would work IF we were thinking like that, and what the pros and cons
>     would be :)
>
>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>     they impact the same SDP state, can cause race conditions etc.
>
>     Regards,
>
>     Christer
>
>
>
>
>
>      >>>> And a middlebox that sees something marked as
>     "application/sdp" that conveys only a tiny fraction of the session
>     will probably be just as catastrophic; I would imagine everything
>     but the modified streams would be shut off. There's no way to win here.
>      >>>
>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>     that they are carried in body parts of content-type application/sdp
>     with content-disposition of 'session'. If a body part has
>     content-type application/sdp but has a disposition other than
>     'session' then it isn't an offer or answer according to 3261, and so
>     3264 doesn't apply.
>      >
>      > 3264 says that all m- line must be present in an Offer - even if
>     they are not modified. So, what I meant was that in case all m-
>     lines are NOT present (in the case of a POF), such Offer would be
>     rejected - unless the middlebox understands the POF/PAN mechanism .
>      >
>     [email-masked] <mailto:[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Fri, 18 Oct 2013 18:40:46 -0500

On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <[email-masked]> wrote:
> 'session' as the content-disposition with the new content type implies that
> the the body is just a different representation of an offer or answer. (We
> were once considering exactly that with SDPng.)
>

By "this one", do you mean POF/PAN or application/sdpfrag?

We don't need anything different than application/sdpfrag.

We can't use POF/PAN because we are not sending offers and answers. We
are just exchanging candidates in agent-to-agent messages. The use of
SDP is an unfortunate coincidence, not an indication of offers and
answers.

Emil

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Oct 2013 06:10:38 +0000

Hi Emil,

Similar to POF/PAN, the sending of candidates do affect the session SDP (bacause, as you said, they are sent within SDP).

So, while we would need to think about whether using POF/PAN would make sense or not, why do you think that we "can't" do it?

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov <[email-masked]> wrote:

Emil

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Oct 2013 06:20:56 +0000

Hi,

I think everyone agrees that in order to make POF/PAN work, certain intermediaries must support the mechanism. I didn't suggest that using app/sdp would make POF/PAN work with non-supporting intermediaries. I only said that it would be easier to identify such non-supporting intermediaries, as they would reject the POF.

But, if we don't even agree that non-supporting intermediaries would reject a POF, but rather think that media e.g. has been disabled, that advantage goes away.

Part of innovation is to discuss/explore different ideas - even the SBC-friendly ones :)

Regards,

Christer

Paul Kyzivat <[email-masked]> wrote:

Adam,

        Thanks,
        Paul

---

From: Emil Ivov <[email-masked]>
Date: Sat, 19 Oct 2013 07:19:15 -0500

Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg" <[email-masked]>
wrote:

> Hi Emil,
>
> Similar to POF/PAN, the sending of candidates do affect the session SDP
> (bacause, as you said, they are sent within SDP).
>

I don't think this is accurate. Use of SDP for additional candidates is
just a coincidence. It was readily available syntax for describing
candidates and it might be convenient in some implementations (although
this is probably of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer
and could have just as easily be based on JSON or XML or anything else.

Also, trickled candidates DO NOT update the session SDP the way a new m=
line does. There is only a loose relation between them and subsequent O/As.
The origin field does NOT need to be updated. New candidates in new O/As
may appear without having been trickled and trickled candidates can just
well be omitted in subsequent O/As. In other words, a trickled candidate
would only affect the state of the ICE agent in exactly the same way a peer
reflexive candidate would and it would be orthogonal to O/A, again, just as
peer reflexive candidates are.

> So, while we would need to think about whether using POF/PAN would make
> sense or not, why do you think that we "can't" do it?
>

OK, maybe "can't" is not entirely accurate here. I am sure that we *could*
make it would with O/A if we really put our backs into it. In a similar
way, I am sure we could also make it work by exchanging candidates in a
shared Dropbox folder. In either case, I don't see why we would want to
incur such a thing on our selves. I don't see any advantage to doing this.

On the downside, trickling candidates in Offer/Answer would imply the
following problems:

*  Very high glare probability.
* Unnecessarily complex implementation (really, this would be a nightmare
and I sincerely advise anyone supporting offer answer for trickle to first
try and implement it).
* Ambiguity between ICE restarts and trickle updates.

Also, given how we have already had this discussion and converged on use of
INFO, it is unclear to to me as to why we are revisiting this. I don't
think anyone has reported any problems on the alternative.

Cheers,
Emil

> that
> >> <[email-masked] <mailto:[email-masked]
> >>
> >>
> >> wrote:
> >>
> >>     Hi,
> >>
> >>      >> 3264 only talks about how to process offers and answers
> described
> >> in

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Oct 2013 15:43:55 +0000

Hi Emil,

Assume you have an m- line, for which you provide candidates using trickle ICE.

Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it will inherit the address properties and candidates of the BUNDLE group.

Are you saying that the previously provided trickle candidates are still comsidered valid, eventhough they are associated with different address properties etc?

Regards,

Christer

Hey Christer,

On 19 Oct 2013 08:10, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Emil,

I don't think this is accurate. Use of SDP for additional candidates is just a coincidence. It was readily available syntax for describing candidates and it might be convenient in some implementations (although this is probably of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer and could have just as easily be based on JSON or XML or anything else.

Also, trickled candidates DO NOT update the session SDP the way a new m= line does. There is only a loose relation between them and subsequent O/As. The origin field does NOT need to be updated. New candidates in new O/As may appear without having been trickled and trickled candidates can just well be omitted in subsequent O/As. In other words, a trickled candidate would only affect the state of the ICE agent in exactly the same way a peer reflexive candidate would and it would be orthogonal to O/A, again, just as peer reflexive candidates are.

OK, maybe "can't" is not entirely accurate here. I am sure that we *could* make it would with O/A if we really put our backs into it. In a similar way, I am sure we could also make it work by exchanging candidates in a shared Dropbox folder. In either case, I don't see why we would want to incur such a thing on our selves. I don't see any advantage to doing this.

On the downside, trickling candidates in Offer/Answer would imply the following problems:

*  Very high glare probability.
* Unnecessarily complex implementation (really, this would be a nightmare and I sincerely advise anyone supporting offer answer for trickle to first try and implement it).
* Ambiguity between ICE restarts and trickle updates.

Also, given how we have already had this discussion and converged on use of INFO, it is unclear to to me as to why we are revisiting this. I don't think anyone has reported any problems on the alternative.

Cheers,
Emil

Regards,

Christer

Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

Emil

>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>>
>> wrote:
>>
>>     Hi,
>>
>>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]<mailto:[email-masked]>                        PHONE: +33.1.77.62.43.30<tel:%2B33.1.77.62.43.30>
https://jitsi.org                       FAX:   +33.1.77.62.47.31<tel:%2B33.1.77.62.47.31>
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Emil Ivov <[email-masked]>
Date: Sat, 19 Oct 2013 10:56:16 -0500

The new SDP O/A you mention would cause an ICE restart and that's what will
define agent state. Not previously exchange trickled candidates.

I am not sure I understand the relation to your argument though (about
trickled candidates affecting session SDP) so I might be missing your point.

Emil

--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" <[email-masked]>
wrote:

>  OK, maybe "can't" is not entirely accurate here. I am sure that we
> *could* make it would with O/A if we really put our backs into it. In a
> similar way, I am sure we could also make it work by exchanging candidates
> in a shared Dropbox folder. In either case, I don't see why we would want
> to incur such a thing on our selves. I don't see any advantage to doing
> this.
>
>  * Unnecessarily complex implementation (really, this would be a
> nightmare and I sincerely advise anyone supporting offer answer for trickle
> to first try and implement it).
>  Also, given how we have already had this discussion and converged on use
> of INFO, it is unclear to to me as to why we are revisiting this. I don't

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Oct 2013 16:44:13 +0000

Hi,

I am trying to figure out how/if O/A and trickle ICE interact when it comes to providing candidates.

But, let's start with a more simple example:

-          I provide candidates A, B and C using O/A

-          Later, I provide candidates D and E using trickle ICE

-          Then, I send a new O/A, with candidates A, B and C

Now, are candidates D and E still valid, or did my new O/A disable them?

Regards,

Christer

Lähettäjä: Emil Ivov [mailto:[email-masked]]
Lähetetty: 19. lokakuuta 2013 18:56
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

The new SDP O/A you mention would cause an ICE restart and that's what will define agent state. Not previously exchange trickled candidates.

I am not sure I understand the relation to your argument though (about trickled candidates affecting session SDP) so I might be missing your point.

Emil

--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Emil,

Regards,

Christer

Hey Christer,

Cheers,
Emil

Regards,

Christer

Emil

---

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 19 Oct 2013 09:53:27 -0700

On Saturday, October 19, 2013, Christer Holmberg wrote:

>  Hi,****
>
> ** **
>
> I am trying to figure out how/if O/A and trickle ICE interact when it
> comes to providing candidates.****
>
> ** **
>
> But, let’s start with a more simple example:          ****
>
> ** **
>
> **-          **I provide candidates A, B and C using O/A****
>
> **-          **Later, I provide candidates D and E using trickle ICE****
>
> **-          **Then, I send a new O/A, with candidates A, B and C****
>
> ** **
>
> Shouldn't the new O/A have all the candidates from A through E listed ..
Just a guess

> Now, are candidates D and E still valid, or did my new O/A disable them?**
> **
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *Lähettäjä:* Emil Ivov [mailto:[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>]
> *Lähetetty:* 19. lokakuuta 2013 18:56
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* Paul Kyzivat; mmusic
> *Aihe:* Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value*
> ***
>
> ** **
>
> The new SDP O/A you mention would cause an ICE restart and that's what
> will define agent state. Not previously exchange trickled candidates. ****
>
> ****
> Emil****
> --sent from my mobile****
>
> wrote:****
> Hi Emil,****
> ** **
> Assume you have an m- line, for which you provide candidates using trickle ICE.****
>
> ** **
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it will inherit the address properties and candidates of the BUNDLE group.****
>
> ** **
>
> Are you saying that the previously provided trickle candidates are still comsidered valid, eventhough they are associated with different address properties etc?****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> Sent from my Sony Ericsson Xperia arc S****
>
> ** **
>
> Emil Ivov <[email-masked]> wrote:****
>
> ** **
>
>  Hey Christer,****
>
> wrote:****
> (bacause, as you said, they are sent within SDP).****
>
> ** **
>
> and could have just as easily be based on JSON or XML or anything else. **
> **
>
> peer reflexive candidates are.****
>
>  ****
>
> sense or not, why do you think that we "can't" do it?****
>
>  ** **
>
> OK, maybe "can't" is no
>

---

From: Emil Ivov <[email-masked]>
Date: Sat, 19 Oct 2013 11:54:34 -0500

If D and E are not provided and checked in the new O/A then they are no
longer valid. Think of them as peer reflexive.

--sent from my mobile
On 19 Oct 2013 18:44, "Christer Holmberg" <[email-masked]>
wrote:

> *Lähettäjä:* Emil Ivov [mailto:[email-masked]]
> following problems:****
> *  Very high glare probability.****
>
> try and implement it). ****
>
> * Ambiguity between ICE restarts and trickle updates.****
>
> Emil ****
> https://www.ietf.org/mailman/listinfo/mmusic****
>
>

---

From: Emil Ivov <[email-masked]>
Date: Sat, 19 Oct 2013 11:55:52 -0500

Yes it could. It will be up to the implementation. Not providing them is
definitely an option.

--sent from my mobile
On 19 Oct 2013 18:53, "Suhas Nandakumar" <[email-masked]> wrote:

>> Now, are candidates D and E still valid, or did my new O/A disable them?*
>> ***
>>
>> ** **
>>
>> Regards,****
>>
>> ** **
>>
>> Christer****
>>
>> ** **
>>
>> *Aihe:* Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
>> ****
>>
>> ** **
>>
>> and could have just as easily be based on JSON or XML or anything else. *
>> ***
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Oct 2013 16:59:04 +0000

Hi,
 
>Shouldn't the new O/A have all the candidates from A through E listed .. 

They may be listed.

But, Emil said: "New candidates in new O/As may appear without having been trickled and trickled candidates can just well be omitted in subsequent O/As."

So, my question is in the case they are omitted in subsequent O/As: are they removed, or does the subsequent O/A simply have no affect on the trickled candidates?

Regards,

Christer

The new SDP O/A you mention would cause an ICE restart and that's what will define agent state. Not previously exchange trickled candidates. 
I am not sure I understand the relation to your argument though (about trickled candidates affecting session SDP) so I might be missing your point.
Emil
--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" <[email-masked]> wrote:
Hi Emil,

 
 
Regards,
 
Christer

 
Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg" <[email-masked]> wrote:
Hi Emil,

 
 
OK, maybe "can't" is no

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Oct 2013 17:01:21 +0000

Hi,

> If D and E are not provided and checked in the new O/A then they are no longer valid. Think of them as peer reflexive.

In that case there could be a race condition, if trickled candidates are provided at the same time as an ongoing O/A.

Regards,

Christer

--sent from my mobile
On 19 Oct 2013 18:44, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Lähettäjä: Emil Ivov [mailto:[email-masked]<mailto:[email-masked]>]

Emil

--sent from my mobile

Hi Emil,

Regards,

Christer

Hey Christer,

Cheers,
Emil

Regards,

Christer

Emil

---

From: Emil Ivov <[email-masked]>
Date: Sat, 19 Oct 2013 12:49:01 -0500

Could you please be more specific? I am not sure I see it.

Emil

--sent from my mobile
On 19 Oct 2013 19:01, "Christer Holmberg" <[email-masked]>
wrote:

> longer valid. Think of them as peer reflexive.****
>
> In that case there could be a race condition, if trickled candidates are
> provided at the same time as an ongoing O/A.****
>
> Regards,****
>
> Christer****
>
> ** **
>
> ** **
>
> -          I provide candidates A, B and C using O/A****
>
> -          Later, I provide candidates D and E using trickle ICE****
>
> -          Then, I send a new O/A, with candidates A, B and C****
>
>  ****
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Oct 2013 21:27:41 +0000

Example:

1.       Alice sends an SDP Offer to Bob.

2.       Bob sends the SDP Answer to Alice, with candidates A, B and C.

3.       After that, Bob sends, using trickle ICE, candidates D and E to Alice.

If Alice receives the SDP Answer first, and then the trickle ICE request, she will assume that Bob first provided candidates A, B and C (in the SDP Answer), and then added D and E (in the trickle ICE request).

If Alice receives the trickle ICE request first, and then the SDP Answer, she will assume that Bob first provided candidates D and E (in the trickle ICE request), but then replaced them with candidates A, B and C (as the SDP Answer did not contain candidates D and E).

Regards,

Christer

Lähettäjä: Emil Ivov [mailto:[email-masked]]
Lähetetty: 19. lokakuuta 2013 20:49
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

Emil

--sent from my mobile
On 19 Oct 2013 19:01, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

--sent from my mobile

Regards,

Christer

Emil

--sent from my mobile

Hi Emil,

Regards,

Christer

Hey Christer,

Cheers,
Emil

Regards,

Christer

Emil

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 19 Oct 2013 22:55:05 -0400

On 10/19/13 11:56 AM, Emil Ivov wrote:
> will define agent state. Not previously exchange trickled candidates.

Are you saying that every O/A causes an ICE restart for every m-line 
that is using ICE? That would be very unfortunate.

	Thanks,
	Paul

> On 19 Oct 2013 17:43, "Christer Holmberg"
>     Emil Ivov <[email-masked]  <mailto:[email-masked]>> wrote:
>
>     Hey Christer,
>
>     On 19 Oct 2013 08:10, "Christer Holmberg"
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi Emil,
>
>         Similar to POF/PAN, the sending of candidates do affect the
>         session SDP (bacause, as you said, they are sent within SDP).
>
>
>     I don't think this is accurate. Use of SDP for additional candidates
>     is just a coincidence. It was readily available syntax for
>     describing candidates and it might be convenient in some
>     implementations (although this is probably of marginal value).
>
>     The point is that the syntax is not due to a relationship to
>     Offer/Answer and could have just as easily be based on JSON or XML
>     or anything else.
>
>     Also, trickled candidates DO NOT update the session SDP the way a
>     new m= line does. There is only a loose relation between them and
>     subsequent O/As. The origin field does NOT need to be updated. New
>     candidates in new O/As may appear without having been trickled and
>     trickled candidates can just well be omitted in subsequent O/As. In
>     other words, a trickled candidate would only affect the state of the
>     ICE agent in exactly the same way a peer reflexive candidate would
>     and it would be orthogonal to O/A, again, just as peer reflexive
>     candidates are.
>
>         So, while we would need to think about whether using POF/PAN
>         would make sense or not, why do you think that we "can't" do it?
>
>
>     *could* make it would with O/A if we really put our backs into it.
>     In a similar way, I am sure we could also make it work by exchanging
>     candidates in a shared Dropbox folder. In either case, I don't see
>     why we would want to incur such a thing on our selves. I don't see
>     any advantage to doing this.
>
>     nightmare and I sincerely advise anyone supporting offer answer for
>     trickle to first try and implement it).
>     Also, given how we have already had this discussion and converged on
>     use of INFO, it is unclear to to me as to why we are revisiting
>     this. I don't think anyone has reported any problems on the alternative.
>
>     Cheers,
>     Emil
>
>
>         Regards,
>
>         Christer
>
>         Emil Ivov <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>         On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>> wrote:
>          >> <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>          >>
>          >> wrote:
>          >>
>          >>     Hi,
>          >>
>          >>      > IIUC you are thinking of POFs and PANs as extended
>         forms of
>          >>     offers and answers.
>          >>
>          >>      >>>>> Content-Disposition does not apply to
>         intermediaries. So, a
>          >> proxy
>          >>      >>>> won't know to look at its contents and let the new
>         streams
>          >>     through.
>          >>     but the modified streams would be shut off. There's no
>         way to win
>          >> here.
>          >>      >>>
>          >>      >>> I think it would reject the Offer - at least that's
>         what it
>          >>     should do according to 3264.
>          >>      >>
>          >>      >> 3264 only talks about how to process offers and
>         answers described
>          >> in
>          >>      >> Maybe you are right. Then sip will go the way of
>         h323 while the
>          >>     world moves on to webrtc.
>          >>      >
>          >>      > I think that getting explicit rejections, rather than
>         having to
>          >>     try to
>          >>      > Anyway, it wasn't really a suggestion - I just wanted
>         to do some
>          >>      > brainstorming :)
>          >>      >
>          >>      > Regards,
>          >>      >
>          >>      > Christer
>          >>      >
>          >>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]>
>           PHONE: +33.1.77.62.43.30 <tel:%2B33.1.77.62.43.30>
>         <tel:%2B33.1.77.62.47.31>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 20 Oct 2013 13:11:34 +0200

Hey Christer,

Before Berlin we agreed (and it is my fault for not putting that in
text yet) that the answerer will wait for PRACK or an INFO request
with end-of-candidates, before trickling further candidates.

There is hence no way for the situation you describe to occur.

Emil

On Sat, Oct 19, 2013 at 11:27 PM, Christer Holmberg
<[email-masked]> wrote:
> If Alice receives the SDP Answer first, and then the trickle ICE request,
> she will assume that Bob first provided candidates A, B and C (in the SDP
> Answer), and then added D and E (in the trickle ICE request).
>
> If Alice receives the trickle ICE request first, and then the SDP Answer,
> she will assume that Bob first provided candidates D and E (in the trickle
> ICE request), but then replaced them with candidates A, B and C (as the SDP
> Answer did not contain candidates D and E).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> provided at the same time as an ongoing O/A.
>
> Regards,
>
> Christer
>
>
>
>
>
> --sent from my mobile
>
> But, let’s start with a more simple example:
>
>
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it
> will inherit the address properties and candidates of the BUNDLE group.
>
>
>
> Are you saying that the previously provided trickle candidates are still
> comsidered valid, eventhough they are associated with different address
> properties etc?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> I don't think this is accurate. Use of SDP for additional candidates is just
> a coincidence. It was readily available syntax for describing candidates and
> it might be convenient in some implementations (although this is probably of
> marginal value).
>
> The origin field does NOT need to be updated. New candidates in new O/As may
> appear without having been trickled and trickled candidates can just well be
> omitted in subsequent O/As. In other words, a trickled candidate would only
> affect the state of the ICE agent in exactly the same way a peer reflexive
> candidate would and it would be orthogonal to O/A, again, just as peer
> reflexive candidates are.
>
>
>
> make it would with O/A if we really put our backs into it. In a similar way,
> I am sure we could also make it work by exchanging candidates in a shared
> Dropbox folder. In either case, I don't see why we would want to incur such
> a thing on our selves. I don't see any advantage to doing this.
>
> INFO, it is unclear to to me as to why we are revisiting this. I don't think
> anyone has reported any problems on the alternative.
>
> Cheers,
> Emil
>
>
>
>
> Regards,
>
> Christer
>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 20 Oct 2013 13:24:26 +0200

Hey Paul,

On Sun, Oct 20, 2013 at 4:55 AM, Paul Kyzivat <[email-masked]> wrote:
> Are you saying that every O/A causes an ICE restart for every m-line that is
> using ICE? That would be very unfortunate.

No, of course not. An offer that contains the currently in-use
addresses (local and remote), contains no other candidates, and has
the same ice-pwd and ice-ufrag, will not cause an ICE restart: Section
9.1.2.2 in 5245.

Emil

>>     Then, you add the m- line to a BUNDLE group, using SDP O/A, which
>> means it will inherit the address properties and candidates of the BUNDLE
>> group.
>>
>>     Are you saying that the previously provided trickle candidates are
>> still comsidered valid, eventhough they are associated with different
>> address properties etc?
>>
>>     Regards,
>>
>>     Christer
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 20 Oct 2013 12:29:47 +0000

Hi Emil,

In general, my point is the following: if there are multiple mechanisms to add/remove (explicit or implicit) candidates, it needs to be clear how they interact, and whether there can be ambiguous situations etc (e.g. if it is unclear in which order candidates have been provided).

And, I assume we now have 3 different mechanisms to provide candidates: SDP O/A, SDP POF/PAN (I assume it will be allowed to provide candidates using POF/PAN, if e.g. a new m- line is added), and Trickle ICE.

But, if you claim there is no way such ambiguous situations can occur, fine :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Emil Ivov [mailto:[email-masked]] 
Lähetetty: 20. lokakuuta 2013 14:12
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

Hey Christer,

Before Berlin we agreed (and it is my fault for not putting that in text yet) that the answerer will wait for PRACK or an INFO request with end-of-candidates, before trickling further candidates.

Emil

On Sat, Oct 19, 2013 at 11:27 PM, Christer Holmberg <[email-masked]> wrote:
> If Alice receives the SDP Answer first, and then the trickle ICE 
> request, she will assume that Bob first provided candidates A, B and C 
> (in the SDP Answer), and then added D and E (in the trickle ICE request).
>
> If Alice receives the trickle ICE request first, and then the SDP 
> Answer, she will assume that Bob first provided candidates D and E (in 
> the trickle ICE request), but then replaced them with candidates A, B 
> and C (as the SDP Answer did not contain candidates D and E).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>> If D and E are not provided and checked in the new O/A then they are 
>> no longer valid. Think of them as peer reflexive.
>
> In that case there could be a race condition, if trickled candidates 
> are provided at the same time as an ongoing O/A.
>
> Regards,
>
> Christer
>
>
>
>
>
> --sent from my mobile
>
> comes to providing candidates.
>
>
>
> means it will inherit the address properties and candidates of the BUNDLE group.
>
>
>
> Similar to POF/PAN, the sending of candidates do affect the session 
> SDP (bacause, as you said, they are sent within SDP).
>
>
>
> is just a coincidence. It was readily available syntax for describing 
> candidates and it might be convenient in some implementations 
> (although this is probably of marginal value).
>
> Offer/Answer and could have just as easily be based on JSON or XML or anything else.
>
> Also, trickled candidates DO NOT update the session SDP the way a new 
> m= line does. There is only a loose relation between them and subsequent O/As.
> The origin field does NOT need to be updated. New candidates in new 
> O/As may appear without having been trickled and trickled candidates 
> can just well be omitted in subsequent O/As. In other words, a 
> trickled candidate would only affect the state of the ICE agent in 
> exactly the same way a peer reflexive candidate would and it would be 
> orthogonal to O/A, again, just as peer reflexive candidates are.
>
>
>
> So, while we would need to think about whether using POF/PAN would 
> make sense or not, why do you think that we "can't" do it?
>
>
>
> *could* make it would with O/A if we really put our backs into it. In 
> a similar way, I am sure we could also make it work by exchanging 
> candidates in a shared Dropbox folder. In either case, I don't see why 
> we would want to incur such a thing on our selves. I don't see any advantage to doing this.
>
> use of INFO, it is unclear to to me as to why we are revisiting this. 
> I don't think anyone has reported any problems on the alternative.
>
> Cheers,
> Emil
>
>
>
>
> Regards,
>
> Christer
>
>> 'session' as the content-disposition with the new content type 
>> implies that the the body is just a different representation of an 
>> offer or answer. (We were once considering exactly that with SDPng.)
>>
>> I still wonder why trickle ICE needs a *different* mechanism for 
>> partial offers. Couldn't we just use this one?
>
>>> <mailto:[email-masked]>>
>>>
>>> wrote:
>>>
>>>     Hi,
>>>
>>> described in

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Sun, 20 Oct 2013 14:37:04 +0000

My experience in SBC is different wherein SBC are only the boxes which are complaints to RFC (if required by the customer) and make sure that interop with non-compliant boxes/endpoints in the network.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Saturday, October 19, 2013 2:40 AM
To: Christer Holmberg; Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

/a

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 20 Oct 2013 22:37:11 +0530

Paul,

> Maybe you are right. Then sip will go the way of h323 while the world

It is amazing to hear from you that h323 way of media negotiation is better
than SIP now :-)

Let us assume content-disposition "partial-session" for partial offer/answer
exist. So, RFC 3264 does not applies for "partial-session". How the normal
interaction and race condition between "session" and "partial-session" will
be handled as both impact the same session in the media layer? Could you
please explain.

Thanks
Partha

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Saturday, October 19, 2013 2:24 AM
> To: Christer Holmberg
> Cc: [email-masked]
> middlebox that sees
> >> something marked as "application/sdp" that conveys only a tiny
> fraction of the session will probably be just as catastrophic; I would
> imagine everything but the

---

From: Adam Roach <[email-masked]>
Date: Sun, 20 Oct 2013 12:12:37 -0500

> be handled as both impact the same session in the media layer? Could you

This is covered in the current draft. After you read it, let me know if you had trouble finding the section dealing with this interaction. 

/a

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 20 Oct 2013 23:34:59 +0530

Adam,

I'm looking for the interaction between full offer and partial offer glare
situation. In the current draft, Sec 6.5.2 & Sec 6.6.2 deals with partial
offer/answer situation only.

Thanks
Partha

> From: Adam Roach [mailto:[email-masked]]
> Sent: Sunday, October 20, 2013 10:43 PM
> To: Parthasarathi R
> Cc: Paul Kyzivat; Christer Holmberg; [email-masked]
> This is covered in the current draft. After you read it, let me know if
> you had trouble finding the section dealing with this interaction.
> 
> /a=

---

From: Adam Roach <[email-masked]>
Date: Sun, 20 Oct 2013 13:27:43 -0500

> offer/answer situation only.
Perhaps adding examples was a mistake. The examples are supposed to help 
with comprehension, but they do not form a part of the specification.

Really, this situation is intended to be covered in section 5.6: a 
partial offer crossing the wire with a full offer is a full glare 
situation. Neither is put into effect, and whatever procedures the 
higher-level protocol says to do to resolve glare are undertaken [1].

If you think there's any specific ambiguity here, please point it out; 
in particular, talk about how two different implementors might read this 
and reasonably do two incompatible things.

/a

___
[1] For SIP, these procedures involve 491 responses and the timer 
described in RFC 3261 section 14.1, but we're not necessarily 
considering partial for SIP at the moment.

---

From: Adam Roach <[email-masked]>
Date: Sun, 20 Oct 2013 14:27:52 -0500

On 10/19/13 16:27, Christer Holmberg wrote:
>
> Example:
>
> 1.Alice sends an SDP Offer to Bob.
>
> 2.Bob sends the SDP Answer to Alice, with candidates A, B and C.
>
> 3.After that, Bob sends, using trickle ICE, candidates D and E to Alice.
>
> If Alice receives the trickle ICE request first, and then the SDP Answer
>

Don't do that then.

It's been pretty clear from the start that any session *modification* 
mechanism that does not also contain the full session state completely 
falls apart in the face of unordered delivery. This is a fundamental 
information problem, and you aren't going to write rules that somehow 
cause it not to be true.

We haven't yet tackled how to send trickle ICE in SIP, much less partial 
offers and partial answers. When we do, the only way it's going to have 
any chance of working at all is by requiring ordered delivery.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 20 Oct 2013 19:50:35 +0000

Hi,

> It's been pretty clear from the start that any session *modification* mechanism that does not also contain the full session state completely falls apart in the face of unordered delivery. This is a fundamental information problem, and you aren't going to write rules that somehow cause it not to be true.
>
> We haven't yet tackled how to send trickle ICE in SIP, much less partial offers and partial answers. When we do, the only way it's going to have any chance of working at all is by requiring ordered delivery.

I totally agree, and my opinion (which I tried to explain to Emil) is that it applies also to candidates. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 20 Oct 2013 16:06:07 -0400

> It is amazing to hear from you that h323 way of media negotiation is better

Even though you included a smiley, I think maybe you didn't understand 
how I meant that statement. I didn't intend to suggest that sip should 
adopt any new behavior from h323. I meant that then sip may become old 
and obsolete, the way h323 is. (Some think it already has. It certainly 
is working on it.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 20 Oct 2013 20:10:58 +0000

>> It is amazing to hear from you that h323 way of media negotiation is 
>> better than SIP now :-)
>
> Even though you included a smiley, I think maybe you didn't understand how I meant that statement. I didn't intend to suggest that sip should adopt any new behavior from h323.

Throughout the years I think we have tried (and are still trying) very hard to adopt H.245 features into SDP O/A...

Regards,

Christer

> Let us assume content-disposition "partial-session" for partial 
> offer/answer exist. So, RFC 3264 does not applies for 
> "partial-session". How the normal interaction and race condition 
> between "session" and "partial-session" will be handled as both impact 
> the same session in the media layer? Could you please explain.
>
> Thanks
> Partha
>
>
>
>>>> won't
>> fraction of the session will probably be just as catastrophic; I 
>> would imagine everything but the
>>> I think it would reject the Offer - at least that's what it should 
>>> do
>> according to 3264.
>>
>> SDP. It does not say how those are conveyed in sip. 3261 says that 
>> they are carried in body parts of content-type application/sdp with 
>> application/sdp but has a disposition other than 'session' then it 
>> isn't an offer or answer according to 3261, and so 3264 doesn't 
>> apply.
>>
>> progress will need to keep pace with protocol extensions as they get deployed.
>>>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 20 Oct 2013 22:18:54 +0200

Christer, "I tried to explain" to you that what you are saying has been
addressed and cannot happen. If you believe that there is a specific
situation that is still possible and is a problem, then please describe
that rather than continuing to suggest that things don't work without any
valid arguments whatsoever.

--sent from my mobile
On 20 Oct 2013 21:50, "Christer Holmberg" <[email-masked]>
wrote:

> request, she will assume that Bob first provided candidates A, B and C (in
> the SDP Answer), and then added D and E (in the trickle ICE request).
> >>
> information problem, and you aren't going to write rules that somehow cause
> it not to be true.
> >
> offers and partial answers. When we do, the only way it's going to have any
> chance of working at all is by requiring ordered delivery.
>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 20 Oct 2013 22:23:29 +0200

One more thought:

Please understand that trickle ICE is NOT a session modification. Please
try to isolate the SDP syntax that it uses from general O/A. It is not part
of it.

Think of it as JSON if that would make thinks easier.

Emil

--sent from my mobile
On 20 Oct 2013 22:18, "Emil Ivov" <[email-masked]> wrote:

>> Answer
>> > We haven't yet tackled how to send trickle ICE in SIP, much less
>> partial offers and partial answers. When we do, the only way it's going to
>> have any chance of working at all is by requiring ordered delivery.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 20 Oct 2013 20:38:10 +0000

Hi Emil,

No matter whether you consider the ICE state (including the candidates) part of the SDP session state or not, SDP session modification requests (read: SDP Offers and Answers) DO impact the ICE State, as Offers and Answers can be used to carry candidates.

Regards,

Christer

Lähettäjä: Emil Ivov [mailto:[email-masked]]
Lähetetty: 20. lokakuuta 2013 23:23
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; Adam Roach; mmusic
Aihe: Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

One more thought:

Please understand that trickle ICE is NOT a session modification. Please try to isolate the SDP syntax that it uses from general O/A. It is not part of it.

Emil

--sent from my mobile
On 20 Oct 2013 22:18, "Emil Ivov" <[email-masked]<mailto:[email-masked]>> wrote:

Christer, "I tried to explain" to you that what you are saying has been addressed and cannot happen. If you believe that there is a specific situation that is still possible and is a problem, then please describe that rather than continuing to suggest that things don't work without any valid arguments whatsoever.

--sent from my mobile
On 20 Oct 2013 21:50, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 20 Oct 2013 20:42:13 +0000

Hi Emil,

I am not suggesting that things don't work.

I am saying that we need to be very sure that there isn't a risk for ambiguous situations, where different endpoints may end up having different "understandings" of the ICE state.

Regards,

Christer

Lähettäjä: Emil Ivov [mailto:[email-masked]]
Lähetetty: 20. lokakuuta 2013 23:19
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic; Adam Roach
Aihe: Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

--sent from my mobile

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 20 Oct 2013 16:55:30 -0400

On 10/20/13 4:23 PM, Emil Ivov wrote:
> One more thought:
>
> Please understand that trickle ICE is NOT a session modification.

Isn't the session modified as a result of the trickle ICE? (E.g., end up 
using a different media address than it otherwise would have.)

And the use of trickle ICE can (I think) require that a subsequent offer 
be sent (or answered) differently than it would had trickle ice not been 
used.

And AFAIK everything that can be accomplished with trickle ICE could 
also be accomplished with Partial Offer/Answer. So the differences 
aren't functional ones. I presume that trickle ICE is expected to be 
faster, and/or easier to implement. (But easier to implement becomes 
moot if both need to be implemented.)

In my book those justify considering it a session modification.

	Thanks,
	Paul

> Please
> try to isolate the SDP syntax that it uses from general O/A. It is not
> part of it.
>
>     Christer, "I tried to explain" to you that what you are saying has
>     been addressed and cannot happen. If you believe that there is a
>     specific situation that is still possible and is a problem, then
>     please describe that rather than continuing to suggest that things
>     don't work without any valid arguments whatsoever.
>
>     --sent from my mobile
>
>     On 20 Oct 2013 21:50, "Christer Holmberg"
>          >> If Alice receives the SDP Answer first, and then the trickle
>         ICE request, she will assume that Bob first provided candidates
>         A, B and C (in the SDP Answer), and then added D and E (in the
>         trickle ICE request).
>          >>
>          > It's been pretty clear from the start that any session
>         *modification* mechanism that does not also contain the full
>         session state completely falls apart in the face of unordered
>         delivery. This is a fundamental information problem, and you
>         aren't going to write rules that somehow cause it not to be true.
>          >
>          > We haven't yet tackled how to send trickle ICE in SIP, much
>         less partial offers and partial answers. When we do, the only
>         way it's going to have any chance of working at all is by
>         requiring ordered delivery.
>
>         I totally agree, and my opinion (which I tried to explain to
>         Emil) is that it applies also to candidates.
>
>         Regards,
>
>         Christer
>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 20 Oct 2013 23:17:57 +0200

Yes, they do have an impact. They reset it. Please describe a scenario
where you think this is a problem.

--sent from my mobile
On 20 Oct 2013 22:38, "Christer Holmberg" <[email-masked]>
wrote:

>  Hi Emil,****
>
> ** **
>
> No matter whether you consider the ICE state (including the candidates)
> part of the SDP session state or not, SDP session modification requests
> (read: SDP Offers and Answers) DO impact the ICE State, as Offers and
> Answers can be used to carry candidates.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *Lähetetty:* 20. lokakuuta 2013 23:23
> *Kopio:* Paul Kyzivat; Adam Roach; mmusic
> *Aihe:* Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
> value****
>
> ** **
>
> One more thought:****
>
> of it.****
> Think of it as JSON if that would make thinks easier.****
>
> Emil****
>
> On 20 Oct 2013 22:18, "Emil Ivov" <[email-masked]> wrote:****
>
> valid arguments whatsoever.****
>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 21 Oct 2013 03:03:44 +0200

On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat <[email-masked]> wrote:
> And the use of trickle ICE can (I think) require that a subsequent offer be
> sent (or answered) differently than it would had trickle ice not been used.

The above statements are also true for vanilla ICE and peer reflexive
candidates, where ICE processing not reflected in SDP can already lead
to potential changes of addresses. If the change occurs, then an O/A
would follow. Currently Trickle ICE works along these exact same
lines.

> And AFAIK everything that can be accomplished with trickle ICE could also be
> accomplished with Partial Offer/Answer.

I already agreed that it is implementable ... the point is that it
would be *incredibly inconvenient*. I already gave a few reasons
earlier in this thread, let's try again:

* there would be an extremely high glare probability (which is
perfectly avoidable without O/A), * there would be a lot of added
complexity. Imagine POFs / PANs that send additional candidates *and*
change codecs and/or add/remove streams.
*  it would be very clumsy: after trickling candidates with a POF,
agents would block and wait for a PAN before they can do it again
* POF/PAN would be a dependency for trickle and there is no reason for it to be.
* In Berlin we agreed that we are adopting Unified for WebRTC cases.
There are Plan B and No Plan style implementations out there and my
understanding is that they have not been outlawed. Such
implementations would be unlikely to adopt POF/PAN. Yet, it would be
great if we made it possible for them to still use Trickle ICE.

The disadvantages aside:

Why would we want to do it this way?
What would we hope to gain?

> So the differences aren't functional
> ones.
> I presume that trickle ICE is expected to be faster, and/or easier to
> implement. (But easier to implement becomes moot if both need to be
> implemented.)

I can promise you that it doesn't. You don't have to take my word for
it. Just try and implement it.

> In my book those justify considering it a session modification.

Let's not take things out of context. Christer's point was that
because it is a session modification, it has to be done in
Offer/Answer.

This is wrong.

You can consider it a session modification if you like but it is not
the kind that requires Offer/Answer. Vanilla ICE proves this.

Emil

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Oct 2013 05:32:34 +0000

Hi Emil,

I am not saying that trickle ICE has to be done using O/A. In Berlin I agreed that e.g. INFO seems to be a feasible mechanism.

What I am saying is that O/A also impact the ICE state, including candidates that you have trickeled using a non-O/A mechanism.

And, similar to POF/PAN, also for trickle ICE we need to describe the usage with BUNDLE, e.g. whether a trickled candidate applies (I assume it does) to all m- lines within a BUNDLE group, etc.

Regards,

Christer

The disadvantages aside:

This is wrong.

Emil

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Oct 2013 09:53:22 -0400

Emil,

I'm open to your arguments that there is reason to have trickle ICE 
alongside O/A and POF/PAN.

But then we must recognize that these all have interactions with one 
another. Rather than just ignore them, or hand wave, ISTM that these 
need to be specified. It introduces complexity, and dealing with that is 
part of the job.

Vanilla ICE specifies the interactions between O/A and the discovery of 
candidates via ICE itself. But should it be updated to talk about all 
these other mechanisms as well? If not, where should those be 
documented? Should trickle ICE discuss interactions with POF/PAN, or 
should POF/PAN discuss interactions with trickle ICE, or both?

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 21 Oct 2013 23:43:11 +0530

Hi Adam,

The cross wire scenario of full offer and partial offer (POF) has to be considered as full glare and has to be handled by higher protocol. In terms of SIP(higher protocol), the full glare situation has to be handled in UPDATE/INFO as sec 4.2 recommends in POF&PAN draft. In case the content-disposition is "partial-session" [note 1] for POF, UPDATE glare handling will not kick start in SIP full offer side as per Sec 5.2 of RFC 3311 [note 2] and also, INFO has no glare handling in SIP. Could you please explain how the full offer and partial offer glare is handled for SIP. 

BTW, I would agree with you in case POA&PAN draft recommends for Re-INVITE for POF as 491 handling for RE-INVITE happens without depends upon offer.   

Thanks
Partha

Note 1: (Initial mail)
Let us assume content-disposition "partial-session" for partial offer/answer exist. So, RFC 3264 does not applies for "partial-session".

Note 2: 
If an UPDATE is received that contains an offer, and the UAS has
   generated an offer (in an UPDATE, PRACK or INVITE) to which it has
   not yet received an answer, the UAS MUST reject the UPDATE with a 491
   response.

> Sent: Sunday, October 20, 2013 11:58 PM
> To: Parthasarathi R
> Cc: 'Paul Kyzivat'; 'Christer Holmberg'; [email-masked]

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 21 Oct 2013 23:58:41 +0530

Paul,

Please read inline.

Thanks
Partha

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, October 21, 2013 1:36 AM
> To: Parthasarathi R
> Cc: 'Christer Holmberg'; [email-masked]
> better
> how I meant that statement. 
<Partha> You are right. I thought your statement that SIP will adopt H.323
media negotiation model while move to WebRTC. </Partha>

I didn't intend to suggest that sip should
> and obsolete, the way h323 is. (Some think it already has. It certainly
<Partha> I sense the same. while SIP was picking up, ISUP was transported in
SIP (SIP-I/T). Now, SIP is transported in WebSocket while WebSocket is
picking up. The history may repeat. </Partha>

> offer/answer
> they
> >> isn't
> progress

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Oct 2013 19:13:02 +0000

Hi,

Assuming we treat (as has been suggested by Emil) trickle candidates as server reflexive candidates, would SDP have any impact on those? We don't signal server relexive candidates in SDP, do we?

So, in that case, if I later send an updated Offer, which does NOT contain the trickle candidates, I guess the Offer should NOT disable the trickle candidates (unless in case of an ICE restart, that is)?

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Monday, 21 October 2013 4:53 PM
To: [email-masked]
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

Emil,

        Thanks,
        Paul