Re: [RAI] Using media stream signaling in media plane or in signaling plane (re-send)

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 24 July 2012 07:08 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEB011E811C for <rai@ietfa.amsl.com>; Tue, 24 Jul 2012 00:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.902
X-Spam-Level:
X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 w-ZVZc8-OREl for <rai@ietfa.amsl.com>; Tue, 24 Jul 2012 00:08:28 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD1A11E8119 for <rai@ietf.org>; Tue, 24 Jul 2012 00:08:27 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f6c6d000001cc5-cb-500e49e903ad
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A3.A6.07365.9E94E005; Tue, 24 Jul 2012 09:08:25 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Tue, 24 Jul 2012 09:08:25 +0200
Message-ID: <500E49E8.3050708@ericsson.com>
Date: Tue, 24 Jul 2012 09:08:24 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <05F760EF51FA6A4F804F9759C239313A45E750C5AD@ESESSCMS0361.eemea.ericsson.se> <500D6079.9050909@alum.mit.edu>
In-Reply-To: <500D6079.9050909@alum.mit.edu>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre5LT74Ag1/TjS1WbDjAavF5yzNW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj401ZwWehiiUfT7M2MC7n72Lk5JAQMJFo Ob6CCcIWk7hwbz1bFyMXh5DAKUaJaz9nMkE4yxkl3v+5xghSxSugLXFx7kk2EJtFQFViwZp2 sDibgIXEzR+NYHFRgUCJb1uPs0LUC0qcnPmEpYuRg0NEQENi0lY1kDCzgKLE0wnbwFqFBRIk 5nW2gdlCAuUSJw49AmvlFNCReLC4lQmkVUJAUuL2gRSIVj2JKVdbGCFseYnmrbOZIVq1JRqa OlgnMArNQrJ4FpKWWUhaFjAyr2IUzk3MzEkvN9RLLcpMLi7Oz9MrTt3ECAzfg1t+6+5gPHVO 5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M3g8XWRsk+q5zPX5O+tc+ s4hvRnx7ut7WOT7aedf/VfXrl0+rFf1nqvQu/uB+4eUsu4RdV65lN8Z7SD87KHZXhU+BRYZH aqdp3qxCdcnEdM+nut/0xWMaZ3nEewV8/y5X+/N0V5L3SoNb7PsP/fzCO7+2NH1mxqU6yWU8 B8N/9u2dejXBbbGtEktxRqKhFnNRcSIANawISy0CAAA=
Cc: "rai@ietf.org" <rai@ietf.org>
Subject: Re: [RAI] Using media stream signaling in media plane or in signaling plane (re-send)
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jul 2012 07:08:28 -0000

On 2012-07-23 16:32, Paul Kyzivat wrote:
> Bo,
> 
> Did you consider the implications if there is more than one stream to be
> paused? (E.g. it's an audio+video call.)
> 
> Presumably that would double the message traffic when done in the media
> streams, but not when done in sip. (But the absolute delays may be no
> different.)

Paul,

When it comes to multiple streams it will highly depend on if the
different streams belong to the same RTP session or not. If they are
within the same RTP session the RTCP based method will add one more FCI
block per SSRC, i.e. for a PAUSE or resume request 8 more bytes. And for
example you can pause one SSRC and resume another with the same RTCP
packet.

If they are from different RTP sessions then different RTCP packets will
be required. Thus you get different scheduling of the request packet and
clearly two RTCP packets bringing up the overhead a bit, to at worst
case a minimal compound RTCP packet, i.e. around 120-140 bytes depending
on CNAME length. It will take at least 5-10 RTP sessions being
simultaneously manipulated using RTCP to have approximately the same
aggregated size as using SIP. I think the main question around this
direction of discussion if any application has very strict requirements
on having atomic operations between RTP sessions. I personally haven't
seen any such case.

And Paul's example of audio and video being paused may not be the best
although in no way prohibited. But one common usage we see for this is
to pause the video stream that is responsible for the larger amount of
data while keeping the audio running to a RTP mixer. Then have that
mixer base its decision on what video streams it provides the other
session participants based on the audio activity. There might be cases
where pausing both audio and video simultaneously is a reasonable usage,
and if you have a more concrete example I would appreciate it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------