Re: [rtcweb] Death of a one-way stream (#76)

Harald Alvestrand <harald@alvestrand.no> Tue, 11 November 2014 20:49 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FCF1AC3BA for <rtcweb@ietfa.amsl.com>; Tue, 11 Nov 2014 12:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.594] 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 vxHu0m3x1vBA for <rtcweb@ietfa.amsl.com>; Tue, 11 Nov 2014 12:49:36 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9BB1AC3B5 for <rtcweb@ietf.org>; Tue, 11 Nov 2014 12:49:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 73B717C01F5 for <rtcweb@ietf.org>; Tue, 11 Nov 2014 21:49:35 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjU98k3MHfub for <rtcweb@ietf.org>; Tue, 11 Nov 2014 21:49:31 +0100 (CET)
Received: from [IPv6:2001:67c:370:160:4805:b828:f652:a1bd] (t2001067c037001604805b828f652a1bd.wireless.v6.meeting.ietf.org [IPv6:2001:67c:370:160:4805:b828:f652:a1bd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6015E7C01F3 for <rtcweb@ietf.org>; Tue, 11 Nov 2014 21:49:30 +0100 (CET)
Message-ID: <54627654.5010408@alvestrand.no>
Date: Tue, 11 Nov 2014 12:49:24 -0800
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAMRcRGQH9eNfXdnWxwY-r5S3Kt7dX9MuY74eVc7pihwYXYB9gQ@mail.gmail.com> <CAOJ7v-3b9DGCeq6Zx-sAOYD65CKmf2Mw+HV+3T+PgKcf=_V5VA@mail.gmail.com> <CABkgnnUP30iQjjOD6aZ0cdntM2YLxReUgQHxv+ko3TtwG-q0Ug@mail.gmail.com> <CAMRcRGSA8wQG4QtL7NJQ6F5sc_wTxH=NcJLhNrjs_0X7w1fyCQ@mail.gmail.com>
In-Reply-To: <CAMRcRGSA8wQG4QtL7NJQ6F5sc_wTxH=NcJLhNrjs_0X7w1fyCQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030002050509090908090702"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qI8r3ds6Hn9bWWrjyOt9Z3hVnp8
Subject: Re: [rtcweb] Death of a one-way stream (#76)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Nov 2014 20:49:41 -0000

This seems like a wonderful spec, and clearly within the scope of MMUSIC.

Once the 4 pages of boilerplate and the 9 sections of O/A semantics have
been added, I think it would be a very reasonable draft, and will
certainly be processed reasonably quickly - say, adopted before the end
of 2015 and forwarded to the IESG before the end of 2016. (sorry if I
seem a bit frustrated - I'm trying to figure out what to say about the
status of MSID in MMUSIC).

Or is it already in some spec that is in some stage of processing somewhere?


On 11/11/2014 12:14 PM, Suhas Nandakumar wrote:
> here is one possible way ..... 
>
> *New SDP Attributes : Media intent for Unidirectional Streams 
> *
>
> m=recv-intent: <action>
> m=send-intent: <action>
>
> These attributes express the intent of the end-point generating the
> SDP on the send and receive state of the media stream
>
> <action> : pause | end
>
> there is no default action other than what gets implied from the media
> direction and/or port number configuration. 
>
>
> *For the use-case from Justin:*
> A and B are exchanging media.
> B stops A's stream, i.e., it no longer wants to receive media from A.
> However, B still wants to send media to A.
> So if B changes the m= line to a=inactive, B's stream stops as well.
>
> B's SDP Offer
>  m=sendonly
>  m=recv-intent:end   [ saying i don't want inbound media on this m=
> line anymore]
>
> A's SDP Answer
> m=recvonly
> m=send-intent:end   [ m= line can be recycled]
>
>
> *For the use-case from Martin:*
> where B disposes of their stream and
> can't resurrect it.  A doesn't know that this is a terminal state for
> that media section.
>
> B's SDP Offer
>  m=recvonly
>  m=send-intent:end   [ saying i will not be sending and thus m= line
> can be recycled]
>
> A's SDP Answer
>  m=sendonly
>  m=recv-intent:end 
>
>
> *Use-case for temporarily pausing the stream*
> A and B are exchanging media.
> B pauses A's stream, 
> However, B still wants to send media to A.
>
> B's SDP Offer
>  m=sendonly
>  m=recv-intent:pause
>
> A's SDP Answer
>  m=recvonly
>  m=send-intent:pause [ m= line cannot be recycled]
>
> Now B want's to start receiving media from A
> B's SDP Offer
>  m=sendrecv  [ bidirectional stream, overrides any unidirectional intents]
>
> A's SDP Answer
>  m=sendrecv
>
>
> In this scheme the action is non-negotiable and thus has to be replied
> in the answer.
>
>
>
>
> Thanks
> Suhas
>
>
>
>
>
> Also to note, this attribute can be used at the media level or the
> source level.
>
>
>
>
> On Mon, Nov 10, 2014 at 5:09 PM, Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 10 November 2014 18:52, Justin Uberti <juberti@google.com
>     <mailto:juberti@google.com>> wrote:
>     > A and B are exchanging media.
>     > B stops A's stream, i.e., it no longer wants to receive media
>     from A.
>     > However, B still wants to send media to A.
>     > So if B changes the m= line to a=inactive, B's stream stops as well.
>
>
>     Yep, and then there is the case where B disposes of their stream and
>     can't resurrect it.  A doesn't know that this is a terminal state for
>     that media section.
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.