Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API

José Luis Millán <jmillan@aliax.net> Tue, 02 July 2013 18:05 UTC

Return-Path: <jmillan@aliax.net>
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 60DB621F9BCF for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 11:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.126
X-Spam-Level:
X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 RdmlI21a0wp3 for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 11:05:24 -0700 (PDT)
Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1E00521F9BBC for <rtcweb@ietf.org>; Tue, 2 Jul 2013 11:05:24 -0700 (PDT)
Received: by mail-ve0-f177.google.com with SMTP id cz10so5144799veb.36 for <rtcweb@ietf.org>; Tue, 02 Jul 2013 11:05:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pzFOKEc6XivHCEb/hcuqXfLmR1vKIBqnfdg3qaVlWrc=; b=OXSsu2QUgBk1JD7nQBgVpj8u6Kdx1qEobOykk2Rw1jHIoo8A0hrd8yTYVdARvLWVrc 5Oelt3KwTc4DSaFxcNV9lBJbujRLAup0ZYjZxOo90F7dSb1HAh8ta6MI6CoJY4RYudBH N36PKjlYkSY9tyAftEUb1clZc3ICTQmfP2LFPOQinNlj0d5ksAqpTL0vQ9G5Xxmc9BDk ROUG9iwDLTX5W2cRwFXixYuABoqAAc8qdiruG9EQFle0uzplO2Q6dHCPz4PpVNPy3n7S VY892LQwEnhVTc3doI0sXugE/gsffZ0gh+TDZBEFim6r9/73nYeyFysTkyO9txuV9jmA fHAw==
MIME-Version: 1.0
X-Received: by 10.52.33.162 with SMTP id s2mr10110384vdi.37.1372788322447; Tue, 02 Jul 2013 11:05:22 -0700 (PDT)
Received: by 10.220.49.138 with HTTP; Tue, 2 Jul 2013 11:05:22 -0700 (PDT)
In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com>
References: <CABw3bnOp1jY6-ziR-PFG4-fRTT5zQ5ebQkmp5PhzeS1ew=h98g@mail.gmail.com> <51D2FC3C.8090609@telecomitalia.it> <CALiegfkrbw7ouiEP726LMOkGJb3bmicU03svZ-3VMLH3Oxhtjw@mail.gmail.com> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com>
Date: Tue, 02 Jul 2013 20:05:22 +0200
Message-ID: <CABw3bnPFpzvXXz9qdkuYO1g4K=fqhCoQuzCseup0ZzWHoWRXEw@mail.gmail.com>
From: José Luis Millán <jmillan@aliax.net>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Content-Type: multipart/alternative; boundary="20cf307d066a4fc81104e08b3049"
X-Gm-Message-State: ALoCoQmKXNKjvYUSTp0fUrdWk3CsY7Jkjrz8OYpE3x+Zs06OPQZgds6cyT8XhMPREhvmeI5PWxlZ
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API
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: Tue, 02 Jul 2013 18:05:28 -0000

In order to avoid the exposed circumstance, where a user has to 'suppose'
she is sharing her media because there is no way to certainly know, yes,
the JS application should be able to, at least, check if a localMediaStream
is being transmitted out of the RTCPeerConnection.

This would be a simple task if each mediaStream, or mediaStreamTrack had
it's own associated (even if logical because of Boundle) transport. In that
case, such connectivity status would give the information and much more
control over each media element.


2013/7/2 Jim Barnett <Jim.Barnett@genesyslab.com>

> When the JS calls setRemote with the response (which rejects the video),
> the UA will know that the video has been rejected.  Is the idea that the UA
> will let the user know via the chrome?  Do we think it is the JS
> applications job to notify the user of success/failure, or the UA's?  I
> don't recall a discussion of this.
>
> - Jim
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Iñaki Baz Castillo
> Sent: Tuesday, July 02, 2013 12:48 PM
> To: Enrico Marocco
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the
> actual API
>
> 2013/7/2 Enrico Marocco <enrico.marocco@telecomitalia.it>:
> > Audio-only call establishment:
> >
> > A --{"action":"CALL","sdp":"v=0..."}-> B B --{"action":"ACCEPT
> > CALL","sdp":"v=0..."}-> A
> >
> > Rejected audio+video upgrade proposal:
> >
> > A --{"action":"UPGRADE","sdp":"v=0..."}-> B B --{"action":"REJECT
> > UPGRADE"}-> A
>
>
> SDP itself is a media negotiation protocol so SDP (and its WebRTC
> "API") should provide a way to determine whether the remote has accepted
> or not our new stream/track. But how? Current API lacks any kind of event
> for the case in which the remote replies a SDP rejecting our new local
> strem/track.
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



-- 
José Luis Millán