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 ----------------------------------------------------------------------
- [RAI] Using media stream signaling in media plane… Bo Burman
- Re: [RAI] Using media stream signaling in media p… Paul Kyzivat
- Re: [RAI] Using media stream signaling in media p… Magnus Westerlund