Re: [rtcweb] Use cases - recording and voicemail

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 22 August 2011 20:45 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 9DA6E21F8AAA for <rtcweb@ietfa.amsl.com>; Mon, 22 Aug 2011 13:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 5kVzMLcvuVXg for <rtcweb@ietfa.amsl.com>; Mon, 22 Aug 2011 13:45:31 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id CE59321F8AA8 for <rtcweb@ietf.org>; Mon, 22 Aug 2011 13:45:29 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id PYln1h0011wpRvQ59Ymcg0; Mon, 22 Aug 2011 20:46:36 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta18.westchester.pa.mail.comcast.net with comcast id PYmP1h01n0tdiYw3eYmVnr; Mon, 22 Aug 2011 20:46:34 +0000
Message-ID: <4E52C02A.900@alum.mit.edu>
Date: Mon, 22 Aug 2011 16:46:34 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <BBF498F2D030E84AB1179E24D1AC41D616C389F16D@ESESSCMS0362.eemea.ericsson.se><BBF498F2D030E84AB1179E24D1AC41D616C389F242@ESESSCMS0362.eemea.ericsson.se>, <A444A0F8084434499206E78C106220CA09BDB6A34F@MCHP058A.global-ad.net><BBF498F2D030E84AB1179E24D1AC41D616C389F245@ESESSCMS0362.eemea.ericsson.se>, <A444A0F8084434499206E78C106220CA09BDB6A397@MCHP058A.global-ad.net><BBF498F2D030E84AB1179E24D1AC41D616C389F24A@ESESSCMS0362.eemea.ericsson.se><2E239D6FCD033C4BAF15F386A979BF510640D0@sonusinmail02.sonusnet.com><A444A0F8084434499206E78C106220CA0B00FDABAD@MCHP058A.global-ad.net> <2E239D6FCD033C4BAF15F386A979BF51064106@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09801F1550D@HKGMBOXPRD22.polycom.com> <2E239D6FCD033C4BAF15F386A979BF51064117@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09801F1555B@HKGMBOXPRD22.polycom.com> <4E52391B.6000900@alvestrand.no> <4E5255D0.90409@alum.mit.edu> <4E52B7E9.1000006@jesup.org>
In-Reply-To: <4E52B7E9.1000006@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Use cases - recording and voicemail
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, 22 Aug 2011 20:45:31 -0000

On 8/22/11 4:11 PM, Randell Jesup wrote:
> On 8/22/2011 9:12 AM, Paul Kyzivat wrote:
>
>> On 8/22/11 7:10 AM, Harald Alvestrand wrote:
>>> On 08/22/11 12:17, Avasarala, Ranjit wrote:
>>>> Hi Partha
>>>>
>>>> I agree with Paul that we could use the recording mechanism discussed
>>>> in siprec mailing list could be added here as webbrowser would
>>>> essentially be a SIP UA which could initiate and terminate SIP
>>>> sessions.
>>> mandatory standard clarification (?):
>>>
>>> .. as somewhere in the combination of the Web browser, the Javascript
>>> and the Web server it connects to, there would be something that
>>> performs the functions of a SIP UA which could initiate and terminate
>>> SIP sessions ...
>>
>> Yes, *something* of this sort - the devil is in the details.
>>
>> IIUC, its the intent of RTCWEB that the media flow directly between
>> source and recipient, rather than following the path of the "signaling".
>>
>> (That of course was also the intent of SIP with proxies, but the almost
>> pervasive use of SBCs has usually forced media to follow the signaling
>> path.)
>>
>> In siprec, it is assumed that an entity called the SRC is in the
>> signaling and media path of the call being recorded, as well as in the
>> signaling and media path of a session with the recorder.
>>
>> If we assume that the RTCWEB "client" is in the media path, but not in a
>> sip signaling path, and that the RTCWEB "server" is sip-capable but not
>> in the media path, then we have a structure that doesn't quite fit the
>> siprec model.
>>
>> However this could perhaps be made to work with siprec via some
>> additional functionality in the RTCWEB client and server, and maybe some
>> tweaks to what is being specified for siprec. The details will depend on
>> which end is making the decision to do recording. If its the client,
>> then that client will need a way to ask "the" server to establish a
>> siprec session and to pass metadata. If its the server that makes the
>> decision, then there needs to be a way for the server to ask the client
>> to fork media and send it to multiple destinations.
>>
>> There are of course privacy concerns in this. Whether they are different
>> in RTCWEB than they are for siprec in general remains to be seen.
>
> There are also other practical issues. In particular with bandwidth: you've
> now roughly tripled the bandwidth requirement of the endpoint: it must send
> to the other end, AND mirror both outgoing (which it controls) and incoming
> (which it doesn't, or only controls very indirectly) to the recording
> server.
>
>
> For cases where you have bandwidth to burn (audio-only calls on broadband)
> you might get away with it. For a video call under any sort of bandwidth
> restraint, it would be a huge problem and would seriously degrade quality.

Re recognize this in siprec. The SRC can be inserted into the signaling 
and media path in a variety of ways. Typical sip deployments today have 
servers in the path that are often not bandwidth constrained.

RTCWEB seems to be revisiting the deployment topologies. Topologies that 
work for recording may also need to be revisited.

	Thanks,
	Paul