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

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

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:[e-mail]] 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:[e-mail]]
> >> *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"
> <[e-mail]
> >> <mailto:[e-mail]>> 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:[e-mail]
> >> <mailto:[e-mail]>] On Behalf Of Emil Ivov
> >>  > > Sent: Monday, March 24, 2014 12:23 AM
> >>  > > To: Paul Kyzivat; [e-mail] <mailto:[e-mail]>
> >>  > > 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
> >>  > > [e-mail] <mailto:[e-mail]>
> >>  > > https://www.ietf.org/mailman/listinfo/mmusic
> >>  >
> >>
> >
> 
> --
> https://jitsi.org
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic