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

"Parthasarathi R" <partha@parthasarathi.co.in> Wed, 26 March 2014 01:35 UTC

Return-Path: <partha@parthasarathi.co.in>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE81A0040 for <mmusic@ietfa.amsl.com>; Tue, 25 Mar 2014 18:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd96Mx26XD2k for <mmusic@ietfa.amsl.com>; Tue, 25 Mar 2014 18:35:43 -0700 (PDT)
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.14]) by ietfa.amsl.com (Postfix) with ESMTP id E24D31A0030 for <mmusic@ietf.org>; Tue, 25 Mar 2014 18:35:42 -0700 (PDT)
Received: from userPC (unknown [122.167.132.183]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id EFC6B1908611; Wed, 26 Mar 2014 01:35:36 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1395797740; bh=EEMgRq/9cl5SOYiTP9xPlSXJzqOzm22nJU3uJ/X9JqY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=W/AzhI3xgTMNB/wLWwT+X0+JlC/JSOqyQtnBX8FOSrkoEQLRHknrBXoNkPlj4EOcA 5Cg8+UJ7RKnCcADJXSGGTb2r/44rJy21ix6herm9Zn/a8fnQ8n0oyQmG0AtEoOFGZz gn/iz62MmjSRR0pIUO5zen0vLtii6G/u2UAWBEos=
From: Parthasarathi R <partha@parthasarathi.co.in>
To: 'Emil Ivov' <emcho@jitsi.org>, 'Paul Kyzivat' <pkyzivat@alum.mit.edu>, mmusic@ietf.org
References: <01e601cf423c$57255890$057009b0$@co.in> <00c901cf4687$0a48dbb0$1eda9310$@co.in> <CAPvvaaKW+vxhJFqUPRZ-YfPQ4dHOS-=YwZaW+=NS3DttaaXD=Q@mail.gmail.com> <532F216E.7090400@alum.mit.edu> <532F2D8C.2010104@jitsi.org>
In-Reply-To: <532F2D8C.2010104@jitsi.org>
Date: Wed, 26 Mar 2014 07:05:28 +0530
Message-ID: <01b701cf4893$afbf0e80$0f3d2b80$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac9GySWWywyls2hzQym+UDzw8mRFLQBycSDw
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020206.53322EEC.0023, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3dbVGBb6T-58QKpw0UQgbuqyZr0
Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 01:35:46 -0000

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