Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft

[Emil Ivov <[e-mail]>]

On 30.03.14, 11:38, Christer Holmberg wrote:
> Hi,
>
> I have tried to understand the whole issue discussed here, with little success :)
>
> So, rather than trying to come up with a solution, I think we first need to agree on some basic assumptions.
>
> If we claim that Trickle ICE has no impact on the SDP O/A state, then:
>
> 1) There should be no need to figure out whether an INFO is sent before an UPDATE; and

That's not exactly true because, like ICE, trickle ICE does depend on 
O/A in order to operate. In other words: if you change your location and 
do a new Offer/Answer, you don't expect vanilla ICE to magically 
continue, blissfully ignorant of that fact. It needs to restart and so 
does Trickle ICE.

> 2) There should be no need to include the o= line, or any other information that binds the INFO to a specific SDP O/A state.

The main reason you need that is so that you can drop stray INFOs that 
have been delayed and have arrived when the ICE processing context they 
were related to is no longer valid (i.e. after an ICE restart).

But I agree that an o= line is not the most convenient way to handle 
this and using ice-ufrag and ice-pwd would be better.

> Instead, Trickle ICE is only a mechanism to transport candidate information from one endpoint to another.

Agreed.

> Endpoints may of course add those candidates to subsequent Offer/Answers.

This should be clarified. I think it's not necessary. Basically an O/A 
can have the following two possible relations to trickle ICE:

1. ICE restart: (ice-ufrag and ice-pwd have changed). This basically 
means that your addressing situation has most likely changed and you 
need to start everything from scratch. So you do.

2. Non-ICE session modification: you are currently doing ICE and while 
you are at it, you change some aspect of your session that has 
no-relation to addressing. For example, you add formats, change the 
direction of a stream, or something like that. In this case trickle ICE 
continues with no modification.

Case 1 obviously doesn't need any of the trickle candidates but they can 
be included if the agent is comfortable reusing them. This is compatible 
with 5245 which says something like this:

    If ICE is restarting [...] the set of candidates MAY include some,
    none, or all of the previous candidates for that stream and MAY
    include a totally new set of candidates

Case 2 is less obvious to me. Requiring agents to include all currently 
known addresses sounds a bit risky to me because it's easy to get into 
situations where an agent receives a set of candidates that does not 
match its current view of the session:

Case 2.1: New candidates appear
Case 2.2: Some candidates are not there.

Case 2.1 is easy to handle: the new candidates are handled as if they 
were trickled.

Case 2.2 is kind of a headache. 5245 says that it MUST NOT happen but I 
don't think this can be guaranteed because various race conditions may 
cause trickled candidates to arrive before the O/A and make an agent 
believe that some of them are lacking.

I think the easiest way to handle this would be to say that, when using 
Trickle ICE, candidates and addressinf information from offers that DO 
NOT restart ICE MUST be ignored.

Thoughts?

Emil

--
https://jitsi.org


>
>
> Regards,
>
> Christer
>
>
>
> ________________________________________
> From: Emil Ivov [[e-mail]]
> Sent: Thursday, 27 March 2014 1:07 AM
> To: Parthasarathi R
> Cc: 'mmusic'; Christer Holmberg; 'Enrico Marocco (TiLab)'
> Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft
>
> On 26.03.14, 19:44, Parthasarathi R wrote:
>>   > > This race condition is very much possible during
>>   > > early
>>   > > dialog scenarios with UPDATE.
>>   > >
>>   > > Could you please explain how SIP trickle ICE using INFO works for
>>   > >
>>   > > 1) UPDATE from remote before Trickle ICE is completed
>>
>> This is analogous to an UPDATE that is received before regular 5245 ICE
>> processing has completed.
>>
>> <Partha> No, in case UDPATE before the offer is completed, 491 response
>> will send out whereas it will not happen in case of INFO </Partha>
>
> I think you might be confusing "before ICE processing has completed" and
> "before O/A has completed"
>
> An UPDATE that is received while "vanilla ICE processing is in progress"
> would have exactly the same effect as an UPDATE received while "trickle
> ICE processing is in progress". If O/A has completed then the UPDATE
> will NOT cause a 491 in either case.
>
>>   > >     a) INVITE from local
>>   > >     b) 183 session progress from remote
>>   > >     c) PRACK from local
>>   > >     d) INFO from local (relay candidates)
>>   > >     e) UPDATE from remote
>>   > >
>>   > > Here, the remote has to consider whether INFO belongs to UPDATE or
>>   > > INVITE as
>>   > > it is possible for INFO to reach before 200 OK for UPDATE as well in
>>   > > the
>>   > > same sequence.
>>
>> And CSeq headers wouldn't help here because ....?
>>
>>   > > Also, RFC 2976
>>
>> which FWIW is obsoleted by RFC6086
>>
>> <Partha> Thanks..I still majorly interwork with RFC 2976 implementation
>> :-( but please note that RFC 6086 does not change much in these SIP
>> dialog or session aspects. The exact snippet of RFC 6086 is as follows:
>>
>> “Note that the INFO method is not used to update characteristics of a
>>      SIP dialog or session, but to allow the applications that use the SIP
>>      session to exchange information (which might update the state of
>>      those applications).”
>
> Trickle ICE does not update the characteristics of a SIP dialog and I
> don't believe it violates the above in any way.
>
>>   > > " - The extensions that use the INFO message MUST NOT rely on the
>>   > >      INFO message to do anything that effects the SIP call state or the
>>   > >      state of related sessions."
>>
>> And I don't believe that it does.
>>
>> <Partha> No, it is not possible to implement this draft without impact
>> offer/answer state machine </Partha>
>
> Please provide an example where you think it actually breaks something.
> (It might be worth waiting until we submit the new version, which should
> probably clarify a few things).
>
>>   > > 2) Trickle ICE INFO with serial forking
>>
>> INFO requests are sent within a dialog. They will go through the prong
>> associated with that dialog and would not be forked.
>>
>> <Partha> IOW, Trickle ICE INFO will be buffered till 18x response is
>> received. So, INFO has no much advantage compare to UPDATE except for
>> the non-reliable response scenario.
>
> No advantage? INFOs can be send in both directions and arrive completely
> asynchronously without ever causing glare or without having to worry
> whose turn it is to send an offer or an answer because you need to
> piggyback candidates on top of it.
>
> We've been through this exact same argument several times already, you
> haven't pointed out any flaws with this logic so I can't see a reason
> why you keep coming back to it.
>
> You claim you are worried about needing to modify the offer/answer state
> machine in your implementation, but that is a very strange argument
> since that implementation would be much more heavily impacted if you
> were to try and trickle with offers and answers.
>
> I think the source of the confusion might be the fact that the draft is
> currently in a relatively poor state, which is my fault, and I am
> hopeful that you may find many of your answers in the next version.
>
> Emil