IETF Logo Mail Archive

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

Emil Ivov <emcho@jitsi.org> Wed, 26 March 2014 05:52 UTC

Return-Path: <emcho@sip-communicator.org>
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 6406B1A021B for <mmusic@ietfa.amsl.com>; Tue, 25 Mar 2014 22:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Oq6paqiY05Mk for <mmusic@ietfa.amsl.com>; Tue, 25 Mar 2014 22:52:51 -0700 (PDT)
Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 281B91A00F1 for <mmusic@ietf.org>; Tue, 25 Mar 2014 22:52:50 -0700 (PDT)
Received: by mail-ve0-f177.google.com with SMTP id sa20so1743713veb.8 for <mmusic@ietf.org>; Tue, 25 Mar 2014 22:52:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h/5kbtN02I8UW8q2ND6P8E8RPaLxlyuV2fiO+4WjWkA=; b=mxUSII2bDoIOFHFPgyGytmcGr0NWVbzngNLJssfo9pm/GyQ8oeR26lMUu944cyzPob 8BBcX/K29TQkmj5QXjwFKKPwm38IMKV/KGZ6OK18BpHKy3KvkZZ2UlCoPggmpOg4JWJq S2EOIh05tnC6wBtOvUB7hgBG/ecNsnoN37G3/W2gHvoq4BG+JKo1GupHIkgJcwifXoc6 w1gP+Lg90Sa118naT3BN6f11KrKRC2DhSmg3+99Lhbu+/IEdXTedlGjmAYgWInrXn/FH LoI1yFDKcd45HoVx3B5VI0kSutEhmcOEpu+VRugOuNKiJ28kF+v+hsDwYgfQmbXemrL5 hrzQ==
X-Gm-Message-State: ALoCoQlEi0vE1pR3tYJ+ZmDs3zKYQ1pIMBpk39tXw/EpwjFu0b3dpRvnjG5k0spgFkzM8Rx648gt
X-Received: by 10.59.7.102 with SMTP id db6mr3772297ved.17.1395813169480; Tue, 25 Mar 2014 22:52:49 -0700 (PDT)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx.google.com with ESMTPSA id bh12sm2437871vdd.16.2014.03.25.22.52.48 for <mmusic@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 22:52:48 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id ij19so1809449vcb.24 for <mmusic@ietf.org>; Tue, 25 Mar 2014 22:52:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.220.104.210 with SMTP id q18mr49849268vco.9.1395813168484; Tue, 25 Mar 2014 22:52:48 -0700 (PDT)
Received: by 10.220.191.130 with HTTP; Tue, 25 Mar 2014 22:52:48 -0700 (PDT)
Received: by 10.220.191.130 with HTTP; Tue, 25 Mar 2014 22:52:48 -0700 (PDT)
In-Reply-To: <01b701cf4893$afbf0e80$0f3d2b80$@co.in>
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> <01b701cf4893$afbf0e80$0f3d2b80$@co.in>
Date: Wed, 26 Mar 2014 06:52:48 +0100
Message-ID: <CAPvvaaKCxnU=-SAefSDOkwms=Y=g9VoBpq57UPCqvGvYxV1VNw@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
To: Parthasarathi R <partha@parthasarathi.co.in>
Content-Type: multipart/alternative; boundary="047d7b3436bc14ad8304f57c14eb"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nzC8U6KtuC73nU_3KzvSYyVKY7M
Cc: mmusic <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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 05:52:53 -0000

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
>

v2.23.0 | Report a Bug | By Email