Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines in SDP)

Randell Jesup <randell-ietf@jesup.org> Mon, 23 April 2012 08:26 UTC

Return-Path: <randell-ietf@jesup.org>
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 6102E21F862B for <rtcweb@ietfa.amsl.com>; Mon, 23 Apr 2012 01:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level:
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599]
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 zoJG+wswbwOX for <rtcweb@ietfa.amsl.com>; Mon, 23 Apr 2012 01:26:52 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61721F8628 for <rtcweb@ietf.org>; Mon, 23 Apr 2012 01:26:51 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1SMEbh-00062l-TS for rtcweb@ietf.org; Mon, 23 Apr 2012 03:26:50 -0500
Message-ID: <4F951221.1050700@jesup.org>
Date: Mon, 23 Apr 2012 04:26:09 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfkBFNv6emEg6gkxV+iPkx52rUwn+qcyEjk2r4iDYEXrAA@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines in SDP)
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: Mon, 23 Apr 2012 08:26:55 -0000

On 4/23/2012 2:40 AM, Christer Holmberg wrote:
> Hi,
>
> I see no reason why you couldn't release resources when you disable media (read:
> set port to zero), but still re-use the associated m- line later.

Exactly - m-lines can't be removed, but they can be re-used - and the 
critical point is that the port doesn't have to match the previous port. 
  So generally they should be no worse than a high-water-mark of the 
number of audio and video streams in use at any one time.

Of course with bundle the port issue is simpler.

> From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Iñaki Baz Castillo [ibc@aliax.net]
>
> Hi, a stream in an SDP cannot be removed but just "disabled" (by
> setting its port to 0). In the same media session a participant could
> add a video stream and "disable" it later multiple times.
>
> Let's assume a media session initiated with just an audio stream:
>
> 1) A participant adds a video stream and the remote accepts it. This
> involves a new media section in the SDP.
> 2) Later the same participant removes the video stream which means
> setting its port to 0 in the SDP.
> 3) Later he adds video again.
> 4) ...and so on.
>
> AFAIK there are two choices for step 2 and 3:
>
> a) Releasing video resources and the UDP socket so when video is
> enabled again a new line should be added to the SDP and new resources
> (ICE, UDP socket) required.
>
> b) Not releasing all the resources (keep the UDP socket but stop
> sending/receiving data on it), and re-enabling it when video is added
> again, so the same SDP line would be reused by setting its port to the
> previous value.
>
>
> Choice a) means more and more lines in the SDP for each video
> activation. Option b) means not releasing resources after disabling a
> media stream.
>
> If I'm not wrong in the above text, which would be the WebRTC approach
> for this topic?

-- 
Randell Jesup
randell-ietf@jesup.org