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

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 10 Nov 2014 16:30:27 -1000

For the issue in subject line , how about we use a=sendonly/inactive to
differentiate the scenarios

Use a=inactive : if as a remote end I want to permanently stop getting
media and sending media , such a media line can be recycled

Use a=sendonly : if as a remote end I want to temporarily pause the
incoming media (putting on hold) and such a media line must not be recycled.

If this is not enough, we can always add an attribute to clarify the exact
semantics ..

Cheers
Suhas

---

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Nov 2014 18:52:51 -0800

> media and sending media , such a media line can be recycled

This unfortunately doesn't work. Consider the following scenario:

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.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Nov 2014 19:09:05 -0800

> 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.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Nov 2014 03:32:57 +0000

Hi,

I don’t think we can change the semantics of the inactive attribute. You may receive such from a legacy device (“WebRTC compliant endpoint”), which does NOT want to permanently stop sending/receiving media.

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 11 November 2014 04:30
To: [email-masked]
Subject: [rtcweb] Death of a one-way stream (#76)

For the issue in subject line , how about we use a=sendonly/inactive to differentiate the scenarios

Use a=inactive : if as a remote end I want to permanently stop getting media and sending media , such a media line can be recycled

Use a=sendonly : if as a remote end I want to temporarily pause the incoming media (putting on hold) and such a media line must not be recycled.

If this is not enough, we can always add an attribute to clarify the exact semantics ..

Cheers
Suhas

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 11 Nov 2014 10:14:35 -1000

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

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.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Nov 2014 12:49:24 -0800

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:
> 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
>
>  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   [ saying i will not be sending and thus m= line
> can be recycled]
>
> A's SDP Answer
>  m=sendonly
>  m=recv-intent:end 
>
>
> 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
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 10 November 2014 18:52, Justin Uberti <[email-masked]
>     <mailto:[email-masked]>> wrote:

-- 
Surveillance is pervasive. Go Dark.