Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 01 October 2014 14:14 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 34ABC1ACDBA for <mmusic@ietfa.amsl.com>; Wed, 1 Oct 2014 07:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 WqPQ9HPQnJms for <mmusic@ietfa.amsl.com>; Wed, 1 Oct 2014 07:14:11 -0700 (PDT)
Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6611ACDB8 for <mmusic@ietf.org>; Wed, 1 Oct 2014 07:14:11 -0700 (PDT)
Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-03v.sys.comcast.net with comcast id xqDL1o0014xDoy801qEA3r; Wed, 01 Oct 2014 14:14:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id xqEA1o0033Ge9ey01qEAyA; Wed, 01 Oct 2014 14:14:10 +0000
Message-ID: <542C0C31.70506@alum.mit.edu>
Date: Wed, 01 Oct 2014 10:14:09 -0400
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: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com>
In-Reply-To: <542BB0F7.3090608@nteczone.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412172850; bh=cIYzsfpg+QclUOq5S0qrNSHGLOv05KPF34hFcqsRdi8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rb8x0ldXSA8aN+Ox06dFFRPDv+422LjgGJWVRna3IvpSUfey6Jh2E5w5/iTzX8tId oEpU+ck5CeAAaigXbt01pZvGgeGkHptkItOr5oH14AWp1bMRi+Xy0Yv3crvCh6AeJb AIc88E/ysL8z5jcD5PrwA1Xaz+SZXJVByPZAIjyPtemxb1D5SwFIGhw2rcMS0jTJOJ rord6I5Ox+tiEoh4Be8zdRwLMTkOlZwFeDj3JtdzKf0AQA6Jf2rjxWEsIjyyJO6K1a pFvxDsFfnpw9cyTrCGPwCMQBfQN4K5hFsAzrIBPpYMNN2FCe4fmVuULvAaaO4iG3Lu g3eftnkfjMdtw==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kkxunWXMOooxAkdqQ2z0j6aKJN0
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
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, 01 Oct 2014 14:14:12 -0000

On 10/1/14 3:44 AM, Christian Groves wrote:

>> <Sal>
>> there have been several discussion about the ability to have more than
>> one usage of the SCTP association,
>> and has been agreed not to allow it.
>> So each 'm' line describes a single SCTP association;  each
>> association has only one single specify usage.
>> </Sal>
>
> [CNG] So how would I specify in SDP a scenario where BFCP uses a
> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they
> both use the same DTLS connection? Are these to be separate m-lines?

To have two different SCTP associations over the same DTLS connection, 
they would have to be distinguished by sctp-port. To achieve that you 
could write two m-lines. They would share the same ip address and port, 
and would have different "a=sctp-port" lines. Then they would have to be 
bundled.

Doing that would require extending the definition of bundle to cover 
that case. (There is no *technical* problem in doing this.)

OTOH, in principle they don't need their own SCTP association. AFAIK 
they each only use one sctp stream-pair (channel). If they could agree 
on how to choose channels then they could share an SCTP association. 
That is where draft-ejzak... comes in.

	Thanks,
	Paul