Re: [MMUSIC] Single SCTP usage per SDP session?

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 25 November 2014 18:54 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 6407B1A877A for <mmusic@ietfa.amsl.com>; Tue, 25 Nov 2014 10:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] 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 FmTUsAvKPkAC for <mmusic@ietfa.amsl.com>; Tue, 25 Nov 2014 10:54:16 -0800 (PST)
Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087601A1A67 for <mmusic@ietf.org>; Tue, 25 Nov 2014 10:54:15 -0800 (PST)
Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with comcast id Kuta1p00452QWKC01uuFiq; Tue, 25 Nov 2014 18:54:15 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id KuuE1p00g3Ge9ey01uuFcQ; Tue, 25 Nov 2014 18:54:15 +0000
Message-ID: <5474D056.3090408@alum.mit.edu>
Date: Tue, 25 Nov 2014 13:54:14 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63BC0F@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63BE81@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63BF30@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> <5474A07C.5030701@nostrum.com>
In-Reply-To: <5474A07C.5030701@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1416941655; bh=ZECEc4L31lqAap4UGZ4Z2OKpJEEyvmqNPsD+F2Ow/0E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bUNYym//mHx4FNbbxoi1uKDxVjIiQbCHCudT+HdLTKkQ/tEz7wpLK40TiMb6OsCIE 73cCKC2IX4owNA0o2Q9Ru4HboELK8q9LnjbH58Fj8/j2AeEJVQZ6Bq6DgNRDTek/XX Gn5Zy3fkr4we/CHEC88s//Mi9Iwm6ch4vxQomXzs6rZl0N/3mKM2vssQFJkpub/yL0 T0y9ABSGqGWuYPaDfW2aBzvdDbQWJ10BLuJAfDJaRNwQhl/BiD0cDSrDKXSIsnbqVd sTnzbapPsAA6TEZ7pSlsn4ooB6k8mGiCnYctIhcySEW4KH6iirjwKL7HoRDm8CV4T2 ID02dLuFi35Pw==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/i_t9_mNH8CDpebE6i7fxtCtPzTk
Subject: Re: [MMUSIC] Single SCTP usage per SDP session?
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: Tue, 25 Nov 2014 18:54:18 -0000

On 11/25/14 10:30 AM, Adam Roach wrote:
> I want to go on record to say that this is the least readable
> quoting/reply style I've ever had to deal with in my life. I lost track
> of the conversation about three messages ago.

+1 !!!

> /a
>
>
> On 11/25/14 08:03, Christer Holmberg wrote:
>>
>> Hi,
>>
>> /<Christer> This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used to determine the TLS role./
>> */<Raju2>/*
>> /2 use cases:/
>> /1.SCTP over DTLS: For this yes, a=setup is for DTLS./
>> /   The sctp port usage needs be clarified indicating it is the server port, not the client port./
>> /  /
>> /<Christer2> Yes./
>> /  /
>> /  /
>> /2.Native SCTP: I believe a=setup is for SCTP association./
>> /When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well./
>> /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1  <http://tools.ietf.org/html/rfc4960#section-5.2.1>  and5.2.2  <http://tools.ietf.org/html/rfc4960#section-5.2.2>  ./
>> /But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation./
>> /So, I believe some clarifications are needed in this area./
>> /  /
>> /<Christer2> So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations./
>> /  /
>> /But, that also applies to SCTP over DTLS, doesn’t it?/
>> */<Raju3>/*
>> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP” instead of “SCTP over DTLS”. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here./*
>> */  /*
>> /<Christer3> The idea was to not use a=setup for any “type” of SCTP, including native SCTP./
>> /  /
>> /Regards,/
>> /  /
>> /Christer/
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>