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

-- 
https://jitsi.org