IETF Logo Mail Archive

Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis

Iñaki Baz Castillo <ibc@aliax.net> Thu, 24 July 2014 08:23 UTC

Return-Path: <ibc@aliax.net>
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 0043A1A00D8 for <mmusic@ietfa.amsl.com>; Thu, 24 Jul 2014 01:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 myja9a-L40HS for <mmusic@ietfa.amsl.com>; Thu, 24 Jul 2014 01:23:00 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E861A00CA for <mmusic@ietf.org>; Thu, 24 Jul 2014 01:22:59 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id a108so2792014qge.2 for <mmusic@ietf.org>; Thu, 24 Jul 2014 01:22:59 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=sw3aZrsvUkBBJ4ObVhnUNKpVWj5bItdL4NnHJntkRRM=; b=XItJwPIU3GfyA03NtYuZMRGIswN9XNEv4FcRHFlFC7gBGrA8CVa+imwF/MIoHZtRpA fJ9f9MUroADpz6imqFNnMqyubbE/lyHRSsHoGEH/ZLShUsVEvtZ+BsfaIrIkX1EYFuOV Z09mBlyi7p2Tn2O6KlPfjBggP/nsDSfnsiSz2564DA9xEhU+ff76JyeUKICQqQr2G0q/ KpfLIQ8fXlPNQrCcE/QeRYmuw7junZ9j55cteJO4Q84SBEaZ6f5xZTn9Y55WYcs26vjT 07P06I+Y1oy7nsf3I+EOraNJBvna8zPfERhONo/sw8mfh7ioI3LerixuR1U01vCFSnoZ DpSg==
X-Gm-Message-State: ALoCoQke325Ujl25QMbhl6r9hk0FKsZCSQqZrx9ZKtTPl0nAHLF08qq1pLRviT+Wp76bntHy4iSv
X-Received: by 10.140.30.73 with SMTP id c67mr11926972qgc.16.1406190179043; Thu, 24 Jul 2014 01:22:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 24 Jul 2014 01:22:38 -0700 (PDT)
In-Reply-To: <011401cfa6d8$378084f0$a6818ed0$@co.in>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com> <CAPvvaaKohXq8cZjUaQR6VvhHZ+Lkzzk2sQUn+iwSp_H1W6qaSA@mail.gmail.com> <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <011401cfa6d8$378084f0$a6818ed0$@co.in>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Thu, 24 Jul 2014 10:22:38 +0200
Message-ID: <CALiegfkMAEEMoDBH6UbuT2ptwurqPYk7AafxpMHu=B_ww2EXzg@mail.gmail.com>
To: Parthasarathi R <partha@parthasarathi.co.in>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nmwWMOsFASWBRuDEZ5vEhwEpStE
Cc: Ari Keränen <ari.keranen@ericsson.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
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: Thu, 24 Jul 2014 08:23:01 -0000

2014-07-24 2:42 GMT+02:00 Parthasarathi R <partha@parthasarathi.co.in>:
> It is better to handle through signaling as it provides to flexibility in the application (like forking usecase).

No, it is not. So 5245bis si supposed to split ICE network protocol
and SDP, and you propose that a new feature must depend, again, on the
signaling protocol? No way.

And the forking usecase (so you mean the "SIP forking usecase") is
perfectly achiveable via a new STUN attribute (by sending a request
containing it to the specific "SIP forked dialog").


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email