IETF Logo Mail Archive

Re: [rtcweb] #23: Section 4.4 SDP signaling requirement

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 26 August 2013 06:28 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C094611E814B for <rtcweb@ietfa.amsl.com>; Sun, 25 Aug 2013 23:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.646
X-Spam-Level:
X-Spam-Status: No, score=-103.646 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ix7isGq+KTv for <rtcweb@ietfa.amsl.com>; Sun, 25 Aug 2013 23:28:47 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEA421F8F07 for <rtcweb@ietf.org>; Sun, 25 Aug 2013 23:28:44 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-c0-521af59b217b
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1C.97.25272.B95FA125; Mon, 26 Aug 2013 08:28:44 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.19) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.328.9; Mon, 26 Aug 2013 08:28:42 +0200
Message-ID: <521AF5E0.2050001@ericsson.com>
Date: Mon, 26 Aug 2013 08:29:52 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb issue tracker <trac+rtcweb@trac.tools.ietf.org>
References: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org>
In-Reply-To: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvje6cr1JBBhO2sVrsX3KZ2WJ+Vyur xdp/7ewW93eWO7B4PO45w+axZMlPJo8vlz+zefzcs5k1gCWKyyYlNSezLLVI3y6BK2Pf52cs Bee4KybMVG5g3MPZxcjJISFgIvHs3VFWCFtM4sK99WxdjFwcQgJHGSWWHVzNDJIQEljGKHGm VwzE5hXQlph/7hIbiM0ioCrRNfkumM0mYCFx80cjmC0qECzRvv0rG0S9oMTJmU9YQGwRASuJ K5cngsWZBZIkti86zdTFyMEhLOAgsXxOFcQqN4krk7vB7uEUcJdo+7iGGeI2SYlti46xQ7Rq SrRu/w1ly0s0b50Ndaa2RENTB+sERqFZSDbPQtIyC0nLAkbmVYwcxanFSbnpRgabGIHhfHDL b4sdjJf/2hxilOZgURLn3aJ3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI0Pb9n0ml/vO cNyLCmnh2+ObtE2dqXxSvAv/Jpt1Ve+M+ZcxXhNMvBpfxTvXyE7qxMnLLzwmZkXz+wq7Xjx4 Ukz0U0SXoIT+BN3Z9vmmlTZpXVdzLp5+dMvCqC1/VYv65nJN5YUn7x5YW/y4ptB+8hOuiHyu dUHKq18cCm+7+K7Kd9+tr4k6SizFGYmGWsxFxYkAEOC9LDUCAAA=
Cc: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, rtcweb@ietf.org
Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2013 06:28:54 -0000

On 2013-08-26 00:30, rtcweb issue tracker wrote:
> #23: Section 4.4 SDP signaling requirement
> 
>  If such RTP session set-up is to be used, this MUST be negotiated during
>  the signalling phase [I-D.ietf-mmusic-sdp-bundle-negotiation].
> 
>  [BA] What about WebRTC applications that don't use SDP for signaling? Or
>  applications that decide to multiplex Audio and Video because they know
>  that the peer supports it?  Mandating the use of BUNDLE negotiation on the
>  wire doesn't make sense.
> 

Well, the current API to my understanding only provides SDP in the API
to input and output information related to bundle signaling.

The goal from our perspective is to ensure that features that affects
RTP session configuration are negotiated between the peers in the RTP
session. As interoperability failure will occur if the peers don't agree
on using one RTP session for all media types or using a separate RTP
session per media type this is something that requires negotiation.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email