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

["Parthasarathi R" <[e-mail]>]

Hi Christer/Emil,

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

As both of you mentioned, there is a need to indicate Trickle ICE SDP
fragment information to O/A FSM. From the offer/answer perspective, "o" line
input or equivalent SDP parameter will be act as the event to O/A FSM
whether the given SDP Fragment has to be considered as a event for O/A FSM
or not. 

Please note that I'm not concerned about the syntax of "o" line but I'm
concerned about the methods used for exchange these SDP fragment. From the
current Trickle ICE proposal, INFO method with SDP fragment has to
considered as an event for O/A FSM input. This impacts the existing O/A
implementation based on SIP methods namely INVITE, RE-INVITE, UPDATE. Based
on the current discussion, I could not understand why Trickle ICE SDP
fragment *MUST* be sent using INFO (package) only and why *MUST NOT* using
UPDATE as Trickle ICE SDP fragment is method independent message body.

Thanks
Partha   

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Monday, March 31, 2014 3:31 AM
> To: Emil Ivov; Parthasarathi R
> Cc: 'mmusic'; 'Enrico Marocco (TiLab)'
> Subject: RE: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft
> 
> 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=