IETF Logo Mail Archive

Re: [MMUSIC] SCTP AppID

Salvatore Loreto <salvatore.loreto@ericsson.com> Thu, 06 March 2014 13:36 UTC

Return-Path: <salvatore.loreto@ericsson.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 AF7231A0300 for <mmusic@ietfa.amsl.com>; Thu, 6 Mar 2014 05:36:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level:
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 uRkCrU02Xw4x for <mmusic@ietfa.amsl.com>; Thu, 6 Mar 2014 05:36:20 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB9F1A0307 for <mmusic@ietf.org>; Thu, 6 Mar 2014 05:36:19 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-9e-531879ce471b
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 0A.8C.04853.EC978135; Thu, 6 Mar 2014 14:36:15 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 14:36:14 +0100
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
To: Christian Groves <Christian.Groves@nteczone.com>
Thread-Topic: [MMUSIC] SCTP AppID
Thread-Index: AQHPOS8NfxpP/0XfyUaZJY1aq+ki1prT2zMAgAAc74CAAAbSAA==
Date: Thu, 06 Mar 2014 13:36:13 +0000
Message-ID: <C1D662DF-E3E3-45CD-991F-8090CD7130E0@ericsson.com>
References: <53185B8E.2070808@nteczone.com> <C8EB64C0-3140-477C-9373-BD36B4B1A64B@ericsson.com> <53187415.2000108@nteczone.com>
In-Reply-To: <53187415.2000108@nteczone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <495AA47A7DF45C4999F982D70C778467@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje75Solgg5mKFl/eN7JYTF3+mMWB yWPJkp9MHivOz2QJYIrisklJzcksSy3St0vgyjh2fi1LwQ3eiq83D7M1MP7g6mLk5JAQMJH4 sOc4E4QtJnHh3nq2LkYuDiGBE4wS+2efgnIWM0pcnDoJrIpNwEzi+cMtzF2MHBwiQN3zz2qC hJkFNCUmdD9hA7GFBRQkJiz9DWaLCChKnL80nwWi3Eli65pIkDCLgIrEqWOPWEBsXgF7idaO S6wQq5oZJT5eO8MIkuAU0JG41v+SHcRmBDru+6k1TBC7xCVuPZkPdbSAxJI955khbFGJl4// sULYShJrD29ngajXk7gxdQobhG0tMavpFiOErS2xbOFrZogjBCVOznzCMoFRfBaSFbOQtM9C 0j4LSfssJO0LGFlXMUoWpxYX56YbGejlpueW6KUWZSYXF+fn6RWnbmIERt3BLb+NdjCe3GN/ iFGag0VJnPc6a02QkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsadzB856mMyHdO6JOVufBIK mmeyqeXj1ru8x3hlz5Z5rlC1iXxuoqd+d3LtDde/4VlOs29skP/8ZHp158N9AtGZO6WWSeQw TdJ7KdgzQ/rm+iQ5jYdX7Jxeibw16Pj40jvuZkErZ1zV3YJTpWXsTe4bN6fv67VI3Sv0Y8/i mOvmXWzvLN9O0FNiKc5INNRiLipOBABmeD0OiAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/6twhyg7Prc8jl1ZoekCJR1ZW-pc
Cc: mmusic mailing list <mmusic@ietf.org>
Subject: Re: [MMUSIC] SCTP AppID
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, 06 Mar 2014 13:36:21 -0000

Hi Christian

to be clear I don't think to register an ALPN for data channel is the right solution 

I understood Martin was only proposing to look at how ALPN defines and handles the registry
and do something similar not using it. Am I wrong?
IMO ALPN parameter defines the protocol that will run on top of TLS (not sure it can be used for DTLS to)
We are running SCTP over DTLS, so we could use it at least to say SCTP

the app parameter is trying to define how SCTP streams are handled here
i.e. "data channel" is a pair of one incoming stream and one outgoing SCTP 
stream having the same stream SCTP identifier.

the protocol or better subprotocol will run then on top of the data channel

/Sal


On Mar 6, 2014, at 1:11 PM, Christian Groves <Christian.Groves@nteczone.com>
 wrote:

> Hello Salvatore,
> 
> OK, I guess one of the RTCweb drafts would then include the request to IANA to register an ALPN for the data channel.
> 
> One thing I'm still missing is how you specify multiple apps/alpns (whatever we're calling them) being used in a single SCTP association, without using datachannel?
> 
> 
> Christian
> 
> On 6/03/2014 10:28 PM, Salvatore Loreto wrote:
>> yet it is
>> 
>> /Sal
>> 
>> On Mar 6, 2014, at 11:27 AM, Christian Groves <Christian.Groves@nteczone.com>
>>  wrote:
>> 
>>> Hello Martin,
>>> 
>>> When you mentioned ALPN is this the draft you were talking about? http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05
>>> 
>>> Regards,
>>> Christian
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
>

v2.46.0 | Report a Bug | By Email | System Status