Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Silvia Pfeiffer <> Wed, 19 June 2013 02:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14E2D21F9954 for <>; Tue, 18 Jun 2013 19:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PTZDRGQnSDFq for <>; Tue, 18 Jun 2013 19:36:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::229]) by (Postfix) with ESMTP id E111C21F9921 for <>; Tue, 18 Jun 2013 19:36:13 -0700 (PDT)
Received: by with SMTP id 10so12279213ied.0 for <>; Tue, 18 Jun 2013 19:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yGXdYSVyoEepJkzSdpgzSZIxmg7mNkmqcmD72sYVrR4=; b=uAIcVVm/Vbbp5/LnkLXK4YfO0Swry263PEpl9MgIG9ueu+Dul37IRtSllb8IMxpCaX 4p71AWaPjgndmeJyWDDIGUnWsoiVYZtlxG953X5o/krfaPGuWVF5YHzmXfdlWA0JGycl pnuhG+HMWWyJDdPE5lO2y3Yp+LdkjBSLhXr62qrT7RjLmllP59HSzFcX6sx6YB4CAqJ5 p2uP3Da5kbMLbR5Q3al05vHqmhtIbw7mIGLZqh85MuLiwuupKsxv1EBEX9YuvC1BREGZ LTUDCBG3+sX6cbbl336P0s+BoUFiCcaKBkdhxVHRz5TmLvupNPoL5dHbBUdookk3UQ4i AOmQ==
X-Received: by with SMTP id io5mr320504igb.27.1371609373419; Tue, 18 Jun 2013 19:36:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Jun 2013 19:35:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Silvia Pfeiffer <>
Date: Wed, 19 Jun 2013 12:35:53 +1000
Message-ID: <>
To: Max Jonas Werner <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jun 2013 02:36:15 -0000

On Tue, Jun 18, 2013 at 10:25 PM, Max Jonas Werner <> wrote:
> Hej Silvia,
> On 18.06.2013 08:25, Silvia Pfeiffer wrote:> On Tue, Jun 18, 2013 at
> 4:17 PM, Emil Ivov <> wrote:
>>> On 18.06.13, 03:00, Silvia Pfeiffer wrote:
>>>> What I would like to see, though, is a bit different from what you've
>>>> proposed. In particular, the MediaFlowDescription object is the one
>>>> object that I believe is supposed to enable JS developers to  do "SDP
>>>> hacking" without having to understand SDP. Unfortunately, the way in
>>>> which it is currently written, this API doesn't help a JS developer
>>>> much. There are properties in that object like "ssrc" that mean
>>>> nothing unless you understand SDP.
>>> SSRC is really just a flow identifier and it actually comes from RTP, not
>>> SDP.
>> OK, could we call it rtpflowId or mediaflowId or peerflowId or
>> something? And what exactly are the other identifiers?
>> (You will notice that I am really naive wrt SDP, sorry!)
> Do you really want to create a second "terminology world"? For people
> who don't know what SSRC means (because they don't know RTP) it may seem
> reasonable but to those who already know RTP you'd have to explain
> "yeah, rtpflowId is actually SSRC." So the term SSRC would have to be
> included in the spec anyway.

You can leave mention of SSRC to a comment in the spec next to rtpflowId.

> I'm not sure if having different names for the same thing would lead to
> less confusion.

If SSRC is the name it's given in SDP and we want to get away from
SDP, this would be a first step, wouldn't it?