IETF Logo Mail Archive

Re: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination)

Simon Perreault <sperreault@jive.com> Mon, 04 August 2014 13:08 UTC

Return-Path: <sperreault@jive.com>
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 E75A61B2ADB for <mmusic@ietfa.amsl.com>; Mon, 4 Aug 2014 06:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NcekEv0Bh71d for <mmusic@ietfa.amsl.com>; Mon, 4 Aug 2014 06:08:14 -0700 (PDT)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5CE1B2AE6 for <mmusic@ietf.org>; Mon, 4 Aug 2014 06:08:10 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id nu7so4484698obb.28 for <mmusic@ietf.org>; Mon, 04 Aug 2014 06:08:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=77vBUnBT/hLjoHqLQ1JzTmu6OsBlYPV5b5nTmxdc8P0=; b=gtGzURqxgAqwFoReSRuzAJh7+/WRcO6nI7IOkSugKBPRLSguxTxgbTURx1HS7RAG17 mAVhCPQFa1FCjiiLmx4/51WpY5cysZmrnQAV2mTkKWFW7wbA13zFZQ5X+YAJxpDOgk6F ve6f63Fpj1YEeEG/zxswOOve5t5oQhC6nn3blczrgutM7TujNXhi6Cmy7U5dB7StJ7Zx SZfh4BFUaoFsI3Czfl7Z5fI+P6AWGOLAP93HXIF8VC2+l+uZTDTvH0/X69W4YV4elAyg GpCD3bFXj+ogAJXAnDEhdOq/n37wtz/Mx8eK0XFpTwg0X1CZbnygA9VHriVOPRTwN1LI rHpA==
X-Gm-Message-State: ALoCoQkAvx4ej+yQlBWKaJvJnMpvrpzBNtvmZxbRW/A9ot6o0CV/VkBB2liQ8AZ7IGk+ZJFI8kWp
X-Received: by 10.60.58.36 with SMTP id n4mr11323478oeq.73.1407157688063; Mon, 04 Aug 2014 06:08:08 -0700 (PDT)
Received: from [192.168.1.96] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id zd1sm38999710obb.1.2014.08.04.06.08.05 for <mmusic@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 06:08:06 -0700 (PDT)
Message-ID: <53DF85B4.6060600@jive.com>
Date: Mon, 04 Aug 2014 09:08:04 -0400
From: Simon Perreault <sperreault@jive.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <CAOJ7v-03iSNNNVMV=1vM1nUuwgCsk6JkyxPcrDEpk7MTr1LmBQ@mail.gmail.com>
In-Reply-To: <CAOJ7v-03iSNNNVMV=1vM1nUuwgCsk6JkyxPcrDEpk7MTr1LmBQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/micKNMy1X-bzytmEY4C3z7bjePI
Subject: Re: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination)
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: Mon, 04 Aug 2014 13:08:17 -0000

Le 2014-08-03 14:06, Justin Uberti a écrit :
> I agree it would be better to have the DTLS packet inside of STUN,
> rather than the converse. I would also suggest that we make this
> agnostic of the encapsulated protocol, e.g. allow for something like
> TURN's DATA attribute to carry generic data in a binding request.

Another idea: put the DTLS and STUN next to each other. Since the STUN 
header contains the STUN message length, you can put data after it in 
the same UDP packet.

Not saying it's a better idea, just something we could consider doing.

Simon

v2.23.0 | Report a Bug | By Email