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

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>
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] On Behalf Of Emil Ivov
> > Sent: Monday, March 24, 2014 12:23 AM
> > To: Paul Kyzivat; 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
> > https://www.ietf.org/mailman/listinfo/mmusic
>