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

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.

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.

	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:emcho@jitsi.org]
> *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" <partha@parthasarathi.co.in
> <mailto:partha@parthasarathi.co.in>> 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:mmusic-bounces@ietf.org
> <mailto:mmusic-bounces@ietf.org>] On Behalf Of Emil Ivov
>  > > Sent: Monday, March 24, 2014 12:23 AM
>  > > To: Paul Kyzivat; mmusic@ietf.org <mailto:mmusic@ietf.org>
>  > > 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
>  > > mmusic@ietf.org <mailto:mmusic@ietf.org>
>  > > https://www.ietf.org/mailman/listinfo/mmusic
>  >
>