Re: [rtcweb] A problem with both A and B

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 30 May 2013 17:26 UTC

Return-Path: <fluffy@cisco.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 8FC7821F9625 for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 10:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.399
X-Spam-Level:
X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 VaBaxpXPxJ9f for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 10:26:26 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE421F9397 for <rtcweb@ietf.org>; Thu, 30 May 2013 10:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1142; q=dns/txt; s=iport; t=1369934785; x=1371144385; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eTFmeaMcFWQNvlCneUusZgOEINWQR9bviCj4gPN5C2w=; b=WlZl6yP6Ithsk7XaOC1wNRfSyIav/ucZcmBo/9vm6KzDHvuz7ekBbGOX pniG++G2CvcRytUQz5b1C/3tmxVil7j5Ky3Kh1aDZHLJ6bXzT1XrGB7Ym tql7IPWgdDD4784d9Gl6ru/LLDIaeIQsQc14nBxaPtpkXQ4/1Mi3oT9EL s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAI+Kp1GtJXG+/2dsb2JhbABQCYMJwkZ+FnSCIwEBAQMBOj8QAgEIDgoKFBAyJQIEDgUIh38Gu3CNYYEIAjEHgnZhA6h+gw+CJw
X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216925714"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 30 May 2013 17:26:21 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4UHQL1H011044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 17:26:21 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 30 May 2013 12:26:21 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [rtcweb] A problem with both A and B
Thread-Index: AQHOXVrM3QhpqWEsQEOof9XIjI1G9Q==
Date: Thu, 30 May 2013 17:25:23 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11352437E@xmb-aln-x02.cisco.com>
References: <51965506.7050008@jitsi.org> <CAMvTgccSpdAa2F26eeRg61mLQg+ThWfHNU5xXHwz0Ap7bePxBQ@mail.gmail.com> <5199EE06.30705@jitsi.org>
In-Reply-To: <5199EE06.30705@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <977A77DA82C175499F92B6545E4F18DE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] A problem with both A and B
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: Thu, 30 May 2013 17:26:31 -0000

On May 20, 2013, at 3:33 AM, Emil Ivov <emcho@jitsi.org> wrote:

> 
> 
> On 20.05.13, 11:53, Kevin Dempsey wrote:
>> Relying on SSRC signalling would mean that RTP sent before the SSRC
>> identity arrives would not be handled consistently with RTP arriving
>> after the SSRC identity.
> 
> If the application is doing the SSRC signalling and if the WebRTC API
> provides a way of retrieving it, an app would be able to signal an SSRC
> before, together with, or after the SDP from O/A. It will all be up to
> exactly what the app needs.
> 
> Emil

Uh, so I thought that is how both plan A and plan B worked. Yes the syntax of the passing the SSRC across the API uses SDP in both cases but the application can do whatever it wants with and provide it any way it wants. What am I missing? I think people long ago agreed stats API would reflect up SSRC and other information to the application as a second path that is not SDP. 

If you are suggesting that a syntax like JSON would be better than SDP syntax to pass the semantic information across the JS API, well that back to comment 22.