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

Suhas Nandakumar <suhasietf@gmail.com> Tue, 11 November 2014 20:15 UTC

Return-Path: <suhasietf@gmail.com>
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 892B81A90C7 for <rtcweb@ietfa.amsl.com>; Tue, 11 Nov 2014 12:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no
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 X2mrAwwSI16J for <rtcweb@ietfa.amsl.com>; Tue, 11 Nov 2014 12:15:39 -0800 (PST)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E891A902E for <rtcweb@ietf.org>; Tue, 11 Nov 2014 12:14:36 -0800 (PST)
Received: by mail-pa0-f47.google.com with SMTP id kx10so11295860pab.20 for <rtcweb@ietf.org>; Tue, 11 Nov 2014 12:14:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x+fcxxrmruIZr9q1PKvfHjvJ8G5SGcSEpDcO8oqYI10=; b=dUqprnevZATLLXP/k7sibMMQupFZcBMYsKab4VDVv16JtWN+JD7Cw6DcjLGPmEaMVe KKmeEKZfHZ/NffFrkFpwA9sEW/l5UMCRs+7RzIWTZRk0nYcNLjUfPSzyC87eS7XV9kQ3 VUyna28uwgvpcz6K7ZhQB8Kbj9lJa7zQlBWX8fkVle5LyNiUOqxDYEqtssYFKMQXk9Zn 8NPS0khTGy4ACBIo/GH9tqbOMAbm825XVOD+SyUPcgC5Fzwafyd03SpWS1SjWqDov5AF 177iglGFTVEwTz4cfFtpsn+JI7W+zH4EbgXoQ15Cp8O79uXSBSEcUfDtjn/uxH0/Y/GX 9AgA==
MIME-Version: 1.0
X-Received: by 10.70.33.195 with SMTP id t3mr14567663pdi.135.1415736875820; Tue, 11 Nov 2014 12:14:35 -0800 (PST)
Received: by 10.70.60.201 with HTTP; Tue, 11 Nov 2014 12:14:35 -0800 (PST)
In-Reply-To: <CABkgnnUP30iQjjOD6aZ0cdntM2YLxReUgQHxv+ko3TtwG-q0Ug@mail.gmail.com>
References: <CAMRcRGQH9eNfXdnWxwY-r5S3Kt7dX9MuY74eVc7pihwYXYB9gQ@mail.gmail.com> <CAOJ7v-3b9DGCeq6Zx-sAOYD65CKmf2Mw+HV+3T+PgKcf=_V5VA@mail.gmail.com> <CABkgnnUP30iQjjOD6aZ0cdntM2YLxReUgQHxv+ko3TtwG-q0Ug@mail.gmail.com>
Date: Tue, 11 Nov 2014 10:14:35 -1000
Message-ID: <CAMRcRGSA8wQG4QtL7NJQ6F5sc_wTxH=NcJLhNrjs_0X7w1fyCQ@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bf18e58942e4a05079aedef"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d2ivHXo0TG91nSMCYkFGlOl6u8U
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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:15:41 -0000

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>
wrote:

> On 10 November 2014 18:52, Justin Uberti <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.
>