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

[Christer Holmberg <[e-mail]>]

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.

Ok, I hear what you are syaing. You need a way to indicate whether the trickled candidates are pre-restart or not.

>> 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.

Or, some part of the o= line.

Keep in mind that you don't need to put everything in the INFO message body. You can also define parameters associated with the info package.

>>> 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.

Well, you can't ignore the "ice completed" Offer, can you?

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