Subject: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01

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

Hi all,

I have mailed earlier why SIP INFO is not the right choice for Trickle ICE
in
http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html. The main
reason is the glare handling. I have added the callflow in Sec 6.4 of
draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will look for
Trickle ICE handling in SIP w.r.t JSEP mapping. Could you please explain how
glare with Trickle ICE Info package will be handled.

Thanks
Partha

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Oct 2013 03:08:58 +0200

On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
<[email-masked]> wrote:
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.

I remember. Have you noticed my answer?

http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html

> The main
> Trickle ICE handling in SIP w.r.t JSEP mapping.

I am confused. You say that your main issue is glare handling and yet
your draft proposes a solution that *introduces* glare (through
crossing UPDATEs) and then doesn't say anything about handling it. Is
this intentional? Am I missing something?

> Could you please explain how

That's simple. Glare does NOT occur when trickling through INFO.

Emil

--
https://jitsi.org

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 22 Oct 2013 22:31:51 +0530

Emil,

In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
unavoidable as per RFC 3264 offer/answer mechanism. The glare handling has
to be done by SIP provided mechanism like 491 handling in UPDATE/RE-INVITE.
draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE compliant
SIP UA and no need of extra extension.

INFO based mechanism fails to identify the actual glare situation in
offer/answer.

Of course,  it is possible to reduce the trickle ICE glare handling with
special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE in case
both endpoints supports the mechanism. 

Please read inline for more comments.

Thanks
Partha

> -----Original Message-----
> From: Emil Ivov [mailto:[email-masked]]
> Sent: Tuesday, October 22, 2013 6:39 AM
> To: Parthasarathi R
> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-
> mmusic-trickle-ice-sip-01
> 

<Partha> Please note that my question is after your answer (msg11964 >
msg11932). </Partha>

> this intentional? Am I missing something?

<Partha> 491 is the only known glare handling. We shall work and further
enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situation.
I wish to confirm that INFO mechanism does not work for this situation
before deep diving. </Partha>

> That's simple. Glare does NOT occur when trickling through INFO.

<Partha> The actual glare situation will be missed in INFO </Partha>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Oct 2013 19:52:06 +0200

On 22.10.13, 19:01, Parthasarathi R wrote:
> unavoidable

I don't think this is true.

> as per RFC 3264 offer/answer mechanism. The glare handling has

Yes, there is a well defined mechanism for handling glare with 3264. 
With that I agree. (Adoption and implementation levels are a different 
story but let's not worry about that right now.)

The thing is that this mechanism would be hugely inefficient for 
trickle. The likelihood of glare occurring even more than once there is 
extremely high when using UPDATEs.

You are actually quite likely to make the whole process even longer than 
Vanilla ICE so unless your purpose is to make Trickle pointless, I don't 
think this is a good idea.

> INFO based mechanism fails to identify the actual glare situation in

I think you might have misunderstood the way trickle ICE works with INFO.

Once the initial offer/answer is complete (and those rely on the regular 
glare handling, independently of trickle or ICE) there are no additional 
offers and answers.

INFO requests transport asynchronous signalling between ICE agents (NOT 
offers and answers) and it is perfectly fine for either party to be 
sending them at any point in time. There's no possibility of glare here.

Does this help clarify things?

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Oct 2013 18:04:37 +0000

Hi,

IF we consider trickle candidates as being identical to server reflexive candidates, I am not sure whether there is a risk of an O/A glare. Because, we don't signal server reflexive candidates in O/A either, do we?

If so, then I assume that Offers and Answers would have no impact on trickle candidates (unless, of course, there is an ICE restart). Or?

Regards,

Christer

________________________________
From: Emil Ivov [[email-masked]]
Sent: Tuesday, 22 October 2013 8:52 PM
To: Parthasarathi R
Cc: Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01

Emil

>> https://jitsi.org<https://jitsi.org/>
>
>

--
https://jitsi.org<https://jitsi.org/>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Oct 2013 20:15:03 +0200

On 22.10.13, 20:04, Christer Holmberg wrote:
> Hi,
>
> IF we consider trickle candidates as being identical to server reflexive

You mean peer reflexive, right?

> candidates, I am not sure whether there is a risk of an O/A glare.

I don't think so either.

> Because, we don't signal server reflexive candidates in O/A either, do we?
>
> If so, then I assume that Offers and Answers would have no impact on
> trickle candidates (unless, of course, there is an ICE restart). Or?

Yes, I believe that's the way to go. We might need to state this 
explicitly in 5245 in order to avoid confusion.

Emil

>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> *From:* Emil Ivov [[email-masked]]
> *Sent:* Tuesday, 22 October 2013 8:52 PM
> *To:* Parthasarathi R
> *Cc:* Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
> *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on
> draft-ivov-mmusic-trickle-ice-sip-01
>
>>>https://jitsi.org <https://jitsi.org/>
>>
>>
>
> --
> https://jitsi.org <https://jitsi.org/>

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Oct 2013 18:31:35 +0000

Hi,

> You mean peer reflexive, right?

Yes.

But, that actually makes me wonder. Because, I DO believe that peer reflexive candidates actually ARE sent in SDP Offers/Answers (server reflexive candidates obviously aren't). At least I couldn't any text in 5245 indicating otherwise.

So, that would mean that if an Offer is received without the peer refexive candidates, the answerer would remove them.

The issue that can occur is if you:

- first send an Answer (to an Offer), without candidate X;

- then you send a trickle request with candidate X;

- the trickle request reaches the remote endpoint BEFORE the Answer. The trickle request will add the candidate, but then the Answer will remove it (as it does not contain candidate X).

Do you understand what I mean? :)

Regards,

Christer

Emil

>>>https://jitsi.org<https://jitsi.org/> <https://jitsi.org/>
>>
>>
>
> --
> https://jitsi.org<https://jitsi.org/> <https://jitsi.org/>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Oct 2013 22:06:08 +0200

On 22.10.13, 20:31, Christer Holmberg wrote:
> But, that actually makes me wonder. Because, I DO believe that peer
> reflexive candidates actually ARE sent in SDP Offers/Answers (server
> reflexive candidates obviously aren't). At least I couldn't any text in
> 5245 indicating otherwise.

Mmmmm .... I am not sure I am following. Server reflexive candidates ARE 
signalled in offer/answer with vanilla ICE. That's how agents learn 
about them.

Peer reflexive candidates MAY be signalled with an updated offer. There 
is no requirement to do this, it can't be relied upon and the benefit is 
limited, if any. The implementations that I am aware of don't do it and 
I believe that, especially with trickle, we can easily update 5245bis 
not to include this.

> So, that would mean that if an Offer is received without the peer
> refexive candidates, the answerer would remove them.

You lost me. How would an answerer remove candidates from an offer if 
they weren't there in the first place? Did you mean to say something else?

> - the trickle request reaches the remote endpoint BEFORE the Answer.

We agreed that the answerer would either wait for a PRACK or an INFO 
with end-of-candidates before starting trickling, so I don't think this 
can happen.

> The
> trickle request will add the candidate, but then the Answer will remove
> it (as it does not contain candidate X).
>

I think I do but I am not sure. Why would you consider lack of a 
candidate as an indication that a candidate needs to be removed if 
including that candidate was a MAY in the first place?

I think that in 5245bis we could easily limit offer/answer updates to 
only impact ICE in two ways (which I believe is how current 
implementations work anyway):

1. None: ICE ufrag and pwd are the same and the offer only includes the 
candidates currently in use. (i.e. the O/A was performed for some other 
session modification)
2. ICE Restart: ICE ufrag and pwd are different and this is a complete 
reinitialization of ICE processing.

How does that sound?

Emil

>  >>>https://jitsi.org <https://jitsi.org/> <https://jitsi.org/>
>  >>
>  >>
>  >
>  > --
>  > https://jitsi.org <https://jitsi.org/> <https://jitsi.org/>
>
> --

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Oct 2013 10:25:37 +0000

Hi Emil,

First, I completely messed up with the candidate types. Sorry for the confusion :)

Anyway, it doesn't really matter what type of candidates are trickled - it's about whether trickled candidates can be affected by Offers/Answers.

> You lost me. How would an answerer remove candidates from an offer if they weren't there in the first place? Did you mean to say something else?

I referred to the example below, where an Offer does not contain a candidate that was previously trickled, and whether the answerer will then assume that the candidate is no longer valid.

> We agreed that the answerer would either wait for a PRACK or an INFO with end-of-candidates before starting trickling, so I don't think this can happen.

But, in the example above the Offer, and the Answer, may not contain any new candidates, the Answer simply contains a list of previously negotiated candidates. I don't think there will be an INFO with end-of-candidates in that case, or a PRACK (in case the Offer was received in an UPDATE, or in a POF).

Anyway, once some rules regarding WHEN candidates can be trickled, it may be easier to point on concrete issues (if any).

It would also be easier to explain the issues with a whiteboard :)

> I think I do but I am not sure. Why would you consider lack of a candidate as an indication that a candidate needs to be removed if including that candidate was a MAY in the first place?

Again, IF we say that trickled candidates MAY be present in Offers/Answers, and will not be removed in case they are not present, then there should be no issue.

Regards,

Christer

>  >> If so, then I assume that Offers and Answers would have no impact 
> on  >> trickle candidates (unless, of course, there is an ICE restart). Or?
>  >
>  > Yes, I believe that's the way to go. We might need to state this  > 
> ----------------------------------------------------------------------
> --  > *From:* Emil Ivov [[email-masked]]  > *Sent:* Tuesday, 22 
> October 2013 8:52 PM  > *To:* Parthasarathi R  > *Cc:* Christer 
> Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
>  > *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on  > 
>  >> In case of ICE Trickle handling in SIP (based on RFC 3261), glare 
> is  >> unavoidable  >  > I don't think this is true.
>  >
>  >> as per RFC 3264 offer/answer mechanism. The glare handling has  >> 
>  >> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE 
> compliant  >> SIP UA and no need of extra extension.
>  >
>  > With that I agree. (Adoption and implementation levels are a 
> different  > story but let's not worry about that right now.)  >  > 
> The thing is that this mechanism would be hugely inefficient for  > 
> trickle. The likelihood of glare occurring even more than once there 
> is  > extremely high when using UPDATEs.
>  >
>  > You are actually quite likely to make the whole process even longer 
> than  > Vanilla ICE so unless your purpose is to make Trickle 
> pointless, I don't  > think this is a good idea.
>  >
>  >> INFO based mechanism fails to identify the actual glare situation 
> in  >> offer/answer.
>  >
>  > Once the initial offer/answer is complete (and those rely on the 
> regular  > glare handling, independently of trickle or ICE) there are 
> no additional  > offers and answers.
>  >
>  > INFO requests transport asynchronous signalling between ICE agents 
> (NOT  > offers and answers) and it is perfectly fine for either party 
> to be  > sending them at any point in time. There's no possibility of glare here.
>  >
>  >> Of course,  it is possible to reduce the trickle ICE glare 
> handling with  >> special SDP handling (enhanced offer/answer) within 
> RE-INVITE/UPDATE in case  >> both endpoints supports the mechanism.
>  >>
>  >>> From: Emil Ivov [mailto:[email-masked]]  >>> Sent: Tuesday, 
> October 22, 2013 6:39 AM  >>> To: Parthasarathi R  >>> Cc: Christer 
> Holmberg; Enrico Marocco (TiLab); mmusic  >>> Subject: Re: UPDATE 
> mechanism for Trickle ICE - Comment on draft-ivov-  >>> 
> mmusic-trickle-ice-sip-01  >>>  >>> On Mon, Oct 21, 2013 at 8:29 PM, 
> Parthasarathi R  >>> <[email-masked]> wrote:
>  >>>> Hi all,
>  >>>>
>  >>>> I have mailed earlier why SIP INFO is not the right choice for  
> >>> Trickle ICE  >>>> in  
>  >> <Partha> Please note that my question is after your answer 
> (msg11964 >  >> msg11932). </Partha>  >>  >>>> The main  >>>> reason 
> is the glare handling. I have added the callflow in Sec 6.4 of  >>>> 
> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will  
> >>> look for  >>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>  >>>
>  >>> I am confused. You say that your main issue is glare handling and 
> yet  >>> your draft proposes a solution that *introduces* glare 
> (through  >>> crossing UPDATEs) and then doesn't say anything about 
> handling it. Is  >>> this intentional? Am I missing something?
>  >>>
>  >>
>  >> <Partha> 491 is the only known glare handling. We shall work and 
> further  >> enhance glare handling in UPDATE/RE-INVITE as it is 
> obvious glare situation.
>  >> I wish to confirm that INFO mechanism does not work for this 
> situation  >> before deep diving. </Partha>  >>  >>>> Could you please 
> explain how  >>>> glare with Trickle ICE Info package will be handled.
>  >>>
>  >> <Partha> The actual glare situation will be missed in INFO 
> </Partha>  >>  >>>  >>> Emil  >>>  >>> --  >>>https://jitsi.org 
> <https://jitsi.org/> <https://jitsi.org/>  >>  >>  >  > --  > 

--
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Oct 2013 15:08:19 +0200

Hey Christer,

On 23.10.13, 12:25, Christer Holmberg wrote:
> Anyway, it doesn't really matter what type of candidates are trickled
> - it's about whether trickled candidates can be affected by
> Offers/Answers.

And by affected you really mean invalidated. OK, I think I understand now.

I don't think there's anything in 5245 that defines semantics which 
would invalidate existing candidates.

I do agree that we could further clarify this in 5245bis and/or Trickle 
for SIP.

>>> So, that would mean that if an Offer is received without the
>>> peer refexive candidates, the answerer would remove them.
>>
>> You lost me. How would an answerer remove candidates from an offer
>> if they weren't there in the first place? Did you mean to say
>> something else?
>
> I referred to the example below, where an Offer does not contain a
> candidate that was previously trickled, and whether the answerer will
> then assume that the candidate is no longer valid.

Right. I don't think there's such a risk. 5245 explicitly forbids update 
Offers and Answers to remove candidates that have been announced 
previously and it allows (as in MAY, not SHOULD) that new candidates be 
added.

The former should address your concern and I believe we could simply 
remove the latter as it is of little use, if any.

>> We agreed that the answerer would either wait for a PRACK or an
>> INFO with end-of-candidates before starting trickling, so I don't
>> think this can happen.
>
> But, in the example above the Offer, and the Answer, may not contain
> any new candidates, the Answer simply contains a list of previously
> negotiated candidates. I don't think there will be an INFO with
> end-of-candidates in that case, or a PRACK (in case the Offer was
> received in an UPDATE, or in a POF).

Yes, maybe not. This would be a non-restarting update Offer and we could 
specify that such offers (and their answers) don't get to change ICE. 
Only ICE restarts do.

> Anyway, once some rules regarding WHEN candidates can be trickled, it
> may be easier to point on concrete issues (if any).

OK.

> Again, IF we say that trickled candidates MAY be present in
> Offers/Answers, and will not be removed in case they are not present,
> then there should be no issue.

OK, agreed.

Emil

>>> Yes, there is a well defined mechanism for handling glare with
>>> 3264. With that I agree. (Adoption and implementation levels are
>>> a
>> different  > story but let's not worry about that right now.)  >
>> > trickle. The likelihood of glare occurring even more than once
>> there is  > extremely high when using UPDATEs.
>>>
>> regular  > glare handling, independently of trickle or ICE) there
>> are no additional  > offers and answers.
>>>
>> (NOT  > offers and answers) and it is perfectly fine for either
>> party to be  > sending them at any point in time. There's no
>> possibility of glare here.
>>>
>> handling with  >> special SDP handling (enhanced offer/answer)
>> within RE-INVITE/UPDATE in case  >> both endpoints supports the
>> mechanism.
>>>>
>>>> Thanks Partha
>>>>> -----Original Message----- From: Emil Ivov
>>>>> [mailto:[email-masked]]  >>> Sent: Tuesday,
>> October 22, 2013 6:39 AM  >>> To: Parthasarathi R  >>> Cc:
>> Christer Holmberg; Enrico Marocco (TiLab); mmusic  >>> Subject: Re:
>> UPDATE mechanism for Trickle ICE - Comment on draft-ivov-  >>>
>> mmusic-trickle-ice-sip-01  >>>  >>> On Mon, Oct 21, 2013 at 8:29
>> PM, Parthasarathi R  >>> <[email-masked]> wrote:
>>>>>> Hi all,
>>>>>>
>> (msg11964 >  >> msg11932). </Partha>  >>  >>>> The main  >>>>
>> reason is the glare handling. I have added the callflow in Sec 6.4
>> of  >>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE
>> handling will
>> (through  >>> crossing UPDATEs) and then doesn't say anything
>> about handling it. Is  >>> this intentional? Am I missing
>> something?
>>>>>
>>>>
>> situation  >> before deep diving. </Partha>  >>  >>>> Could you
>> please explain how  >>>> glare with Trickle ICE Info package will
>> be handled.
>>>>>
>> -- https://jitsi.org <https://jitsi.org/>
>>
>
> -- https://jitsi.org
>

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Oct 2013 14:06:06 +0000

Hi,

> I don't think there's anything in 5245 that defines semantics which would invalidate existing candidates.

Generally, in SDP Offer/Answer, when an SDP attribute is not present, it means that it's invalidated, or the default value (if such has been specified) is assumed.

You could of course argue that, if a candidate has never been carried in an SDP Offer/Answer to begin with, SDP Offer/Answers should have no impact on it.

But, that really depends on whether the candidates are considered part of the SDP state or not. IF so, trickled candidates would update that state, in the same way SDP Offers/Answers do.

My point is that these things need to be clearly clarified.

> Right. I don't think there's such a risk. 5245 explicitly forbids update Offers and Answers to remove candidates that have been announced previously and it allows (as in MAY, not SHOULD) that new candidates be added.
>
> The former should address your concern and I believe we could simply remove the latter as it is of little use, if any.

Well, then there is of course a risk that the receiver of the Answer will trigger an error, as the trickled candidate is not included in the Answer (as the Answer was sent before the candidate was trickled :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Oct 2013 16:42:26 +0200

> Generally, in SDP Offer/Answer, when an SDP attribute is not present, it means that it's invalidated, or the default value (if such has been specified) is assumed.

What I meant was that 5245 explicitly states that all previously 
signalled candidates MUST be signalled in updated Offers, so candidate 
removal in the middle of ICE processing is not something that is defined 
for ICE.

Also, non-signalled candidates, like peer reflexive, are not required to 
be signalled in update Offers, so their absence in an offer cannot in 
any way be construed as a request for their removal.

> You could of course argue that, if a candidate has never been carried in an SDP Offer/Answer to begin with, SDP Offer/Answers should have no impact on it.

Yes, that's exactly what I'd argue since this is pretty much what 5245 
says (I say "pretty much" because it doesn't explicitly state it for 
trickle, but the general case matches).

> But, that really depends on whether the candidates are considered
> part of the SDP state or not. IF so, trickled candidates would update
> that state, in the same way SDP Offers/Answers do.

Right, and I've already mentioned that I don't see any reason to 
consider them as part of the SDP state, just as you wouldn't consider 
peer-reflexive candidates to be part of it.

> My point is that these things need to be clearly clarified.

I also agree that a clarification would be helpful (especially a clear 
one ;) ). It's easy to get lost in all this.

> Well, then there is of course a risk that the receiver of the Answer
> will trigger an error, as the trickled candidate is not included in
> the Answer (as the Answer was sent before the candidate was trickled
> :)

Lost me again. I think some ascii art or a web sequence diag [0] would 
be very helpful here. Want to give it a try?

Or we could continue this discussion once we have the specific cases in 
the new version of the draft. Hopefully it would be easier that way.

Emil

[0] WebSequenceDiagrams: https://www.websequencediagrams.com/

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 Oct 2013 13:01:32 +0000

Hi,

> What I meant was that 5245 explicitly states that all previously signalled candidates MUST be signalled in updated Offers, so candidate removal in the middle of ICE processing is not something that is defined for ICE.
>
> Also, non-signalled candidates, like peer reflexive, are not required to be signalled in update Offers, so their absence in an offer cannot in any way be construed as a request for their removal.

So, IF we can define the same for trickled candidates, then there might not be an issue.

We have to remember, though, that a trickled candidate is not a new candidate "type". The candidate types you trickle are the same types you send in Offer/Answer - tickle is simply an alternative candidate transport mechanism.

>> But, that really depends on whether the candidates are considered part 
>> of the SDP state or not. IF so, trickled candidates would update that 
>> state, in the same way SDP Offers/Answers do.
>
> Right, and I've already mentioned that I don't see any reason to consider them as part of the SDP state, just as you wouldn't consider peer-reflexive candidates to be part of it.

If a trickled candidate is eventually selected, doesn't a "clean up" SDP Offer have to be sent (as for any other non-default candidate), where the c- line is aligned with the candidate? In that case the candidate becomes part of the SDP state :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 24 Oct 2013 16:27:53 +0200

Hey Christer,

On 24.10.13, 15:01, Christer Holmberg wrote:
>>>>> Anyway, it doesn't really matter what type of candidates are
>>>>> trickled - it's about whether trickled candidates can be
>>>>> affected by Offers/Answers.
>>>>
>>>> I don't think there's anything in 5245 that defines semantics
>>>> which would invalidate existing candidates.
>>>
>>> Generally, in SDP Offer/Answer, when an SDP attribute is not
>>> present, it means that it's invalidated, or the default value (if
>>> such has been specified) is assumed.
>>
>> signalled candidates MUST be signalled in updated Offers, so
>> candidate removal in the middle of ICE processing is not something
>> that is defined for ICE.
>>
>> Also, non-signalled candidates, like peer reflexive, are not
>> required to be signalled in update Offers, so their absence in an
>> offer cannot in any way be construed as a request for their
>> removal.
>

That's also my thinking (without the IF ;) ).

> We have to remember, though, that a trickled candidate is not a new
> candidate "type". The candidate types you trickle are the same types
> you send in Offer/Answer - tickle is simply an alternative candidate
> transport mechanism.

Yes, that's right. I am not sure why you are saying it though.

>>> part of the SDP state or not. IF so, trickled candidates would
>>> update that state, in the same way SDP Offers/Answers do.
>>
>> consider them as part of the SDP state, just as you wouldn't
>> consider peer-reflexive candidates to be part of it.
>
> If a trickled candidate is eventually selected, doesn't a "clean up"
> SDP Offer have to be sent (as for any other non-default candidate),
> where the c- line is aligned with the candidate? In that case the
> candidate becomes part of the SDP state :)

As a result of the update offer, not as a direct result of trickle (just 
as with peer-reflexive candidates, which I seem to like repeating :) )

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 Oct 2013 14:34:17 +0000

Hi,

> Yes, that's right. I am not sure why you are saying it though.

Because when you say:

	"we treat trickle candidates in the same way as peer-reflexive candidates" 

...it sounds like a trickle candidate is a new type of candidate (similar to peer-reflexive candidate), which is not true.

You should say:

	"We treat candidates that were provided using the trickle ICE mechanism in the same way as peer-reflexive candidates"

:)

Regards,

Christer

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 24 Oct 2013 15:36:53 +0000

> 	"We treat candidates that were provided using the trickle ICE mechanism in the same way as peer-reflexive candidates"

There's a problem with this.

RFC 5245 says:

   However, the peer reflexive candidate is not paired with other remote
   candidates.  This is not necessary; a valid pair will be generated
   from it momentarily based on the procedures in Section 7.1.3.2.2.  If
   an agent wishes to pair the peer reflexive candidate with other
   remote candidates besides the one in the valid pair that will be
   generated, the agent MAY generate an updated offer which includes the
   peer reflexive candidate.

In other words, peer-reflexive candidates aren't automatically paired with all remote candidates; they're only paired with the remote candidate you were checking when you discovered them, unless you send them in an updated offer.

Candidates provided over Trickle don't have a remote candidate to be automatically paired with, so "treating them like peer-reflexive candidates" doesn't make much sense.

-- 
Jonathan Lennox
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Oct 2013 12:08:19 -0400

I'm far from an expert on ICE, so maybe this is covered and I just don't 
know it...

ISTM there is a need for some real clarity about the relationship 
between ICE state and SDP O/A state, and if/when pieces of state move or 
are synchronized between them. This isn't clear even for SDP O/A on its 
own, but with ICE, and now with trickle ICE, and with Partial O/A it is 
becoming even more of a problem.

RFC 6337 started to clarify SDP O/A itself, but it didn't deal with the 
sorts of issues that are coming up in this discussion.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Thu, 24 Oct 2013 18:31:21 +0200

> Candidates provided over Trickle don't have a remote candidate to be automatically paired with, so "treating them like peer-reflexive candidates" doesn't make much sense.

No it doesn't. The idea is that "trickled candidates" being exchanged,
checked and selected entirely outside the context of Offer/Answer is
not a problem because we already have this with "peer-reflexive
candidates".

Trickled candidates obviously do need specific handling within the
*ice agents*, which is one of the reasons for the existence of the
trickle ICE drafts.

Cheers,
Emil

--
https://jitsi.org