[MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP
Christer Holmberg <christer.holmberg@ericsson.com> Fri, 21 November 2014 19:17 UTC
Return-Path: <christer.holmberg@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 946621A01AE for <mmusic@ietfa.amsl.com>; Fri, 21 Nov 2014 11:17:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ch2LCjvA6s3d for <mmusic@ietfa.amsl.com>; Fri, 21 Nov 2014 11:17:03 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67131A007E for <mmusic@ietf.org>; Fri, 21 Nov 2014 11:17:02 -0800 (PST)
X-AuditID: c1b4fb2d-f79fc6d000001087-bb-546f8face7ec
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.40.04231.CAF8F645; Fri, 21 Nov 2014 20:17:00 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 20:17:00 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg and DCEP
Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHw==
Date: Fri, 21 Nov 2014 19:16:58 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D52ED2EESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6a/vwQg0OnFC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHcrJjEVXJevaJ7eyd7AeEy6i5GTQ0LAROLh29dsELaYxIV7 64FsLg4hgSOMEk2vLjNCOEsYJWau+MHaxcjBwSZgIdH9TxukQURAXeLr3h5mkLAwUHjpfQ+I sK3E9Cf7WCBsPYlzM24yg9gsAqoSP+/+AtvFK+ArMf3sFLAaRqC930+tYQKxmQXEJW49mc8E cY+AxJI955khbFGJl4//sULYShKNS56wQtTnSxz+uYcJYqagxMmZT1gmMArNQjJqFpKyWUjK IOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2M wIg4uOW37g7G1a8dDzEKcDAq8fBuWJUXIsSaWFZcmXuIUZqDRUmcd9G5ecFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGI1qDJ7Ms3jFVhubI5u8ophrF0N7cYD0ws0aG3qrguym28QKzExd 3q+64d+5Ccn/8xkubXNkvXRsCRuDpggLj7T7XIO5gi3iq7LnPZkq/ykuNK1SclP7hcKbgiea p2Xu1tcwsv6ackx/8g59lY55K9SPJNsG/j15oEp6scjhxGkeYduqyhznKrEUZyQaajEXFScC AKauc+xpAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yEOF-NJLPn-LqeWp3QwZdJDOttk
Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP
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: Fri, 21 Nov 2014 19:17:05 -0000
Hi, draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that DCEP will not be used to open data channels - instead data channels will be considered open once the SDP O/A negotiation has finished and the SCTP association used to realize the data channel(s) has been created. My question is whether the intention is to forbid usage of DCEP together with draft-ejzak-mmusic-data-channel-sdpneg, or whether it should be optional? If optional, there needs to be a way to indicate that application data shall not be sent until a channel has been opened using DCEP. In addition, it would be useful to be able to indicate which endpoint is responsible for sending the DCEP_CHANNEL_OPEN message. Regards, Christer
- [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg a… Christer Holmberg