[MMUSIC] Connection and connectivity preconditions

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 04 April 2005 08:31 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05478 for <mmusic-web-archive@ietf.org>; Mon, 4 Apr 2005 04:31:57 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIN7w-0000XX-67 for mmusic-web-archive@ietf.org; Mon, 04 Apr 2005 04:40:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIMwg-0001q6-V5; Mon, 04 Apr 2005 04:28:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIMwf-0001px-8G for mmusic@megatron.ietf.org; Mon, 04 Apr 2005 04:28:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05284 for <mmusic@ietf.org>; Mon, 4 Apr 2005 04:28:27 -0400 (EDT)
Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIN4Y-0000QX-3i for mmusic@ietf.org; Mon, 04 Apr 2005 04:36:39 -0400
Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j348NilL023245; Mon, 4 Apr 2005 10:27:24 +0200 (MEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 10:27:18 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 10:27:18 +0200
Received: from [131.160.37.196] (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AEBA218A90; Mon, 4 Apr 2005 11:27:17 +0300 (EEST)
Message-ID: <4250FA65.8080709@ericsson.com>
Date: Mon, 04 Apr 2005 11:27:17 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>, fandreas@cisco.com, Dave Oran <oran@cisco.com>, dwing@cisco.com
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2005 08:27:18.0247 (UTC) FILETIME=[1D292770:01C538F0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] Connection and connectivity preconditions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit

Folks,

in the last IETF we discussed how to proceed with the following both drafts:

draft-andreasen-mmusic-connectivityprecondition-02.txt
draft-ietf-mmusic-connection-precon-01.txt

The former defines connectivity (e.g., RTP No-Op or ICE-based) 
preconditions and the latter defines connection-oriented (e.g., TCP or 
SCTP-based) preconditions.

The question is what to do to handle scenarios using connection-oriented 
protocols. The choices are:

1) Merge both documents so that only one precondition type is defined 
which, for connection-oriented protocols, is met when the connection 
establishment procedure finishes (e.g., a successful TCP 3-way handshake).

2) Leave the second draft as it is and define in the first draft further 
conditions that should be met for connection-oriented protocols. For 
example, the connection establishment procedure needs to be successfull 
*and* you have to run some type of connectivity check on top of it to 
ensure that you are talking to the correct remote endpoint.


In principle, Flemming and I thought that option 1) was the way to go, 
but in the meeting some folks talked about option 2).

Given that, at present, nobody is implementing something like option 2) 
(if somebody is doing it please speak up), my proposal would be to go 
for option 1).

Comments?

Thanks,

Gonzalo

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic