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

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 1 Apr 2014 21:35:33 +0530

As Paul indicated, "o" line input acts as event for O/A FSM in the remote
side to decide whether the given SDP fragment has to be accepted or not.
Please note that the similar logic is used in case SIP session timer SDP
wherein "o" line will not be incremented from the previous to indicate that
there is no change in SDP.

The first "ice-ufrag" & "ice-pwd" in SDP shall be used to differentiate but
O/A FSM impact is unavoidable. Also, Please note that the multiple
"ice-ufrag" & "ice-pwd" is possible in the given SDP because of multiple "m"
lines (with different ports).

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Emil Ivov
> Sent: Thursday, March 27, 2014 4:17 AM
> To: Paul Kyzivat
> Cc: 'mmusic'
> Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft
> 
> 
> 
> On 26.03.14, 20:06, Paul Kyzivat wrote:
> > I think it makes sense to include the o= line. It will still require
> > some text to fully explain what it means and how to use it.
> 
> After reading your mail I am not so sure any more.
> 
> > Note that the values of o= are also independent in the two
> directions,
> > so (like CSeq) can't be used directly to correlate messages in
> opposite
> > directions.
> >
> > However the O/A process does correlate pairs of o=, one from each
> side.
> >
> > What we end up with is:
> >
> > - a session has a series of O/A exchanges. Each O and A contains an
> >    SDP. And each SDP has has an o= line.
> > - From that you can identify a series of SDP pairs. Viewed from one
> >    side each pair has one local and one remote SDP.
> > - the version numbers in the o= lines of the local SDPs form a
> >    non-decreasing sequence. The same is true for the remote SDPs.
> >    (But two in a sequence may have the *same* version.)
> >
> > What we are talking about is for the trickle ICE SDP fragments to
> > contain the o= line from the SDP most recently sent in an offer or
> > answer by the sender of the fragment.
> >
> > If you receive a trickle ICE fragment, then you should compare the o=
> > line to that of the most recent SDP received in an offer or answer.
> If
> > those match, and you have no unanswered offer outstanding, then all
> is ok.
> >
> > If they differ and you have no unanswered offer outstanding, then
> > something is wrong. (I haven't thought through all the possibilities
> here.)
> >
> > If they differ and you have an unanswered outstanding offer, then it
> may
> > be that an answer is enroute and this trickle was intended to follow
> it.
> >
> > Note that if you have an unanswered offer outstanding, it is possible
> > that the answer will be identical to the prior offer, and that the
> > trickle fragment was sent after the answer. I *think* this doesn't
> > matter - treating it as if it was sent first will yield the same
> result.
> 
> This is really great insight! Thanks Paul!
> 
> It does make me wonder however if o= is the best way to handle things
> here though. For example, it hadn't occurred to me that an O/A can
> increment the o=values without having an impact on ICE processing. This
> would happen if ice-ufrag and ice-pwd remain the same.
> 
> So all this makes me think that ufrag and pwd may still be the easiest
> and most straightforward way of matching INFOs to a specific ICE
> context.
> 
> Thoughts?
> Emil
> 
> >
> >      Thanks,
> >      Paul
> >
> > On 3/26/14 1:49 PM, Parthasarathi R wrote:
> >> Hi Emil,
> >>
> >> Could you please clarify your intention of sending Origin "o" line
> or
> >> ICE-ufrag & ICE-pwd in this INFO & UPDATE scenario.
> >>
> >> I have mentioned  "o" line by which it will be trivial for everybody
> to
> >> understand that offer/answer state machine is impacted by these
> INFO.
> >>
> >> Thanks
> >>
> >> Partha
> >>
> >> *From:*Emil Ivov [mailto:[email-masked]]
> >> *Sent:* Wednesday, March 26, 2014 11:23 AM
> >> *To:* Parthasarathi R
> >> *Cc:* Paul Kyzivat; mmusic
> >> *Subject:* RE: [MMUSIC] Comment on SIP Trickle ICE based on INFO
> draft
> >>
> >>
> >> On 26 Mar 2014 2:35 AM, "Parthasarathi R"
> <[email-masked]
> >> <mailto:[email-masked]>> wrote:
> >>  >
> >>  > Hi Emil,
> >>  >
> >>  > <snip> > OK, I see. Then the easiest way to tackle this would be
> to
> >> mandate
> >>  > that
> >>  > > all INFOs contain the ICE ufrag and pwd of the offer/answer
> they are
> >>  > > pertaining to.
> >>  > >
> >>  > > Does anyone see a problem with that?
> >>  > </snip>
> >>  >
> >>  > I guess that your intention is to pass the corresponding Origin
> ("o")
> >> line
> >>  > in each INFO message by which INFO will be identified for the
> >> corresponding
> >>  > SDP by which the ICE candidates are passed.
> >>
> >> No, that wasn't my intention but sending the origin line would also
> work
> >> indeed. Thanks for pointing it out!
> >>
> >> We could actually make that a requirement of the sdpfrag format.
> >>
> >> --sent from my mobile
> >>
> >>  > I'm saying so as there is no
> >>  > purpose of passing ICE ufrag & pwd in each INFO message
> >>  >
> >>  > Thanks
> >>  > Partha
> >>  >
> >>  >
> >>  > > -----Original Message-----
> >>  > > From: mmusic [mailto:[email-masked]
> >> <mailto:[email-masked]>] On Behalf Of Emil Ivov
> >>  > > Sent: Monday, March 24, 2014 12:23 AM
> >>  > > To: Paul Kyzivat; [email-masked] <mailto:[email-masked]>
> >>  > > Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO
> draft
> >>  > >
> >>  > >
> >>  > >
> >>  > > On 23.03.14, 19:01, Paul Kyzivat wrote:
> >>  > > > One comment
> >>  > > >
> >>  > > > On 3/23/14 7:54 AM, Emil Ivov wrote:
> >>  > > >
> >>  > > >> This is analogous to an UPDATE that is received before
> regular
> >> 5245
> >>  > > ICE
> >>  > > >> processing has completed.
> >>  > > >>
> >>  > > >>  > >     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 ....?
> >>  > > >
> >>  > > > IIUC, the question is whether the remote can tell whether the
> INFO
> >>  > > was
> >>  > > > sent before or after receiving the UPDATE.
> >>  > > >
> >>  > > > CSeq values are independent in each direction. So they are
> >> useless to
> >>  > > > answer this question. Something else will be needed.
> >>  > >
> >>  > > OK, I see. Then the easiest way to tackle this would be to
> >> mandate that
> >>  > > all INFOs contain the ICE ufrag and pwd of the offer/answer
> they are
> >>  > > pertaining to.
> >>  > >
> >>  > > Does anyone see a problem with that?
> >>  > >
> >>  > > Emil
> >>  > >
> >>  > > --
> >>  > > https://jitsi.org
> >>  > >
> >>  > > _______________________________________________
> >>  > > mmusic mailing list
> >>  > > [email-masked] <mailto:[email-masked]>
> >>  > > https://www.ietf.org/mailman/listinfo/mmusic
> >>  >
> >>
> >
> 
> --
> https://jitsi.org
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 1 Apr 2014 23:11:57 +0530

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   

> From: Christer Holmberg [mailto:[email-masked]]
> 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 [[email-masked]]
> > Sent: Thursday, 27 March 2014 1:07 AM
> > To: Parthasarathi R
> > Cc: 'mmusic'; Christer Holmberg; 'Enrico Marocco (TiLab)'
> > 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
> >> <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
> >>   > > 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.
> >>
> >>   > > 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=