From nobody Tue Jul  1 14:34:15 2014
Return-Path: <br@brianrosen.net>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73201A064E for <siprec@ietfa.amsl.com>; Tue,  1 Jul 2014 14:34:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a9-c9wwDfMn for <siprec@ietfa.amsl.com>; Tue,  1 Jul 2014 14:34:12 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9C01A041F for <siprec@ietf.org>; Tue,  1 Jul 2014 14:34:12 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id e89so4051982qgf.15 for <siprec@ietf.org>; Tue, 01 Jul 2014 14:34:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6nq3hbscAdSypXYD9vf/NBSMmAoGDbFs3TdovIP55IU=; b=dreZ2LDKlZGdqns846nuq3T4iKcCV4h5O4foFxFSFTga0zhBp4PXDkJON2t3lfUIDC QIyN2K8umffG4XcK/lNlFczZSklWZJWs8wVsbiLBrVq/qcndazaZhEL8izqFmypSVjkC KgIrHb8IVAqFwxDTozzpkMGlftUshIPWQcmK60yeLuEbSIGOPLjwZxG4UddxFhzn6+Gt SUyRcdm4jqmYz/pZRDkIg4o2p86QoHOpvBF6xKSQH1jWz9Hf+ShzrdA4Or4v4oNnM+kJ ti9sJ8yR80gHUBNgwXBvDAp3VibLDATpqdJL5+rpEDSuvvvwNrqi2zuLukhvM4iawWS6 Ikqw==
X-Gm-Message-State: ALoCoQkzTPXNDPak326vXRrkzXr6IfuXMB2mo+x6PfjVYW3AdPqy0wwCr96ZRvxbP1wfueWK7zIE
X-Received: by 10.224.22.12 with SMTP id l12mr78713866qab.88.1404250451564; Tue, 01 Jul 2014 14:34:11 -0700 (PDT)
Received: from [10.33.193.19] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id c8sm5698068qam.41.2014.07.01.14.34.10 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 14:34:10 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <53AC4B1A.9050707@alum.mit.edu>
Date: Tue, 1 Jul 2014 17:34:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <ECFDDD30-85A7-471C-95FF-767F82C80946@brianrosen.net>
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/_DVk687YTl7nRI03RJ9vAEKRkaw
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jul 2014 21:34:14 -0000

I=92ve reviewed this document.  I think it is a very good start, and =
think we can get it ready to ship quite quickly.

I have the following comments:

We need to specify a way to send and save REPORTS that are sent/received =
on the CS to the SRS.  If, for example, a message sent by a party to =
another is not received completely, and a REPORT js generated on the RS, =
we need to somehow record than in the CS.  You have a note about =
reports, but it isn=92t clear if you mean reports in the CS or the RS.  =
Both have to be recorded, but at least in the RS, the SRS has all the =
info needed.

I think there is a problem with the text about adding a CPIM wrapper if =
there isn=92t one.  I think the recording has to know if the original =
message was sent by some entity other than the one in the CPIM =46rom =
(that is, we have to preserve the MSRP From).  The SRS has to know =
whether the original message had a CPIM header, and its contents.   If =
the SRC changes the message (by adding the wrapper) I think the SRS has =
to be able to figure that out, and record that fact in some way.

When we echo a message from the RS to the CS, we=92re going to lose the =
MESSAGE-ID from the RS.  That=92s a problem.  We have to save that info =
in the recording.  A hack would be to use the same message ID in both =
the CS and the RS, possibly with some prefix.

I worry a bit about chunking in the RS differently from chunking in the =
CS. I may be mistaken, but if the chunking is different, will that =
affect the byte-range response in a failure report?

The URIs in the original to/from need to be captured, but they will be =
different in the RS.  Need to fix that.

Do we need to say something about max-size issues between CS and RS?

You can=92t possibly not change -metadata.  As an example. you have to =
allow an msrp AoR for a participant

Yes, I think we have to extend Participant to handle nicks.  Probably =
also to handle the SIP session URI vs the MSRP URIs

Brian

On Jun 26, 2014, at 12:32 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> =
wrote:

> Trying one more time. Please!!!
>=20
> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>> Can I get some people in the wg to review and comment on this =
version?
>>=20
>>     Thanks,
>>     Paul
>>=20
>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>> I've submitted a revised version of the msrp recording draft.
>>> This one is substantially fleshed out. It certainly needs more =
tweaking,
>>> but is complete enough that you should be able to make meaningful
>>> comments on the approach.
>>>=20
>>>     Thanks,
>>>     Paul
>>>=20
>>>=20
>>> -------- Original Message --------
>>> Subject: New Version Notification for
>>> draft-yan-siprec-msrp-recording-01.txt
>>> Date: Wed, 28 May 2014 15:03:24 -0700
>>> From: internet-drafts@ietf.org
>>> To: Michael Yan <michael.yan@huawei.com>,        "Paul H. Kyzivat"
>>> <pkyzivat@alum.mit.edu>,        "Michael Yan" =
<michael.yan@huawei.com>,
>>>        "Paul Kyzivat" <pkyzivat@alum.mit.edu>
>>>=20
>>>=20
>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>> has been successfully submitted by Paul H. Kyzivat and posted to the
>>> IETF repository.
>>>=20
>>> Name:        draft-yan-siprec-msrp-recording
>>> Revision:    01
>>> Title:        Overview for MSRP Recording based on SIPREC
>>> Document date:    2014-05-28
>>> Group:        Individual Submission
>>> Pages:        9
>>> URL:
>>> =
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt=

>>>=20
>>> Status: =
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>> Htmlized: =
http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>> Diff: =
http://www.ietf.org/rfcdiff?url2=3Ddraft-yan-siprec-msrp-recording-01
>>>=20
>>> Abstract:
>>>    SIPREC is capable of recording interactive text media that is
>>>    transmitted via RTP.  However that format is not commonly used =
for
>>>    message or chat scenarios.  There is also a need for recording =
text
>>>    media carried via MSRP.  One case of note is exchange of text =
between
>>>    hearing-impaired users and emergence service bureaus.  Also,
>>>    recording support is needed for MSRP used in chat conferences and
>>>    multimedia conferences.
>>>=20
>>>    This document describes how to achieve MSRP channel recording =
within
>>>    the mechanism of SIP Recording (SIPREC).
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>=20
>>> The IETF Secretariat
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> siprec mailing list
>>> siprec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>=20
>>=20
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>>=20
>=20
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec


From nobody Wed Jul  2 02:32:07 2014
Return-Path: <andrew.hutton@unify.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAF81B27E0 for <siprec@ietfa.amsl.com>; Wed,  2 Jul 2014 02:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY4Eux3BZGHM for <siprec@ietfa.amsl.com>; Wed,  2 Jul 2014 02:32:03 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6A01B27E5 for <siprec@ietf.org>; Wed,  2 Jul 2014 02:32:03 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 91D411EB8568 for <siprec@ietf.org>; Wed,  2 Jul 2014 11:32:02 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 2 Jul 2014 11:32:02 +0200
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: SIPREC Meeting and Agenda for IETF90.
Thread-Index: Ac+V2HouJ5MdcRGuSAucGlMXUhaygg==
Date: Wed, 2 Jul 2014 09:32:01 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E1347E@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17E1347EMCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/0XZpDAmnfVlGVpWS7kZelQrSkag
Subject: [siprec] SIPREC Meeting and Agenda for IETF90.
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jul 2014 09:32:05 -0000

--_000_9F33F40F6F2CD847824537F3C4E37DDF17E1347EMCHP04MSXglobal_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

We need to submit a draft agenda by the 7th of July so please if you want t=
o present during the SIPREC Session then please let me know.

We are currently scheduled for the Friday 11:50 slot (https://datatracker.i=
etf.org/meeting/90/agenda.html) but there have been some changes to the age=
nda over the last couple of days including SIPREC being moved so there coul=
d still be late changes.

I will send a message to the list if the SIPREC session is moved again.

Regards
Andy


--_000_9F33F40F6F2CD847824537F3C4E37DDF17E1347EMCHP04MSXglobal_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi All,</div>
<div>&nbsp;</div>
<div>We need to submit a draft agenda by the 7<font size=3D"1"><span style=
=3D"font-size:7.3pt;"><sup>th</sup></span></font> of July so please if you =
want to present during the SIPREC Session then please let me know.</div>
<div>&nbsp;</div>
<div>We are currently scheduled for the Friday 11:50 slot (<a href=3D"https=
://datatracker.ietf.org/meeting/90/agenda.html"><font color=3D"blue"><u>htt=
ps://datatracker.ietf.org/meeting/90/agenda.html</u></font></a>) but there =
have been some changes to the agenda
over the last couple of days including SIPREC being moved so there could st=
ill be late changes.</div>
<div>&nbsp;</div>
<div>I will send a message to the list if the SIPREC session is moved again=
.</div>
<div>&nbsp;</div>
<div>Regards</div>
<div>Andy </div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_9F33F40F6F2CD847824537F3C4E37DDF17E1347EMCHP04MSXglobal_--


From nobody Wed Jul  2 07:10:04 2014
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508501A0065 for <siprec@ietfa.amsl.com>; Wed,  2 Jul 2014 07:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RI344J-U8IU for <siprec@ietfa.amsl.com>; Wed,  2 Jul 2014 07:09:59 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 524E11A004B for <siprec@ietf.org>; Wed,  2 Jul 2014 07:09:59 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id MRFe1o0021swQuc51S9ylz; Wed, 02 Jul 2014 14:09:58 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id MS9y1o00X3ZTu2S3bS9yzV; Wed, 02 Jul 2014 14:09:58 +0000
Message-ID: <53B412B6.6050404@alum.mit.edu>
Date: Wed, 02 Jul 2014 10:09:58 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: siprec@ietf.org
References: <9F33F40F6F2CD847824537F3C4E37DDF17E1347E@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E1347E@MCHP04MSX.global-ad.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404310198; bh=AKaPWCQpuFf1KyKJJ5iWkG6m4Ds1wgNvntr5O13+KSQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fxXAwqTEyxWfibAbZE2pYarSWAvtaPls+hsaz7KOn0jEvVox3nLNs3PP608JqGRp/ zUnvj4P3our9uQG2zMerNkfNf+nhU2aGqKMQzxrmy8PZ+umetZmaYY3L4rn481w2QJ f14ex5uhiB58Q1WQ+3M04emHr/83MeLRWiKwesNHRVYwWjDIrDqmSTtlYgalf3U3mB IPk031CXIS5kZm/6KgoJumNIr7lpVSPMOqlj/xK+ghBFeME3538iyJK4Q8XuSp+Rif mOBlqzIAQi4CInBlMvJttyKqVJ5tfGFvX6zroHQHRHu2k2BdHXFBQ9e/90tcp6cq39 3X1tUi4a227eQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/UBRjxQwTY_YEh4uzJKgjbRZPOrI
Subject: Re: [siprec] SIPREC Meeting and Agenda for IETF90.
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jul 2014 14:10:00 -0000

I want to present re msrp recording

On 7/2/14 5:32 AM, Hutton, Andrew wrote:
> Hi All,
> We need to submit a draft agenda by the 7^th of July so please if you
> want to present during the SIPREC Session then please let me know.
> We are currently scheduled for the Friday 11:50 slot
> (_https://datatracker.ietf.org/meeting/90/agenda.html_) but there have
> been some changes to the agenda over the last couple of days including
> SIPREC being moved so there could still be late changes.
> I will send a message to the list if the SIPREC session is moved again.
> Regards
> Andy
>
>
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>


From nobody Wed Jul  2 14:45:12 2014
Return-Path: <simon.farrow@stancilcorp.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62E11A07A1 for <siprec@ietfa.amsl.com>; Wed,  2 Jul 2014 14:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NezhMSm1Y1Hy for <siprec@ietfa.amsl.com>; Wed,  2 Jul 2014 14:45:07 -0700 (PDT)
Received: from jax4mhob03.myregisteredsite.com (jax4mhob03.myregisteredsite.com [64.69.218.83]) by ietfa.amsl.com (Postfix) with ESMTP id 888F31A0A84 for <siprec@ietf.org>; Wed,  2 Jul 2014 14:45:07 -0700 (PDT)
Received: from mymail.myregisteredsite.com (jax4wmnode1b.mymail.myregisteredsite.com [209.237.134.203]) by jax4mhob03.myregisteredsite.com (8.14.4/8.14.4) with SMTP id s62Lj5Pa010497 for <siprec@ietf.org>; Wed, 2 Jul 2014 17:45:05 -0400
Received: (qmail 18148 invoked by uid 80); 2 Jul 2014 21:45:04 -0000
Received: from unknown (HELO simonlaptop) (simon.farrow@stancilcorp.com@12.52.78.250) by mymail.myregisteredsite.com with ESMTPA; 2 Jul 2014 21:45:04 -0000
From: "Simon Farrow" <simon.farrow@stancilcorp.com>
To: "'Paul Kyzivat'" <pkyzivat@alum.mit.edu>, <siprec@ietf.org>
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu>
In-Reply-To: <53AC4B1A.9050707@alum.mit.edu>
Date: Wed, 2 Jul 2014 14:45:08 -0700
Message-ID: <000601cf963e$e742b0c0$b5c81240$@stancilcorp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFxmRh7NdZhKaHPVkysknF/14IEZgInePvAAokRvHsB99YP15wUAT0w
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/Hqi-TmA7lgki90ciiPlr0-HGtlA
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jul 2014 21:45:11 -0000

Paul

Sorry for the delay in getting to the document.

Is encryption out scope for this document (as it is mentioned in the Siprec
Protocol document). If so I think that should be stated but we might need to
take into consideration RFC 5547 (File Transfer) mentions secured MIME
(S/MIME) RFC 3851 while the protocol document only mentions RFC 3711, 5124
and 4568.

Once again thanks to you and Michael on preparing this document.

Simon Farrow
Director of Engineering

Stancil Corporation
2644 South Croddy Way
Santa Ana
CA 92704

Tel: 1-714-546-2002 ext 4311
http://www.stancilcorp.com
simon.farrow@stancilcorp.com

-----Original Message-----
From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Thursday, June 26, 2014 9:32 AM
To: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for
draft-yan-siprec-msrp-recording-01.txt

Trying one more time. Please!!!

On 6/3/14 2:46 PM, Paul Kyzivat wrote:
> Can I get some people in the wg to review and comment on this version?
>
>      Thanks,
>      Paul
>
> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>> I've submitted a revised version of the msrp recording draft.
>> This one is substantially fleshed out. It certainly needs more 
>> tweaking, but is complete enough that you should be able to make 
>> meaningful comments on the approach.
>>
>>      Thanks,
>>      Paul
>>
>>
>> -------- Original Message --------
>> Subject: New Version Notification for 
>> draft-yan-siprec-msrp-recording-01.txt
>> Date: Wed, 28 May 2014 15:03:24 -0700
>> From: internet-drafts@ietf.org
>> To: Michael Yan <michael.yan@huawei.com>,        "Paul H. Kyzivat"
>> <pkyzivat@alum.mit.edu>,        "Michael Yan" <michael.yan@huawei.com>,
>>         "Paul Kyzivat" <pkyzivat@alum.mit.edu>
>>
>>
>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>> has been successfully submitted by Paul H. Kyzivat and posted to the 
>> IETF repository.
>>
>> Name:        draft-yan-siprec-msrp-recording
>> Revision:    01
>> Title:        Overview for MSRP Recording based on SIPREC
>> Document date:    2014-05-28
>> Group:        Individual Submission
>> Pages:        9
>> URL:
>> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-0
>> 1.txt
>>
>> Status: 
>> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>> Htmlized: 
>> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>> Diff: 
>> http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-01
>>
>> Abstract:
>>     SIPREC is capable of recording interactive text media that is
>>     transmitted via RTP.  However that format is not commonly used for
>>     message or chat scenarios.  There is also a need for recording text
>>     media carried via MSRP.  One case of note is exchange of text between
>>     hearing-impaired users and emergence service bureaus.  Also,
>>     recording support is needed for MSRP used in chat conferences and
>>     multimedia conferences.
>>
>>     This document describes how to achieve MSRP channel recording within
>>     the mechanism of SIP Recording (SIPREC).
>>
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>>
>
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>

_______________________________________________
siprec mailing list
siprec@ietf.org
https://www.ietf.org/mailman/listinfo/siprec


From nobody Thu Jul  3 09:08:43 2014
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B84B1A0356 for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 09:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf41qnapuNTI for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 09:08:41 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 081561A0330 for <siprec@ietf.org>; Thu,  3 Jul 2014 09:08:40 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id MrjW1o0041c6gX857s8gYe; Thu, 03 Jul 2014 16:08:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id Ms8g1o00G3ZTu2S3js8gLY; Thu, 03 Jul 2014 16:08:40 +0000
Message-ID: <53B58008.9070507@alum.mit.edu>
Date: Thu, 03 Jul 2014 12:08:40 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Simon Farrow <simon.farrow@stancilcorp.com>, siprec@ietf.org
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <000601cf963e$e742b0c0$b5c81240$@stancilcorp.com>
In-Reply-To: <000601cf963e$e742b0c0$b5c81240$@stancilcorp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404403720; bh=y6V3ZdovvRyvwTIr0XdG0fzy0bJ7O8FAsnjNgGcoBzc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q6DNc55cDftUtXulJodmOkEjwGfgRwfCMvwwkpzjAdTJxevz9BSSqch5BQmLnFADt dUeCtxvKqNtZ/4mzyDcDGn9CLJMugAZOyXL16BVswHQbMA8w3jMfYgdkZLqhS4dckR VnnHC5EoXnzsswtKaa1TWtau1R/7xuzGhPbJjg5MPDAthofpHgUfRkP3uWb2UI27O0 xesBEGpbWX4bBwi7bD0PbIwI85bknGRAmv5NlYwJDN3aBquLfpdvIdONWYR6colEeQ 9o6AadVYX3HWi5/ETE3uU/D6tQh2PeG5Leqb2Q/Tu5kk34BadqP+p+4O2g56GvcTJk f4QL/yl+Vp0Ig==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/ZU4V55O86sDIMK9yN-Q7_fU9GH4
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jul 2014 16:08:42 -0000

On 7/2/14 5:45 PM, Simon Farrow wrote:
> Paul
>
> Sorry for the delay in getting to the document.
>
> Is encryption out scope for this document (as it is mentioned in the Siprec
> Protocol document).

It isn't out of scope. See the Security Considerations of the protocol 
document.

> If so I think that should be stated but we might need to
> take into consideration RFC 5547 (File Transfer) mentions secured MIME
> (S/MIME) RFC 3851 while the protocol document only mentions RFC 3711, 5124
> and 4568.

File transfer may be a special case, but maybe not.

If the file content is secured with S/MIME, then it is my expectation 
that this protection would be retained in the recording. That may well 
mean that the SRS can't understand the content of the recorded file.

Do you think that we need additional language about this case?

	Thanks,
	Paul

> Once again thanks to you and Michael on preparing this document.
>
> Simon Farrow
> Director of Engineering
>
> Stancil Corporation
> 2644 South Croddy Way
> Santa Ana
> CA 92704
>
> Tel: 1-714-546-2002 ext 4311
> http://www.stancilcorp.com
> simon.farrow@stancilcorp.com
>
> -----Original Message-----
> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Thursday, June 26, 2014 9:32 AM
> To: siprec@ietf.org
> Subject: Re: [siprec] New Version Notification for
> draft-yan-siprec-msrp-recording-01.txt
>
> Trying one more time. Please!!!
>
> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>> Can I get some people in the wg to review and comment on this version?
>>
>>       Thanks,
>>       Paul
>>
>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>> I've submitted a revised version of the msrp recording draft.
>>> This one is substantially fleshed out. It certainly needs more
>>> tweaking, but is complete enough that you should be able to make
>>> meaningful comments on the approach.
>>>
>>>       Thanks,
>>>       Paul
>>>
>>>
>>> -------- Original Message --------
>>> Subject: New Version Notification for
>>> draft-yan-siprec-msrp-recording-01.txt
>>> Date: Wed, 28 May 2014 15:03:24 -0700
>>> From: internet-drafts@ietf.org
>>> To: Michael Yan <michael.yan@huawei.com>,        "Paul H. Kyzivat"
>>> <pkyzivat@alum.mit.edu>,        "Michael Yan" <michael.yan@huawei.com>,
>>>          "Paul Kyzivat" <pkyzivat@alum.mit.edu>
>>>
>>>
>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>> has been successfully submitted by Paul H. Kyzivat and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-yan-siprec-msrp-recording
>>> Revision:    01
>>> Title:        Overview for MSRP Recording based on SIPREC
>>> Document date:    2014-05-28
>>> Group:        Individual Submission
>>> Pages:        9
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-0
>>> 1.txt
>>>
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-01
>>>
>>> Abstract:
>>>      SIPREC is capable of recording interactive text media that is
>>>      transmitted via RTP.  However that format is not commonly used for
>>>      message or chat scenarios.  There is also a need for recording text
>>>      media carried via MSRP.  One case of note is exchange of text between
>>>      hearing-impaired users and emergence service bureaus.  Also,
>>>      recording support is needed for MSRP used in chat conferences and
>>>      multimedia conferences.
>>>
>>>      This document describes how to achieve MSRP channel recording within
>>>      the mechanism of SIP Recording (SIPREC).
>>>
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> siprec mailing list
>>> siprec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>>
>
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>
>


From nobody Thu Jul  3 09:55:46 2014
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995711B2987 for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 09:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EDsQYvxISc8 for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 09:55:41 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BD8511B2952 for <siprec@ietf.org>; Thu,  3 Jul 2014 09:55:40 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id MsNc1o0010EZKEL53svgm9; Thu, 03 Jul 2014 16:55:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id Msvf1o00g3ZTu2S3Msvgxb; Thu, 03 Jul 2014 16:55:40 +0000
Message-ID: <53B58B0B.1060004@alum.mit.edu>
Date: Thu, 03 Jul 2014 12:55:39 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian Rosen <br@brianrosen.net>
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <ECFDDD30-85A7-471C-95FF-767F82C80946@brianrosen.net>
In-Reply-To: <ECFDDD30-85A7-471C-95FF-767F82C80946@brianrosen.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404406540; bh=0K/Pt69NEATGUBsQJBDuPyl4i2LcKeZU0ekOVoFINwc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uz+bNGjEBShjmHOPlj2kCPy6rKAxCFgO+uLwywoy7wzkS6CsSaovartC/4xPLa740 TfYAqDKi/VM/yEFZC3OsGo9i9iHUAN/PZ6lHLqJ2KdaKgVxzLV/MTKP1WcSHOBBS5O XPPQSQDm7NyLWzFlR0aR/mmxnH/B81iSkxB6P7gpILVQhsEKDlOygiplmMgt5ORjAC ZuTawUU8STi2FUkkPZ96bJIcacPPgl6YTPweWpSNIvfTSeccecEjW9543fCdt77GT1 Ypu2AC4YbHSAXNv9hjtlO8nmcmu/zesUwEbOcvXhZkyEZHvS7JnoVPy6nQnEoc5SB+ wbaVjaPZDq13w==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/AAFavxbnxqK_qpIQjBsgjVtHifI
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jul 2014 16:55:42 -0000

On 7/1/14 5:34 PM, Brian Rosen wrote:
> I’ve reviewed this document.  I think it is a very good start, and think we can get it ready to ship quite quickly.
>
> I have the following comments:
>
> We need to specify a way to send and save REPORTS that are sent/received on the CS to the SRS.  If, for example, a message sent by a party to another is not received completely,
> and a REPORT js generated on the RS,  we need to somehow record than in the CS.

I guess CS and RS need to be swapped in the above line, right?

> You have a note about reports, but it isn’t clear if you mean reports in the CS or the RS.  Both have to be recorded, but at least in the RS, the SRS has all the info needed.

I just have a placeholder, because I haven't thought much about it yet.

I especially hadn't thought about reports on the RS. Note that the SRS 
won't be sending anything except reports to the SRC, so there is no 
reason for the SRC to be sending reports to the SRS about the RS msrp 
session.

Conversely, suppose the SRC gets a report from the SRS that something 
hasn't made it successfully. What should it do? (I can't think of 
anything useful for it do do.) I guess this is analogous to the SRC 
getting RTCP reports indicating packet loss of RTP media. We don't talk 
about that.

But reports on the CS are significant information that could be 
important to record. I think they can't be sent as MSRP reports. I 
suspect we must find a way to encapsulate them as regular MSRP messages. 
But that seems messy. Ideas are welcome.

> I think there is a problem with the text about adding a CPIM wrapper if there isn’t one.  I think the recording has to know if the original message was sent by some entity other than the one in the CPIM From (that is, we have to preserve the MSRP From).  The SRS has to know whether the original message had a CPIM header, and its contents.   If the SRC changes the message (by adding the wrapper) I think the SRS has to be able to figure that out, and record that fact in some way.

I hear you, though I'm not yet convinced how important it is for the SRS 
to be able to make this distinction.

I think the only way to be *certain* that the SRS can distinguish these 
is to wrap *every* message, even those that already contain CPIM 
headers. Then the SRS would know that the outer wrapper was always from 
the SRC, and that if there was another cpim wrapper inside then it was 
from the CS. But that seems like overkill.

If we only put CPIM wrappers on messages that don't already have them, 
then we could put something *special* in them. But there would be no 
guarantee that the CS didn't use that.

We could also introduce a new mime type similar to CPIM, but specially 
for recording. If we constrained the usage of that then we might be able 
to claim that it could never appear on the CS. But I would prefer to 
avoid this.

> When we echo a message from the RS to the CS, we’re going to lose the MESSAGE-ID from the RS.  That’s a problem.  We have to save that info in the recording.  A hack would be to use the same message ID in both the CS and the RS, possibly with some prefix.
>
> I worry a bit about chunking in the RS differently from chunking in the CS. I may be mistaken, but if the chunking is different, will that affect the byte-range response in a failure report?

Don't the above issues have analogs for RTP/RTCP?
Do we have any more requirement to solve them here than we did there?

> The URIs in the original to/from need to be captured, but they will be different in the RS.  Need to fix that.

I assume you are talking about the to/from in CPIM, right? Why do they 
need to be different in the RS?

> Do we need to say something about max-size issues between CS and RS?

Probably. Seems like a policy issue in the SRS. If the SRS doesn't want 
to record large messages. Maybe we want to specify that the SRC MUST 
honor the SRS's max-size, bypassing recording of messages that are too 
big. (Or perhaps inserting special small messages as placeholders for 
the bypassed messages.)

> You can’t possibly not change -metadata.  As an example. you have to allow an msrp AoR for a participant

Hmm. I guess so. I was thinking that we were lenient in the AoR type, 
but I guess not.

Since the metadata isn't done yet, maybe we can change it before it is 
done, to allow this. (Allow any URI.)

> Yes, I think we have to extend Participant to handle nicks.

A participant can already have multiple AoR/Name pairs. So we could add 
the nickname as one of those.

(We really did try to plan ahead with the metadata.)

> Probably also to handle the SIP session URI vs the MSRP URIs

Note that the metadata associates participants with both the CS and 
individual media streams. So the SIP session URIs are already covered there.

	Thanks,
	Paul

> Brian
>
> On Jun 26, 2014, at 12:32 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
>> Trying one more time. Please!!!
>>
>> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>>> Can I get some people in the wg to review and comment on this version?
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>>> I've submitted a revised version of the msrp recording draft.
>>>> This one is substantially fleshed out. It certainly needs more tweaking,
>>>> but is complete enough that you should be able to make meaningful
>>>> comments on the approach.
>>>>
>>>>      Thanks,
>>>>      Paul
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: New Version Notification for
>>>> draft-yan-siprec-msrp-recording-01.txt
>>>> Date: Wed, 28 May 2014 15:03:24 -0700
>>>> From: internet-drafts@ietf.org
>>>> To: Michael Yan <michael.yan@huawei.com>,        "Paul H. Kyzivat"
>>>> <pkyzivat@alum.mit.edu>,        "Michael Yan" <michael.yan@huawei.com>,
>>>>         "Paul Kyzivat" <pkyzivat@alum.mit.edu>
>>>>
>>>>
>>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>>> has been successfully submitted by Paul H. Kyzivat and posted to the
>>>> IETF repository.
>>>>
>>>> Name:        draft-yan-siprec-msrp-recording
>>>> Revision:    01
>>>> Title:        Overview for MSRP Recording based on SIPREC
>>>> Document date:    2014-05-28
>>>> Group:        Individual Submission
>>>> Pages:        9
>>>> URL:
>>>> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt
>>>>
>>>> Status: https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>>> Htmlized: http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-01
>>>>
>>>> Abstract:
>>>>     SIPREC is capable of recording interactive text media that is
>>>>     transmitted via RTP.  However that format is not commonly used for
>>>>     message or chat scenarios.  There is also a need for recording text
>>>>     media carried via MSRP.  One case of note is exchange of text between
>>>>     hearing-impaired users and emergence service bureaus.  Also,
>>>>     recording support is needed for MSRP used in chat conferences and
>>>>     multimedia conferences.
>>>>
>>>>     This document describes how to achieve MSRP channel recording within
>>>>     the mechanism of SIP Recording (SIPREC).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>
>>>
>>> _______________________________________________
>>> siprec mailing list
>>> siprec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>
>


From nobody Thu Jul  3 12:25:35 2014
Return-Path: <br@brianrosen.net>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DEA1B2A05 for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 12:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaP2cjZiYUGC for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 12:25:30 -0700 (PDT)
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838741B2861 for <siprec@ietf.org>; Thu,  3 Jul 2014 12:25:30 -0700 (PDT)
Received: by mail-qg0-f54.google.com with SMTP id q107so640208qgd.27 for <siprec@ietf.org>; Thu, 03 Jul 2014 12:25:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RmQ9CQ39yjuSkt1FFPL7SOBNh8ZE+5saSb7TXypx09c=; b=NSweaZMGYIPGmmr7iKTIHSqMDWl+Uo0PhiHk+oY0Ns4WLnNF85Z/mcCx0ZkKmDHLig CKrgby9FadypOOOBHMSrw0R1+uH4W7xT7S/Ec6jB9uRv5lM3AJ5CtjpSsqPGbrx5rtQJ UCQwmtJKJHNWFUa0wVXr8/UZawWWnzv/IKU8zT6jyVQ2PmLUrfiBbHN01yIgj/WsypEn CyZgZhAmtGcD7RSCM8RGrsEClBH/T2IyVVtGsRCMATSVIXoC9qFgF/5aOw1CfjLuC8lv 1zBjDFSmHed2CZk3Gginywvoyky9+5jNFazdDdim3H8cy9iZ5xxW60XbVW65PMlOSuPZ e1uQ==
X-Gm-Message-State: ALoCoQnuJEtbz2AJ15G983TZ2ZGispsrCs1GsOGxhV7HkdLHL+aU05QpCicbz76AxGvH3Qef2a4w
X-Received: by 10.140.49.76 with SMTP id p70mr10136102qga.86.1404415529680; Thu, 03 Jul 2014 12:25:29 -0700 (PDT)
Received: from [10.33.193.19] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id m1sm51079389qaz.27.2014.07.03.12.25.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 12:25:28 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_615C2824-3A04-4ECB-B9F2-C647468C18A2"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <53B58B0B.1060004@alum.mit.edu>
Date: Thu, 3 Jul 2014 15:25:28 -0400
Message-Id: <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net>
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <ECFDDD30-85A7-471C-95FF-767F82C80946@brianrosen.net> <53B58B0B.1060004@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/l08dPuk6KdbM6sXGGRZb8fSlO84
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jul 2014 19:25:33 -0000

--Apple-Mail=_615C2824-3A04-4ECB-B9F2-C647468C18A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Jul 3, 2014, at 12:55 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 7/1/14 5:34 PM, Brian Rosen wrote:
>> I=92ve reviewed this document.  I think it is a very good start, and =
think we can get it ready to ship quite quickly.
>>=20
>> I have the following comments:
>>=20
>> We need to specify a way to send and save REPORTS that are =
sent/received on the CS to the SRS.  If, for example, a message sent by =
a party to another is not received completely,
>> and a REPORT js generated on the RS,  we need to somehow record than =
in the CS.
>=20
> I guess CS and RS need to be swapped in the above line, right?
Yeah doh!
>=20
>> You have a note about reports, but it isn=92t clear if you mean =
reports in the CS or the RS.  Both have to be recorded, but at least in =
the RS, the SRS has all the info needed.
>=20
> I just have a placeholder, because I haven't thought much about it =
yet.
>=20
> I especially hadn't thought about reports on the RS. Note that the SRS =
won't be sending anything except reports to the SRC, so there is no =
reason for the SRC to be sending reports to the SRS about the RS msrp =
session.
Yeah, but it has to send reports it got on the CS somehow

>=20
> Conversely, suppose the SRC gets a report from the SRS that something =
hasn't made it successfully. What should it do? (I can't think of =
anything useful for it do do.) I guess this is analogous to the SRC =
getting RTCP reports indicating packet loss of RTP media. We don't talk =
about that.
No, I think if the SRC gets a report of a problem on the CS it must =
record that. =20

I think if we neglected to record known problems detected in RTCP =
reports then we need to fix that too at some point =97 if the SRC knows =
about a problem, that has to be recorded.

>=20
> But reports on the CS are significant information that could be =
important to record. I think they can't be sent as MSRP reports. I =
suspect we must find a way to encapsulate them as regular MSRP messages. =
But that seems messy. Ideas are welcome.
Yeah, I think that=92s right, and I think it=92s messy.  Sending them in =
metadata is a possibility.  Extending reports in some manner is a =
possibility.

>=20
>> I think there is a problem with the text about adding a CPIM wrapper =
if there isn=92t one.  I think the recording has to know if the original =
message was sent by some entity other than the one in the CPIM =46rom =
(that is, we have to preserve the MSRP From).  The SRS has to know =
whether the original message had a CPIM header, and its contents.   If =
the SRC changes the message (by adding the wrapper) I think the SRS has =
to be able to figure that out, and record that fact in some way.
>=20
> I hear you, though I'm not yet convinced how important it is for the =
SRS to be able to make this distinction.
I think the recording is what the SRC got.  If you can=92t effectively =
reproduce what the SRC gets, the mechanism is not adequate.

>=20
> I think the only way to be *certain* that the SRS can distinguish =
these is to wrap *every* message, even those that already contain CPIM =
headers. Then the SRS would know that the outer wrapper was always from =
the SRC, and that if there was another cpim wrapper inside then it was =
from the CS. But that seems like overkill.
Yeah, I=92d prefer not to do that

>=20
> If we only put CPIM wrappers on messages that don't already have them, =
then we could put something *special* in them. But there would be no =
guarantee that the CS didn't use that.
There is always a way.  We can extend CPIM if we need to.

>=20
> We could also introduce a new mime type similar to CPIM, but specially =
for recording. If we constrained the usage of that then we might be able =
to claim that it could never appear on the CS. But I would prefer to =
avoid this.
I=92d rather just extend CPIM

>=20
>> When we echo a message from the RS to the CS, we=92re going to lose =
the MESSAGE-ID from the RS.  That=92s a problem.  We have to save that =
info in the recording.  A hack would be to use the same message ID in =
both the CS and the RS, possibly with some prefix.
>>=20
>> I worry a bit about chunking in the RS differently from chunking in =
the CS. I may be mistaken, but if the chunking is different, will that =
affect the byte-range response in a failure report?
>=20
> Don't the above issues have analogs for RTP/RTCP?
No, i don=92t think so.  Message ID is much more of a real id then =
anything you find in an RTP header.  You can derive wall time, which =
might be similar, but not really.

> Do we have any more requirement to solve them here than we did there?
>=20
>> The URIs in the original to/from need to be captured, but they will =
be different in the RS.  Need to fix that.
>=20
> I assume you are talking about the to/from in CPIM, right? Why do they =
need to be different in the RS?
MSRP To/=46rom in the RS is SRS/SRC.  If there wasn=92t any CPIM, we =
could add it, in which case MSRP To/=46rom in CS becomes CPIM To/=46rom =
in RS.  If there is CPIM already, we need to preserve it, and then we =
need to solve sending CS MSRP To/=46rom in the RS.

>=20
>> Do we need to say something about max-size issues between CS and RS?
>=20
> Probably. Seems like a policy issue in the SRS. If the SRS doesn't =
want to record large messages. Maybe we want to specify that the SRC =
MUST honor the SRS's max-size, bypassing recording of messages that are =
too big. (Or perhaps inserting special small messages as placeholders =
for the bypassed messages.)
Yeah, something.  Basically, to avoid problems, CS max has to be at =
least as big as RS max.  I think that=92s just a MUST as a by-the-way.

>=20
>> You can=92t possibly not change -metadata.  As an example. you have =
to allow an msrp AoR for a participant
>=20
> Hmm. I guess so. I was thinking that we were lenient in the AoR type, =
but I guess not.
>=20
> Since the metadata isn't done yet, maybe we can change it before it is =
done, to allow this. (Allow any URI.)
Depends on how we solve some of these other issues.
That one leaped out at me, have to look harder to see if there are =
others.   Interaction of the term =93Participant=94 for example.

>=20
>> Yes, I think we have to extend Participant to handle nicks.
>=20
> A participant can already have multiple AoR/Name pairs. So we could =
add the nickname as one of those.
Would have to be labeled in some way

>=20
> (We really did try to plan ahead with the metadata.)
>=20
>> Probably also to handle the SIP session URI vs the MSRP URIs
>=20
> Note that the metadata associates participants with both the CS and =
individual media streams. So the SIP session URIs are already covered =
there.
I=92m missing something, but it=92s probably lack of clue on how =
metadata works. =20
And, I spotted another metadata change problem:

6.5.1.  Attributes

   Participant has a single defined attribute:

   o  AoR / Name pair list - This attribute is a list of Name/AoR
      tuples.  An AoR MAY be a SIP/SIPS/TEL URI.  Name represents
      Participant name(SIP display name) or dialed number (DN) (when
      known).  Multiple tuples are allowed for cases where a participant
      has more than one AoR.  (For example a P-Asserted-identity header
      [RFC3325] can have both SIP and TEL URIs.)

Have to add msrp/msrps to the list.  Does the MSRP To/=46rom HAVE to be =
an msrp/msrps scheme, or can it be a sip AoR?  If the latter, we could =
have a corner case where the SIP AoR and the MSRP AoR were both SIP but =
different.

>=20
> 	Thanks,
> 	Paul
>=20
>> Brian
>>=20
>> On Jun 26, 2014, at 12:32 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> =
wrote:
>>=20
>>> Trying one more time. Please!!!
>>>=20
>>> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>>>> Can I get some people in the wg to review and comment on this =
version?
>>>>=20
>>>>     Thanks,
>>>>     Paul
>>>>=20
>>>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>>>> I've submitted a revised version of the msrp recording draft.
>>>>> This one is substantially fleshed out. It certainly needs more =
tweaking,
>>>>> but is complete enough that you should be able to make meaningful
>>>>> comments on the approach.
>>>>>=20
>>>>>     Thanks,
>>>>>     Paul
>>>>>=20
>>>>>=20
>>>>> -------- Original Message --------
>>>>> Subject: New Version Notification for
>>>>> draft-yan-siprec-msrp-recording-01.txt
>>>>> Date: Wed, 28 May 2014 15:03:24 -0700
>>>>> From: internet-drafts@ietf.org
>>>>> To: Michael Yan <michael.yan@huawei.com>,        "Paul H. Kyzivat"
>>>>> <pkyzivat@alum.mit.edu>,        "Michael Yan" =
<michael.yan@huawei.com>,
>>>>>        "Paul Kyzivat" <pkyzivat@alum.mit.edu>
>>>>>=20
>>>>>=20
>>>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>>>> has been successfully submitted by Paul H. Kyzivat and posted to =
the
>>>>> IETF repository.
>>>>>=20
>>>>> Name:        draft-yan-siprec-msrp-recording
>>>>> Revision:    01
>>>>> Title:        Overview for MSRP Recording based on SIPREC
>>>>> Document date:    2014-05-28
>>>>> Group:        Individual Submission
>>>>> Pages:        9
>>>>> URL:
>>>>> =
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt=

>>>>>=20
>>>>> Status: =
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>>>> Htmlized: =
http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>>>> Diff: =
http://www.ietf.org/rfcdiff?url2=3Ddraft-yan-siprec-msrp-recording-01
>>>>>=20
>>>>> Abstract:
>>>>>    SIPREC is capable of recording interactive text media that is
>>>>>    transmitted via RTP.  However that format is not commonly used =
for
>>>>>    message or chat scenarios.  There is also a need for recording =
text
>>>>>    media carried via MSRP.  One case of note is exchange of text =
between
>>>>>    hearing-impaired users and emergence service bureaus.  Also,
>>>>>    recording support is needed for MSRP used in chat conferences =
and
>>>>>    multimedia conferences.
>>>>>=20
>>>>>    This document describes how to achieve MSRP channel recording =
within
>>>>>    the mechanism of SIP Recording (SIPREC).
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission
>>>>> until the htmlized version and diff are available at =
tools.ietf.org.
>>>>>=20
>>>>> The IETF Secretariat
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> siprec mailing list
>>>>> siprec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>=20
>>>=20
>>> _______________________________________________
>>> siprec mailing list
>>> siprec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/siprec
>>=20
>>=20
>=20


--Apple-Mail=_615C2824-3A04-4ECB-B9F2-C647468C18A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Jul 3, 2014, at 12:55 PM, Paul =
Kyzivat &lt;<a =
href=3D"mailto:pkyzivat@alum.mit.edu">pkyzivat@alum.mit.edu</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">On 7/1/14 5:34 PM, Brian Rosen wrote:<br><blockquote =
type=3D"cite">I=92ve reviewed this document. &nbsp;I think it is a very =
good start, and think we can get it ready to ship quite =
quickly.<br><br>I have the following comments:<br><br>We need to specify =
a way to send and save REPORTS that are sent/received on the CS to the =
SRS. &nbsp;If, for example, a message sent by a party to another is not =
received completely,<br>and a REPORT js generated on the RS, &nbsp;we =
need to somehow record than in the CS.<br></blockquote><br>I guess CS =
and RS need to be swapped in the above line, right?<br></blockquote>Yeah =
doh!<br><blockquote type=3D"cite"><br><blockquote type=3D"cite">You have =
a note about reports, but it isn=92t clear if you mean reports in the CS =
or the RS. &nbsp;Both have to be recorded, but at least in the RS, the =
SRS has all the info needed.<br></blockquote><br>I just have a =
placeholder, because I haven't thought much about it yet.<br><br>I =
especially hadn't thought about reports on the RS. Note that the SRS =
won't be sending anything except reports to the SRC, so there is no =
reason for the SRC to be sending reports to the SRS about the RS msrp =
session.<br></blockquote>Yeah, but it has to send reports it got on the =
CS somehow</div><div><br><blockquote type=3D"cite"><br>Conversely, =
suppose the SRC gets a report from the SRS that something hasn't made it =
successfully. What should it do? (I can't think of anything useful for =
it do do.) I guess this is analogous to the SRC getting RTCP reports =
indicating packet loss of RTP media. We don't talk about =
that.<br></blockquote>No, I think if the SRC gets a report of a problem =
on the CS it must record that. &nbsp;</div><div><br></div><div>I think =
if we neglected to record known problems detected in RTCP reports then =
we need to fix that too at some point =97 if the SRC knows about a =
problem, that has to be recorded.</div><div><br><blockquote =
type=3D"cite"><br>But reports on the CS are significant information that =
could be important to record. I think they can't be sent as MSRP =
reports. I suspect we must find a way to encapsulate them as regular =
MSRP messages. But that seems messy. Ideas are =
welcome.<br></blockquote>Yeah, I think that=92s right, and I think it=92s =
messy. &nbsp;Sending them in metadata is a possibility. &nbsp;Extending =
reports in some manner is a possibility.</div><div><br><blockquote =
type=3D"cite"><br><blockquote type=3D"cite">I think there is a problem =
with the text about adding a CPIM wrapper if there isn=92t one. &nbsp;I =
think the recording has to know if the original message was sent by some =
entity other than the one in the CPIM =46rom (that is, we have to =
preserve the MSRP From). &nbsp;The SRS has to know whether the original =
message had a CPIM header, and its contents. &nbsp;&nbsp;If the SRC =
changes the message (by adding the wrapper) I think the SRS has to be =
able to figure that out, and record that fact in some =
way.<br></blockquote><br>I hear you, though I'm not yet convinced how =
important it is for the SRS to be able to make this =
distinction.<br></blockquote>I think the recording is what the SRC got. =
&nbsp;If you can=92t effectively reproduce what the SRC gets, the =
mechanism is not adequate.</div><div><br><blockquote type=3D"cite"><br>I =
think the only way to be *certain* that the SRS can distinguish these is =
to wrap *every* message, even those that already contain CPIM headers. =
Then the SRS would know that the outer wrapper was always from the SRC, =
and that if there was another cpim wrapper inside then it was from the =
CS. But that seems like overkill.<br></blockquote>Yeah, I=92d prefer not =
to do that</div><div><br><blockquote type=3D"cite"><br>If we only put =
CPIM wrappers on messages that don't already have them, then we could =
put something *special* in them. But there would be no guarantee that =
the CS didn't use that.<br></blockquote>There is always a way. &nbsp;We =
can extend CPIM if we need to.</div><div><br><blockquote =
type=3D"cite"><br>We could also introduce a new mime type similar to =
CPIM, but specially for recording. If we constrained the usage of that =
then we might be able to claim that it could never appear on the CS. But =
I would prefer to avoid this.<br></blockquote>I=92d rather just extend =
CPIM</div><div><br><blockquote type=3D"cite"><br><blockquote =
type=3D"cite">When we echo a message from the RS to the CS, we=92re =
going to lose the MESSAGE-ID from the RS. &nbsp;That=92s a problem. =
&nbsp;We have to save that info in the recording. &nbsp;A hack would be =
to use the same message ID in both the CS and the RS, possibly with some =
prefix.<br><br>I worry a bit about chunking in the RS differently from =
chunking in the CS. I may be mistaken, but if the chunking is different, =
will that affect the byte-range response in a failure =
report?<br></blockquote><br>Don't the above issues have analogs for =
RTP/RTCP?<br></blockquote>No, i don=92t think so. &nbsp;Message ID is =
much more of a real id then anything you find in an RTP header. =
&nbsp;You can derive wall time, which might be similar, but not =
really.</div><div><br></div><div><blockquote type=3D"cite">Do we have =
any more requirement to solve them here than we did =
there?<br><br><blockquote type=3D"cite">The URIs in the original to/from =
need to be captured, but they will be different in the RS. &nbsp;Need to =
fix that.<br></blockquote><br>I assume you are talking about the to/from =
in CPIM, right? Why do they need to be different in the =
RS?<br></blockquote>MSRP To/=46rom in the RS is SRS/SRC. &nbsp;If there =
wasn=92t any CPIM, we could add it, in which case MSRP To/=46rom in CS =
becomes CPIM To/=46rom in RS. &nbsp;If there is CPIM already, we need to =
preserve it, and then we need to solve sending CS MSRP To/=46rom in the =
RS.</div><div><br></div><div><blockquote type=3D"cite"><br><blockquote =
type=3D"cite">Do we need to say something about max-size issues between =
CS and RS?<br></blockquote><br>Probably. Seems like a policy issue in =
the SRS. If the SRS doesn't want to record large messages. Maybe we want =
to specify that the SRC MUST honor the SRS's max-size, bypassing =
recording of messages that are too big. (Or perhaps inserting special =
small messages as placeholders for the bypassed =
messages.)<br></blockquote>Yeah, something. &nbsp;Basically, to avoid =
problems, CS max has to be at least as big as RS max. &nbsp;I think =
that=92s just a MUST as a by-the-way.</div><div><br><blockquote =
type=3D"cite"><br><blockquote type=3D"cite">You can=92t possibly not =
change -metadata. &nbsp;As an example. you have to allow an msrp AoR for =
a participant<br></blockquote><br>Hmm. I guess so. I was thinking that =
we were lenient in the AoR type, but I guess not.<br><br>Since the =
metadata isn't done yet, maybe we can change it before it is done, to =
allow this. (Allow any URI.)<br></blockquote>Depends on how we solve =
some of these other issues.</div><div>That one leaped out at me, have to =
look harder to see if there are others. &nbsp; Interaction of the term =
=93Participant=94 for example.</div><div><br><blockquote =
type=3D"cite"><br><blockquote type=3D"cite">Yes, I think we have to =
extend Participant to handle nicks.<br></blockquote><br>A participant =
can already have multiple AoR/Name pairs. So we could add the nickname =
as one of those.<br></blockquote>Would have to be labeled in some =
way</div><div><br><blockquote type=3D"cite"><br>(We really did try to =
plan ahead with the metadata.)<br><br><blockquote type=3D"cite">Probably =
also to handle the SIP session URI vs the MSRP =
URIs<br></blockquote><br>Note that the metadata associates participants =
with both the CS and individual media streams. So the SIP session URIs =
are already covered there.<br></blockquote>I=92m missing something, but =
it=92s probably lack of clue on how metadata works. =
&nbsp;</div><div>And, I spotted another metadata change =
problem:</div><div><pre class=3D"newpage" style=3D"font-size: 1em; =
margin-top: 0px; margin-bottom: 0px; page-break-before: always;"><span =
class=3D"h4" style=3D"line-height: 0pt; display: inline; font-size: 1em; =
font-weight: bold;"><h4 style=3D"line-height: 0pt; display: inline; =
font-size: 1em;"><a class=3D"selflink" name=3D"section-6.5.1" =
href=3D"http://tools.ietf.org/html/draft-ietf-siprec-metadata-15#section-6=
.5.1" style=3D"color: black; text-decoration: none;"><br =
class=3D"Apple-interchange-newline">6.5.1</a>.  Attributes</h4></span>

   Participant has a single defined attribute:

   o  AoR / Name pair list - This attribute is a list of Name/AoR
      tuples.  An AoR MAY be a SIP/SIPS/TEL URI.  Name represents
      Participant name(SIP display name) or dialed number (DN) (when
      known).  Multiple tuples are allowed for cases where a participant
      has more than one AoR.  (For example a P-Asserted-identity header
      [<a href=3D"http://tools.ietf.org/html/rfc3325" =
title=3D"&quot;Private Extensions to the Session Initiation Protocol =
(SIP) for Asserted Identity within Trusted Networks&quot;">RFC3325</a>] =
can have both SIP and TEL URIs.)
</pre><div><br></div><div>Have to add msrp/msrps to the list. &nbsp;Does =
the MSRP To/=46rom HAVE to be an msrp/msrps scheme, or can it be a sip =
AoR? &nbsp;If the latter, we could have a corner case where the SIP AoR =
and the MSRP AoR were both SIP but =
different.</div><div><br></div><blockquote type=3D"cite"><br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Thanks,<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Paul<br><br><blockquote =
type=3D"cite">Brian<br><br>On Jun 26, 2014, at 12:32 PM, Paul Kyzivat =
&lt;<a href=3D"mailto:pkyzivat@alum.mit.edu">pkyzivat@alum.mit.edu</a>&gt;=
 wrote:<br><br><blockquote type=3D"cite">Trying one more time. =
Please!!!<br><br>On 6/3/14 2:46 PM, Paul Kyzivat wrote:<br><blockquote =
type=3D"cite">Can I get some people in the wg to review and comment on =
this version?<br><br> &nbsp;&nbsp;&nbsp;&nbsp;Thanks,<br> =
&nbsp;&nbsp;&nbsp;&nbsp;Paul<br><br>On 5/28/14 6:10 PM, Paul Kyzivat =
wrote:<br><blockquote type=3D"cite">I've submitted a revised version of =
the msrp recording draft.<br>This one is substantially fleshed out. It =
certainly needs more tweaking,<br>but is complete enough that you should =
be able to make meaningful<br>comments on the approach.<br><br> =
&nbsp;&nbsp;&nbsp;&nbsp;Thanks,<br> =
&nbsp;&nbsp;&nbsp;&nbsp;Paul<br><br><br>-------- Original Message =
--------<br>Subject: New Version Notification =
for<br>draft-yan-siprec-msrp-recording-01.txt<br>Date: Wed, 28 May 2014 =
15:03:24 -0700<br>From: <a =
href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a><br>T=
o: Michael Yan &lt;<a =
href=3D"mailto:michael.yan@huawei.com">michael.yan@huawei.com</a>&gt;, =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Paul H. Kyzivat"<br>&lt;<a =
href=3D"mailto:pkyzivat@alum.mit.edu">pkyzivat@alum.mit.edu</a>&gt;, =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Michael Yan" &lt;<a =
href=3D"mailto:michael.yan@huawei.com">michael.yan@huawei.com</a>&gt;,<br>=
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Paul Kyzivat" &lt;<a =
href=3D"mailto:pkyzivat@alum.mit.edu">pkyzivat@alum.mit.edu</a>&gt;<br><br=
><br>A new version of I-D, draft-yan-siprec-msrp-recording-01.txt<br>has =
been successfully submitted by Paul H. Kyzivat and posted to the<br>IETF =
repository.<br><br>Name: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;draft-yan-siprec-msrp-recording<=
br>Revision: &nbsp;&nbsp;&nbsp;01<br>Title: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Overview for MSRP Recording =
based on SIPREC<br>Document date: &nbsp;&nbsp;&nbsp;2014-05-28<br>Group: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Individual =
Submission<br>Pages: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;9<br>URL:<br><a =
href=3D"http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recordin=
g-01.txt">http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-record=
ing-01.txt</a><br><br>Status: =
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/<br>Htmli=
zed: =
http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01<br>Diff: =
http://www.ietf.org/rfcdiff?url2=3Ddraft-yan-siprec-msrp-recording-01<br><=
br>Abstract:<br> &nbsp;&nbsp;&nbsp;SIPREC is capable of recording =
interactive text media that is<br> &nbsp;&nbsp;&nbsp;transmitted via =
RTP. &nbsp;However that format is not commonly used for<br> =
&nbsp;&nbsp;&nbsp;message or chat scenarios. &nbsp;There is also a need =
for recording text<br> &nbsp;&nbsp;&nbsp;media carried via MSRP. =
&nbsp;One case of note is exchange of text between<br> =
&nbsp;&nbsp;&nbsp;hearing-impaired users and emergence service bureaus. =
&nbsp;Also,<br> &nbsp;&nbsp;&nbsp;recording support is needed for MSRP =
used in chat conferences and<br> &nbsp;&nbsp;&nbsp;multimedia =
conferences.<br><br> &nbsp;&nbsp;&nbsp;This document describes how to =
achieve MSRP channel recording within<br> &nbsp;&nbsp;&nbsp;the =
mechanism of SIP Recording (SIPREC).<br><br><br><br><br><br><br>Please =
note that it may take a couple of minutes from the time =
of<br>submission<br>until the htmlized version and diff are available at =
tools.ietf.org.<br><br>The IETF =
Secretariat<br><br><br><br><br>___________________________________________=
____<br>siprec mailing =
list<br>siprec@ietf.org<br>https://www.ietf.org/mailman/listinfo/siprec<br=
><br></blockquote><br>_______________________________________________<br>s=
iprec mailing list<br><a =
href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br>https://www.ietf.or=
g/mailman/listinfo/siprec<br><br></blockquote><br>________________________=
_______________________<br>siprec mailing list<br><a =
href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br>https://www.ietf.or=
g/mailman/listinfo/siprec<br></blockquote><br><br></blockquote><br></block=
quote></div><br></body></html>=

--Apple-Mail=_615C2824-3A04-4ECB-B9F2-C647468C18A2--


From nobody Thu Jul  3 13:20:40 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBDF1B2B55; Thu,  3 Jul 2014 13:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpCDYUOWrToy; Thu,  3 Jul 2014 13:20:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C511B2B9A; Thu,  3 Jul 2014 13:20:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140703202010.10313.91660.idtracker@ietfa.amsl.com>
Date: Thu, 03 Jul 2014 13:20:10 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/f9NPNLF6Yl26FqDoq3tvYozpWH8
Cc: siprec@ietf.org
Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jul 2014 20:20:34 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SIP Recording Working Group of the IETF.

        Title           : Session Recording Protocol
        Authors         : Leon Portman
                          Henry Lum
                          Charles Eckel
                          Alan Johnston
                          Andrew Hutton
	Filename        : draft-ietf-siprec-protocol-13.txt
	Pages           : 42
	Date            : 2014-07-03

Abstract:
   This document specifies the use of the Session Initiation Protocol
   (SIP), the Session Description Protocol (SDP), and the Real Time
   Protocol (RTP) for delivering real-time media and metadata from a
   Communication Session (CS) to a recording device.  The Session
   Recording Protocol specifies the use of SIP, SDP, and RTP to
   establish a Recording Session (RS) between the Session Recording
   Client (SRC), which is on the path of the CS, and a Session Recording
   Server (SRS) at the recording device.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-siprec-protocol-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-protocol-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Jul  3 13:31:42 2014
Return-Path: <eckelcu@cisco.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C941B2A5A for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 13:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FdWK9r-z3Hg for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 13:31:39 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99FC1B2A26 for <siprec@ietf.org>; Thu,  3 Jul 2014 13:31:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2071; q=dns/txt; s=iport; t=1404419499; x=1405629099; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/3PZrr0uEUlDWC7jlesQNFjisivL6RZS9n+UwOFVPvo=; b=NK7t1K2+5RB4o3sslJXHoYKdRi6Hs/wGoNrHetVXGp4/ak4hYeXp18jW PJAJTMCtIhk5JY6KJCaAfLanvG8vrneWyeLp4aEmHKsXtViwdv37vfZNT sYxnoSFpr41AV0Yk/noGu+6SFGCHaIMisoE6adfJVQJbKb+YIOQFAMtuj E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmYIACe8tVOtJA2J/2dsb2JhbABagw1SUwe+XYZsUwGBDhZ1hAQBAQQBAQE3NBsCAQg2ECcLJQIEEwmIOQgFyUkXjymEQwWadoFIkkODQ4Iw
X-IronPort-AV: E=Sophos;i="5.01,596,1400025600"; d="scan'208";a="337711131"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2014 20:31:38 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s63KVcdX032677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <siprec@ietf.org>; Thu, 3 Jul 2014 20:31:38 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.242]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 15:31:37 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
Thread-Index: AQHPlvxNjHZ8hx4HoEuoLv/B3nK8sZuOrBIA
Date: Thu, 3 Jul 2014 20:31:36 +0000
Message-ID: <CFDB0A51.2D0DE%eckelcu@cisco.com>
References: <20140703202010.10313.91660.idtracker@ietfa.amsl.com>
In-Reply-To: <20140703202010.10313.91660.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.144.205]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D024BCF0F00863428BCB4318B082DDBB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/dbZ983S7p9FpCl1q-7InYc1toCk
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jul 2014 20:31:40 -0000

This update addresses the FIR vs. SIP INFO issue as well as the WGLC
comments. Please have a look and share any comments.

Cheers,
Charles

On 7/3/14, 1:20 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the SIP Recording Working Group of the IETF.
>
>        Title           : Session Recording Protocol
>        Authors         : Leon Portman
>                          Henry Lum
>                          Charles Eckel
>                          Alan Johnston
>                          Andrew Hutton
>	Filename        : draft-ietf-siprec-protocol-13.txt
>	Pages           : 42
>	Date            : 2014-07-03
>
>Abstract:
>   This document specifies the use of the Session Initiation Protocol
>   (SIP), the Session Description Protocol (SDP), and the Real Time
>   Protocol (RTP) for delivering real-time media and metadata from a
>   Communication Session (CS) to a recording device.  The Session
>   Recording Protocol specifies the use of SIP, SDP, and RTP to
>   establish a Recording Session (RS) between the Session Recording
>   Client (SRC), which is on the path of the CS, and a Session Recording
>   Server (SRS) at the recording device.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-siprec-protocol-13
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-13
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>siprec mailing list
>siprec@ietf.org
>https://www.ietf.org/mailman/listinfo/siprec


From nobody Thu Jul  3 13:36:50 2014
Return-Path: <eckelcu@cisco.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569081B2A2C for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 13:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIbmFP7EVcdp for <siprec@ietfa.amsl.com>; Thu,  3 Jul 2014 13:36:47 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD9F1A035E for <siprec@ietf.org>; Thu,  3 Jul 2014 13:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4147; q=dns/txt; s=iport; t=1404419806; x=1405629406; h=from:to:subject:date:message-id:mime-version; bh=Z+trS0svKSLqa4NeK6iJ1v+YtwkWac8KzXwH2CHXt/0=; b=U5HkFzXuDONce7Gso9sJPmzO2hRj50CmBnexKcXxrAv1J9xJLr7FtRT6 A7EK8xfVB6t/Rv3Oz1QaQlcmLBKs0U3ZUtji/tQyUvC1NRClQbr8KVqkX DtfdfcJRl324H1aPMDDeqGy9RGLJF+6BZAHfE4gUEqx+V8DUrsazyrHDc g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFALm+tVOtJA2I/2dsb2JhbABagkZHUlrGHIEPFnWEAwECBC1eAQgEDQMBAig5FAkKBAESiEINyUgTBI53BxMNEYQ9BZp2lAuDQ2yBRA
X-IronPort-AV: E=Sophos; i="5.01,597,1400025600"; d="scan'208,217"; a="58178122"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 03 Jul 2014 20:36:25 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s63KaO9P023527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 20:36:24 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.242]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 15:36:24 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] SIPREC Meeting and Agenda for IETF90.
Thread-Index: AQHPlv50J5MdcRGuSAucGlMXUhaygg==
Date: Thu, 3 Jul 2014 20:36:24 +0000
Message-ID: <CFDB0BBF.2D0EC%eckelcu@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.144.205]
Content-Type: multipart/alternative; boundary="_000_CFDB0BBF2D0ECeckelcuciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/pCnlLX4EIKpTjwSsvxfsdY_Mxkk
Subject: Re: [siprec] SIPREC Meeting and Agenda for IETF90.
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jul 2014 20:36:48 -0000

--_000_CFDB0BBF2D0ECeckelcuciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I just posted an update to the protocol draft. I do not anticipate requirin=
g agenda time in Toronto, but it really depends on folks reviewing the draf=
t and identifying any issues.

Cheers,
Charles

From: <Hutton>, Andrew <andrew.hutton@unify.com<mailto:andrew.hutton@unify.=
com>>
Date: Wednesday, July 2, 2014 at 2:32 AM
To: "siprec@ietf.org<mailto:siprec@ietf.org>" <siprec@ietf.org<mailto:sipre=
c@ietf.org>>
Subject: [siprec] SIPREC Meeting and Agenda for IETF90.

Hi All,

We need to submit a draft agenda by the 7th of July so please if you want t=
o present during the SIPREC Session then please let me know.

We are currently scheduled for the Friday 11:50 slot (https://datatracker.i=
etf.org/meeting/90/agenda.html) but there have been some changes to the age=
nda over the last couple of days including SIPREC being moved so there coul=
d still be late changes.

I will send a message to the list if the SIPREC session is moved again.

Regards
Andy


--_000_CFDB0BBF2D0ECeckelcuciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <0461C1A81A07334396B7A724749D51E5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif;">
<div>I just posted an update to the protocol draft. I do not anticipate req=
uiring agenda time in Toronto, but it really depends on folks reviewing the=
 draft and identifying any issues.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Charles</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>&lt;Hutton&gt;, Andrew &lt;<a=
 href=3D"mailto:andrew.hutton@unify.com">andrew.hutton@unify.com</a>&gt;<br=
>
<span style=3D"font-weight:bold">Date: </span>Wednesday, July 2, 2014 at 2:=
32 AM<br>
<span style=3D"font-weight:bold">To: </span>&quot;<a href=3D"mailto:siprec@=
ietf.org">siprec@ietf.org</a>&quot; &lt;<a href=3D"mailto:siprec@ietf.org">=
siprec@ietf.org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>[siprec] SIPREC Meeting an=
d Agenda for IETF90.<br>
</div>
<div><br>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:=
 #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf --><style><!-- .EmailQuote { margin-left: 1pt; padd=
ing-left: 4pt; border-left: #800000 2px solid; } --></style>
<div><font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi All,</div>
<div>&nbsp;</div>
<div>We need to submit a draft agenda by the 7<font size=3D"1"><span style=
=3D"font-size:7.3pt;"><sup>th</sup></span></font> of July so please if you =
want to present during the SIPREC Session then please let me know.</div>
<div>&nbsp;</div>
<div>We are currently scheduled for the Friday 11:50 slot (<a href=3D"https=
://datatracker.ietf.org/meeting/90/agenda.html"><font color=3D"blue"><u>htt=
ps://datatracker.ietf.org/meeting/90/agenda.html</u></font></a>) but there =
have been some changes to the agenda
 over the last couple of days including SIPREC being moved so there could s=
till be late changes.</div>
<div>&nbsp;</div>
<div>I will send a message to the list if the SIPREC session is moved again=
.</div>
<div>&nbsp;</div>
<div>Regards</div>
<div>Andy </div>
<div>&nbsp;</div>
</span></font></div>
</div>
</blockquote>
</span>
</body>
</html>

--_000_CFDB0BBF2D0ECeckelcuciscocom_--


From nobody Wed Jul  9 15:22:44 2014
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76A41A0065 for <siprec@ietfa.amsl.com>; Wed,  9 Jul 2014 15:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBAIZ0959y3Q for <siprec@ietfa.amsl.com>; Wed,  9 Jul 2014 15:22:40 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 653AD1A0123 for <siprec@ietf.org>; Wed,  9 Jul 2014 15:22:40 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id QJMh1o00716LCl05CNNfVb; Wed, 09 Jul 2014 22:22:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id QNNf1o00o3ZTu2S3SNNf57; Wed, 09 Jul 2014 22:22:39 +0000
Message-ID: <53BDC0AF.1060906@alum.mit.edu>
Date: Wed, 09 Jul 2014 18:22:39 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian Rosen <br@brianrosen.net>
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <ECFDDD30-85A7-471C-95FF-767F82C80946@brianrosen.net> <53B58B0B.1060004@alum.mit.edu> <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net>
In-Reply-To: <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404944560; bh=bY3SZL627+bPcACiiHjT+vnqxY3kDZaquboRqBq5e7g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q0int0caGmZolQUSECXM9/P6K9oQf0HzQmsi8E2wjYzL2Mkd2E+KI39nEnCH6mJbu vOpRd+105wXJRPb9mqbyNfps8gdu3WXyO0a+MoksXkCnECPd1PwfiyC5j7DBY/TVpv vQzOkxxBIaYDG1PgRIQKFg686uTqT/OgjUDWM7AUlbPq2pmEjBJcVpvbfdv1st3Z/g mR3UOLbOdyZRFp9YNfr5QcSHCuoyoH1mH5XGeD8vJ0e1EUBVxOs7wMgKvYVAYqdD0N /FMod3a01UGhowGosJw3jvx86HM4s9iU26unv4nhglrwVqS2JyZpcChY7EeRBEJSFh BJ5X2ucDBopMA==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/ZHWd06LB9mW55xva1V_O6VhPclA
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jul 2014 22:22:42 -0000

Brian - inline

On 7/3/14 3:25 PM, Brian Rosen wrote:
>
> On Jul 3, 2014, at 12:55 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto:pkyzivat@alum.mit.edu>> wrote:
>
>> On 7/1/14 5:34 PM, Brian Rosen wrote:
>>> I’ve reviewed this document.  I think it is a very good start, and
>>> think we can get it ready to ship quite quickly.
>>>
>>> I have the following comments:
>>>
>>> We need to specify a way to send and save REPORTS that are
>>> sent/received on the CS to the SRS.  If, for example, a message sent
>>> by a party to another is not received completely,
>>> and a REPORT js generated on the RS,  we need to somehow record than
>>> in the CS.
>>
>> I guess CS and RS need to be swapped in the above line, right?
> Yeah doh!
>>
>>> You have a note about reports, but it isn’t clear if you mean reports
>>> in the CS or the RS.  Both have to be recorded, but at least in the
>>> RS, the SRS has all the info needed.
>>
>> I just have a placeholder, because I haven't thought much about it yet.
>>
>> I especially hadn't thought about reports on the RS. Note that the SRS
>> won't be sending anything except reports to the SRC, so there is no
>> reason for the SRC to be sending reports to the SRS about the RS msrp
>> session.
> Yeah, but it has to send reports it got on the CS somehow
>
>>
>> Conversely, suppose the SRC gets a report from the SRS that something
>> hasn't made it successfully. What should it do? (I can't think of
>> anything useful for it do do.) I guess this is analogous to the SRC
>> getting RTCP reports indicating packet loss of RTP media. We don't
>> talk about that.
> No, I think if the SRC gets a report of a problem on the CS it must
> record that.

That is a different case. I was specifically talking about the case 
where the SRC gets a report from the *SRS*. There is nothing useful it 
can do. Obviously the SRS knows about the problem (it sent the report), 
so it can record an indication of the problem without the SRC having to 
tell it.

> I think if we neglected to record known problems detected in RTCP
> reports then we need to fix that too at some point — if the SRC knows
> about a problem, that has to be recorded.
>
>>
>> But reports on the CS are significant information that could be
>> important to record.

This is the case you were talking about.

>> I think they can't be sent as MSRP reports. I
>> suspect we must find a way to encapsulate them as regular MSRP
>> messages. But that seems messy. Ideas are welcome.
> Yeah, I think that’s right, and I think it’s messy.  Sending them in
> metadata is a possibility.

I don't think we can bound the rate that these occur. So I am very 
reluctant to use the metadata mechanism to deal with them.

> Extending reports in some manner is a
> possibility.

Yes, this is possible. But it would be nice to avoid modifying MSRP.

>>> I think there is a problem with the text about adding a CPIM wrapper
>>> if there isn’t one.  I think the recording has to know if the
>>> original message was sent by some entity other than the one in the
>>> CPIM From (that is, we have to preserve the MSRP From).  The SRS has
>>> to know whether the original message had a CPIM header, and its
>>> contents.   If the SRC changes the message (by adding the wrapper) I
>>> think the SRS has to be able to figure that out, and record that fact
>>> in some way.
>>
>> I hear you, though I'm not yet convinced how important it is for the
>> SRS to be able to make this distinction.
> I think the recording is what the SRC got.  If you can’t effectively
> reproduce what the SRC gets, the mechanism is not adequate.

Does introducing a CPIM wrapper where there was none (making explict 
what had been implicit) prevent reproducing what the SRC got?

Consider that we allow the SRC to transcode media before sending it to 
the SRS. And we permit the SRC to transcode media before recording it. 
In both of those cases we can't reproduce *exactly* what the SRC got.

What is so different here?

>> I think the only way to be *certain* that the SRS can distinguish
>> these is to wrap *every* message, even those that already contain CPIM
>> headers. Then the SRS would know that the outer wrapper was always
>> from the SRC, and that if there was another cpim wrapper inside then
>> it was from the CS. But that seems like overkill.
> Yeah, I’d prefer not to do that
>
>>
>> If we only put CPIM wrappers on messages that don't already have them,
>> then we could put something *special* in them. But there would be no
>> guarantee that the CS didn't use that.
> There is always a way.  We can extend CPIM if we need to.

Yes we could. If we feel that we must.

>> We could also introduce a new mime type similar to CPIM, but specially
>> for recording. If we constrained the usage of that then we might be
>> able to claim that it could never appear on the CS. But I would prefer
>> to avoid this.
> I’d rather just extend CPIM

This is a matter of taste. I could go either way. It would be nice to 
not have to extend CPIM.

>>> When we echo a message from the RS to the CS, we’re going to lose the
>>> MESSAGE-ID from the RS.  That’s a problem.  We have to save that info
>>> in the recording.  A hack would be to use the same message ID in both
>>> the CS and the RS, possibly with some prefix.

After studying 4975 awhile I think we could do this. It *should* be ok 
to use the old message-ids as-is - they are supposed to be globally 
unique, across sessions. (Of course if we reuse them then they won't be 
globally unique.)

If we are hyper, we could allow the SRC to add a prefix. But that 
introduces complications if we are doing redundant SRCs sending to the 
same SRS, because we won't recognize when we get the same message on 
both paths.

>>> I worry a bit about chunking in the RS differently from chunking in
>>> the CS. I may be mistaken, but if the chunking is different, will
>>> that affect the byte-range response in a failure report?

The whole point of reporting byte ranges is that they are independent of 
the chunking. I don't think this is an issue.

>> Don't the above issues have analogs for RTP/RTCP?
> No, i don’t think so.  Message ID is much more of a real id then
> anything you find in an RTP header.  You can derive wall time, which
> might be similar, but not really.

I guess what is different about message id is that its scope encompasses 
multiple MSRP sessions. If the CS participants drop one session and 
start another, and resend messages with the same ids, then I guess we do 
want the SRS to understand that they were updating the same message.

>> Do we have any more requirement to solve them here than we did there?
>>
>>> The URIs in the original to/from need to be captured, but they will
>>> be different in the RS.  Need to fix that.
>>
>> I assume you are talking about the to/from in CPIM, right? Why do they
>> need to be different in the RS?
> MSRP To/From in the RS is SRS/SRC.

OK.

> If there wasn’t any CPIM, we could
> add it, in which case MSRP To/From in CS becomes CPIM To/From in RS.

Why? It doesn't have to be if we don't want that. I would expect the SRC 
to insert URIs that it knows from the CS for the participants in this 
MSRP session. These would probably be the SIP URIs from the CS SIP 
session of the sender and receiver of the MSRP session in the CS.

> If
> there is CPIM already, we need to preserve it, and then we need to solve
> sending CS MSRP To/From in the RS.

Why do we need the MSRP To/From at all? Those are just artificial things 
used to identify particular sessions.

>>> Do we need to say something about max-size issues between CS and RS?
>>
>> Probably. Seems like a policy issue in the SRS. If the SRS doesn't
>> want to record large messages. Maybe we want to specify that the SRC
>> MUST honor the SRS's max-size, bypassing recording of messages that
>> are too big. (Or perhaps inserting special small messages as
>> placeholders for the bypassed messages.)
> Yeah, something.  Basically, to avoid problems, CS max has to be at
> least as big as RS max.  I think that’s just a MUST as a by-the-way.

I don't think so. We give the SRS a lot of lattitude about what it 
records. If it wants to bound its resources by refusing to record small 
messages, then that is its business.

We can't expect the CS to change its behavior to suit the RS. And IIUC 
max-size is not negotiated, it is declared by the receiver. So there is 
no way to communicate the max-size from the CS to the RS.

Also, max-size is only a hint - the sender need not honor it.

We *could* specify that the SRC SHOULD NOT forward messages on the RS 
that exceed the SRS's max-size. I don't think there is much else we can 
or should do.

>>> You can’t possibly not change -metadata.  As an example. you have to
>>> allow an msrp AoR for a participant
>>
>> Hmm. I guess so. I was thinking that we were lenient in the AoR type,
>> but I guess not.

Based on my own comments above, I don't know why we need to have an msrp 
AOR for a participant. I think we would identify participants in an MSRP 
media session by sip URI.

>> Since the metadata isn't done yet, maybe we can change it before it is
>> done, to allow this. (Allow any URI.)
> Depends on how we solve some of these other issues.
> That one leaped out at me, have to look harder to see if there are
> others.   Interaction of the term “Participant” for example.
>
>>
>>> Yes, I think we have to extend Participant to handle nicks.
>>
>> A participant can already have multiple AoR/Name pairs. So we could
>> add the nickname as one of those.
> Would have to be labeled in some way

I went back to review the chat stuff that defines Nickname. (It still 
isn't an RFC!) I remembered wrong - the nickname isn't represented as a 
URI. Ideally we would manage it in-band in the MSRP. But the way 
nicknames are managed doesn't work very well for us. An msrp session is 
bound to at most one nickname at any point in time.

We could work with that, sending NICKNAME requests on the RS msrp 
session as needed to set the nickname to match that of the message we 
want to send. But that would be unpleasant.

An alternative would be to define the use of Use-Nickname with a SEND 
message. It currently isn't defined, but draft-ietf-simple-chat-18 
leaves it open to be defined in the future.

We would want to specify that the SRS will be especially lenient 
(promiscuous) in approving the use of nicknames.

>> (We really did try to plan ahead with the metadata.)
>>
>>> Probably also to handle the SIP session URI vs the MSRP URIs
>>
>> Note that the metadata associates participants with both the CS and
>> individual media streams. So the SIP session URIs are already covered
>> there.
> I’m missing something, but it’s probably lack of clue on how metadata
> works.
> And, I spotted another metadata change problem:
>
>
>
>         6.5.1
>         <http://tools.ietf.org/html/draft-ietf-siprec-metadata-15#section-6.5.1>.
>         Attributes
>
>
>
>     Participant has a single defined attribute:
>
>     o  AoR / Name pair list - This attribute is a list of Name/AoR
>        tuples.  An AoR MAY be a SIP/SIPS/TEL URI.  Name represents
>        Participant name(SIP display name) or dialed number (DN) (when
>        known).  Multiple tuples are allowed for cases where a participant
>        has more than one AoR.  (For example a P-Asserted-identity header
>        [RFC3325  <http://tools.ietf.org/html/rfc3325>] can have both SIP and TEL URIs.)
>
>
> Have to add msrp/msrps to the list.  Does the MSRP To/From HAVE to be an
> msrp/msrps scheme, or can it be a sip AoR?  If the latter, we could have
> a corner case where the SIP AoR and the MSRP AoR were both SIP but
> different.

The MSRP From/To URIs must be MSRP URIs.

But, I still don't see why we need to care about preserving those in the 
recording.

I must say that this is the kind of discussion I have been hoping to 
have - to nail down the nitty-gritty details.

	Thanks,
	Paul

>> Thanks,
>> Paul
>>
>>> Brian
>>>
>>> On Jun 26, 2014, at 12:32 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>
>>>> Trying one more time. Please!!!
>>>>
>>>> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>>>>> Can I get some people in the wg to review and comment on this version?
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>>>>> I've submitted a revised version of the msrp recording draft.
>>>>>> This one is substantially fleshed out. It certainly needs more
>>>>>> tweaking,
>>>>>> but is complete enough that you should be able to make meaningful
>>>>>> comments on the approach.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> Subject: New Version Notification for
>>>>>> draft-yan-siprec-msrp-recording-01.txt
>>>>>> Date: Wed, 28 May 2014 15:03:24 -0700
>>>>>> From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>>>>> To: Michael Yan <michael.yan@huawei.com
>>>>>> <mailto:michael.yan@huawei.com>>,        "Paul H. Kyzivat"
>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>,
>>>>>>        "Michael Yan" <michael.yan@huawei.com
>>>>>> <mailto:michael.yan@huawei.com>>,
>>>>>>        "Paul Kyzivat" <pkyzivat@alum.mit.edu
>>>>>> <mailto:pkyzivat@alum.mit.edu>>
>>>>>>
>>>>>>
>>>>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>>>>> has been successfully submitted by Paul H. Kyzivat and posted to the
>>>>>> IETF repository.
>>>>>>
>>>>>> Name:        draft-yan-siprec-msrp-recording
>>>>>> Revision:    01
>>>>>> Title:        Overview for MSRP Recording based on SIPREC
>>>>>> Document date:    2014-05-28
>>>>>> Group:        Individual Submission
>>>>>> Pages:        9
>>>>>> URL:
>>>>>> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt
>>>>>>
>>>>>> Status:
>>>>>> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>>>>> Htmlized:
>>>>>> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>>>>> Diff:
>>>>>> http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-01
>>>>>>
>>>>>> Abstract:
>>>>>>    SIPREC is capable of recording interactive text media that is
>>>>>>    transmitted via RTP.  However that format is not commonly used for
>>>>>>    message or chat scenarios.  There is also a need for recording text
>>>>>>    media carried via MSRP.  One case of note is exchange of text
>>>>>> between
>>>>>>    hearing-impaired users and emergence service bureaus.  Also,
>>>>>>    recording support is needed for MSRP used in chat conferences and
>>>>>>    multimedia conferences.
>>>>>>
>>>>>>    This document describes how to achieve MSRP channel recording
>>>>>> within
>>>>>>    the mechanism of SIP Recording (SIPREC).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>> submission
>>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> siprec mailing list
>>>>>> siprec@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> siprec mailing list
>>>>> siprec@ietf.org <mailto:siprec@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>
>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org <mailto:siprec@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>>
>>
>


From nobody Wed Jul  9 15:49:05 2014
Return-Path: <br@brianrosen.net>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F411A014E for <siprec@ietfa.amsl.com>; Wed,  9 Jul 2014 15:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level: 
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv3ja-I9hxLt for <siprec@ietfa.amsl.com>; Wed,  9 Jul 2014 15:49:00 -0700 (PDT)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA941A014C for <siprec@ietf.org>; Wed,  9 Jul 2014 15:48:59 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id il7so9136459vcb.27 for <siprec@ietf.org>; Wed, 09 Jul 2014 15:48:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=T/0ET7KUtiDsAAOuV46seoNI1tYV2WT/eYADyFPdtBg=; b=KLO8rTBd/PP0qL6FgLO9te0KXRJ2d9SQlN0UNrgDlwt5qtAbswgwmJy0emYvYFnmPh KP+EpgHJK7wd00gBlQl6UurqCb7RZvDhEu1RkGpsoH+mCFL5j7nFXLHsLCDSBe6cQYeO tB4GXBgBxhc54xG+VwF0AlOXnKNqH+rpptF3oOCKfNVqD1cC/nciPtUpJO8CaQFX6v8N JVZLc2njxIpGciYX064WuQKT4VgM0JaE19C87vUZGjZxEJByysNlgtZDG+xTt81S3/Y5 MrbBNyVOslu+kNKe7zIEJCMGlX53Ypl3/zP21XIaUlNU0VAhK1OZOA1GeOpIa78PMZjc P1CQ==
X-Gm-Message-State: ALoCoQkvkoEXgAGd3duzThQz+R9ycGTbcueKSdtkIMy4GsSzurWPeaphh4E0Hq82N2mtcMWuwSk6
X-Received: by 10.52.228.163 with SMTP id sj3mr34519462vdc.30.1404946138933; Wed, 09 Jul 2014 15:48:58 -0700 (PDT)
Received: from [192.168.129.103] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id i10sm87865054qaq.22.2014.07.09.15.48.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 15:48:57 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <53BDC0AF.1060906@alum.mit.edu>
Date: Wed, 9 Jul 2014 15:48:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D3E761E-94FE-4C10-98BE-A87ACAE554CA@brianrosen.net>
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <ECFDDD30-85A7-471C-95FF-767F82C80946@brianrosen.net> <53B58B0B.1060004@alum.mit.edu> <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net> <53BDC0AF.1060906@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/RfNczCas3pMsOkfo_JnnOfcQXMk
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jul 2014 22:49:03 -0000

Hopefully, we aren=92t getting too deep in levels
On Jul 9, 2014, at 3:22 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Brian - inline
>=20
> On 7/3/14 3:25 PM, Brian Rosen wrote:
>>=20
>> On Jul 3, 2014, at 12:55 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>=20
>>> On 7/1/14 5:34 PM, Brian Rosen wrote:
>>>> I=92ve reviewed this document.  I think it is a very good start, =
and
>>>> think we can get it ready to ship quite quickly.
>>>>=20
>>>> I have the following comments:
>>>>=20
>>>> We need to specify a way to send and save REPORTS that are
>>>> sent/received on the CS to the SRS.  If, for example, a message =
sent
>>>> by a party to another is not received completely,
>>>> and a REPORT js generated on the RS,  we need to somehow record =
than
>>>> in the CS.
>>>=20
>>> I guess CS and RS need to be swapped in the above line, right?
>> Yeah doh!
>>>=20
>>>> You have a note about reports, but it isn=92t clear if you mean =
reports
>>>> in the CS or the RS.  Both have to be recorded, but at least in the
>>>> RS, the SRS has all the info needed.
>>>=20
>>> I just have a placeholder, because I haven't thought much about it =
yet.
>>>=20
>>> I especially hadn't thought about reports on the RS. Note that the =
SRS
>>> won't be sending anything except reports to the SRC, so there is no
>>> reason for the SRC to be sending reports to the SRS about the RS =
msrp
>>> session.
>> Yeah, but it has to send reports it got on the CS somehow
>>=20
>>>=20
>>> Conversely, suppose the SRC gets a report from the SRS that =
something
>>> hasn't made it successfully. What should it do? (I can't think of
>>> anything useful for it do do.) I guess this is analogous to the SRC
>>> getting RTCP reports indicating packet loss of RTP media. We don't
>>> talk about that.
>> No, I think if the SRC gets a report of a problem on the CS it must
>> record that.
>=20
> That is a different case. I was specifically talking about the case =
where the SRC gets a report from the *SRS*. There is nothing useful it =
can do. Obviously the SRS knows about the problem (it sent the report), =
so it can record an indication of the problem without the SRC having to =
tell it.
Right, my bad.  The SRS knows, it can record it.

>=20
>> I think if we neglected to record known problems detected in RTCP
>> reports then we need to fix that too at some point =97 if the SRC =
knows
>> about a problem, that has to be recorded.
>>=20
>>>=20
>>> But reports on the CS are significant information that could be
>>> important to record.
>=20
> This is the case you were talking about.
Yeah

>=20
>>> I think they can't be sent as MSRP reports. I
>>> suspect we must find a way to encapsulate them as regular MSRP
>>> messages. But that seems messy. Ideas are welcome.
>> Yeah, I think that=92s right, and I think it=92s messy.  Sending them =
in
>> metadata is a possibility.
>=20
> I don't think we can bound the rate that these occur. So I am very =
reluctant to use the metadata mechanism to deal with them.
Understand, but encapsulation in MSRP would use a lot of BW also

>=20
>> Extending reports in some manner is a
>> possibility.
>=20
> Yes, this is possible. But it would be nice to avoid modifying MSRP.
Yeah, but might be lesser of evils

>=20
>>>> I think there is a problem with the text about adding a CPIM =
wrapper
>>>> if there isn=92t one.  I think the recording has to know if the
>>>> original message was sent by some entity other than the one in the
>>>> CPIM =46rom (that is, we have to preserve the MSRP From).  The SRS =
has
>>>> to know whether the original message had a CPIM header, and its
>>>> contents.   If the SRC changes the message (by adding the wrapper) =
I
>>>> think the SRS has to be able to figure that out, and record that =
fact
>>>> in some way.
>>>=20
>>> I hear you, though I'm not yet convinced how important it is for the
>>> SRS to be able to make this distinction.
>> I think the recording is what the SRC got.  If you can=92t =
effectively
>> reproduce what the SRC gets, the mechanism is not adequate.
>=20
> Does introducing a CPIM wrapper where there was none (making explict =
what had been implicit) prevent reproducing what the SRC got?
Because the SRS can=92t distinguish between the SRC receiving a wrapped =
message from a case where the SRC did the wrapping on the RS.

>=20
> Consider that we allow the SRC to transcode media before sending it to =
the SRS. And we permit the SRC to transcode media before recording it. =
In both of those cases we can't reproduce *exactly* what the SRC got.
I think this is substantively different but YMMV

>=20
> What is so different here?
>=20
>>> I think the only way to be *certain* that the SRS can distinguish
>>> these is to wrap *every* message, even those that already contain =
CPIM
>>> headers. Then the SRS would know that the outer wrapper was always
>>> from the SRC, and that if there was another cpim wrapper inside then
>>> it was from the CS. But that seems like overkill.
>> Yeah, I=92d prefer not to do that
>>=20
>>>=20
>>> If we only put CPIM wrappers on messages that don't already have =
them,
>>> then we could put something *special* in them. But there would be no
>>> guarantee that the CS didn't use that.
>> There is always a way.  We can extend CPIM if we need to.
>=20
> Yes we could. If we feel that we must.
>=20
>>> We could also introduce a new mime type similar to CPIM, but =
specially
>>> for recording. If we constrained the usage of that then we might be
>>> able to claim that it could never appear on the CS. But I would =
prefer
>>> to avoid this.
>> I=92d rather just extend CPIM
>=20
> This is a matter of taste. I could go either way. It would be nice to =
not have to extend CPIM.
Something has to give.  Probably a good topic for the meeting

>=20
>>>> When we echo a message from the RS to the CS, we=92re going to lose =
the
>>>> MESSAGE-ID from the RS.  That=92s a problem.  We have to save that =
info
>>>> in the recording.  A hack would be to use the same message ID in =
both
>>>> the CS and the RS, possibly with some prefix.
>=20
> After studying 4975 awhile I think we could do this. It *should* be ok =
to use the old message-ids as-is - they are supposed to be globally =
unique, across sessions. (Of course if we reuse them then they won't be =
globally unique.)
>=20
> If we are hyper, we could allow the SRC to add a prefix. But that =
introduces complications if we are doing redundant SRCs sending to the =
same SRS, because we won't recognize when we get the same message on =
both paths.
Yeah, I understand.  If the SRC adds a prefix, it could be different =
from the prefix the redundant SRC uses and the SRS could figure it out.

>=20
>>>> I worry a bit about chunking in the RS differently from chunking in
>>>> the CS. I may be mistaken, but if the chunking is different, will
>>>> that affect the byte-range response in a failure report?
>=20
> The whole point of reporting byte ranges is that they are independent =
of the chunking. I don't think this is an issue.
Okay

>=20
>>> Don't the above issues have analogs for RTP/RTCP?
>> No, i don=92t think so.  Message ID is much more of a real id then
>> anything you find in an RTP header.  You can derive wall time, which
>> might be similar, but not really.
>=20
> I guess what is different about message id is that its scope =
encompasses multiple MSRP sessions. If the CS participants drop one =
session and start another, and resend messages with the same ids, then I =
guess we do want the SRS to understand that they were updating the same =
message.
Yes, and probably more.

>=20
>>> Do we have any more requirement to solve them here than we did =
there?
>>>=20
>>>> The URIs in the original to/from need to be captured, but they will
>>>> be different in the RS.  Need to fix that.
>>>=20
>>> I assume you are talking about the to/from in CPIM, right? Why do =
they
>>> need to be different in the RS?
>> MSRP To/=46rom in the RS is SRS/SRC.
>=20
> OK.
>=20
>> If there wasn=92t any CPIM, we could
>> add it, in which case MSRP To/=46rom in CS becomes CPIM To/=46rom in =
RS.
>=20
> Why? It doesn't have to be if we don't want that. I would expect the =
SRC to insert URIs that it knows from the CS for the participants in =
this MSRP session. These would probably be the SIP URIs from the CS SIP =
session of the sender and receiver of the MSRP session in the CS.
The SRS has to be able to derive what was MSRP To/=46rom in the CS was.  =
It=92s recording what the SRC saw.


>=20
>> If
>> there is CPIM already, we need to preserve it, and then we need to =
solve
>> sending CS MSRP To/=46rom in the RS.
>=20
> Why do we need the MSRP To/=46rom at all? Those are just artificial =
things used to identify particular sessions.
I think the recording has to record what the SRC got.  I don=92t think =
it=92s good enough to derive a notion of session, create new session IDs =
and then just use them.  The recording has to be able to reproduce what =
the SRC saw.


>=20
>>>> Do we need to say something about max-size issues between CS and =
RS?
>>>=20
>>> Probably. Seems like a policy issue in the SRS. If the SRS doesn't
>>> want to record large messages. Maybe we want to specify that the SRC
>>> MUST honor the SRS's max-size, bypassing recording of messages that
>>> are too big. (Or perhaps inserting special small messages as
>>> placeholders for the bypassed messages.)
>> Yeah, something.  Basically, to avoid problems, CS max has to be at
>> least as big as RS max.  I think that=92s just a MUST as a =
by-the-way.
>=20
> I don't think so. We give the SRS a lot of lattitude about what it =
records. If it wants to bound its resources by refusing to record small =
messages, then that is its business.
>=20
> We can't expect the CS to change its behavior to suit the RS. And IIUC =
max-size is not negotiated, it is declared by the receiver. So there is =
no way to communicate the max-size from the CS to the RS.
>=20
> Also, max-size is only a hint - the sender need not honor it.
>=20
> We *could* specify that the SRC SHOULD NOT forward messages on the RS =
that exceed the SRS's max-size. I don't think there is much else we can =
or should do.
Looks like we have to just have a discussion on the issue in the doc.  =
The limitation is that the SRC doesn=92t know the SRS max until after =
the CS is established, so it can=92t do something like reflect the RS =
max into the CS.  As you point out, that=92s not really desirable in the =
first place.  So, probably just point out the issues and say it=92s a =
system design issue to make sure the RS can handle what could occur on =
the CS or recording will be impaired.  I=92m okay with SHOULD NOT on the =
RS.
=20
>=20
>>>> You can=92t possibly not change -metadata.  As an example. you have =
to
>>>> allow an msrp AoR for a participant
>>>=20
>>> Hmm. I guess so. I was thinking that we were lenient in the AoR =
type,
>>> but I guess not.
>=20
> Based on my own comments above, I don't know why we need to have an =
msrp AOR for a participant. I think we would identify participants in an =
MSRP media session by sip URI.
Again, I think we have to record what is in the CS.  If the CS =
identifies a participant by an MSRP AoR, we need to record that.  We can =
use whatever we want in the RS itself, so long as we can reproduce what =
was in the original CS.

>=20
>>> Since the metadata isn't done yet, maybe we can change it before it =
is
>>> done, to allow this. (Allow any URI.)
>> Depends on how we solve some of these other issues.
>> That one leaped out at me, have to look harder to see if there are
>> others.   Interaction of the term =93Participant=94 for example.
>>=20
>>>=20
>>>> Yes, I think we have to extend Participant to handle nicks.
>>>=20
>>> A participant can already have multiple AoR/Name pairs. So we could
>>> add the nickname as one of those.
>> Would have to be labeled in some way
>=20
> I went back to review the chat stuff that defines Nickname. (It still =
isn't an RFC!) I remembered wrong - the nickname isn't represented as a =
URI. Ideally we would manage it in-band in the MSRP. But the way =
nicknames are managed doesn't work very well for us. An msrp session is =
bound to at most one nickname at any point in time.
>=20
> We could work with that, sending NICKNAME requests on the RS msrp =
session as needed to set the nickname to match that of the message we =
want to send. But that would be unpleasant.
>=20
> An alternative would be to define the use of Use-Nickname with a SEND =
message. It currently isn't defined, but draft-ietf-simple-chat-18 =
leaves it open to be defined in the future.
>=20
> We would want to specify that the SRS will be especially lenient =
(promiscuous) in approving the use of nicknames.
Hmmm, lots to think about.  Probably want to consult the chat authors.

>=20
>>> (We really did try to plan ahead with the metadata.)
>>>=20
>>>> Probably also to handle the SIP session URI vs the MSRP URIs
>>>=20
>>> Note that the metadata associates participants with both the CS and
>>> individual media streams. So the SIP session URIs are already =
covered
>>> there.
>> I=92m missing something, but it=92s probably lack of clue on how =
metadata
>> works.
>> And, I spotted another metadata change problem:
>>=20
>>=20
>>=20
>>        6.5.1
>>        =
<http://tools.ietf.org/html/draft-ietf-siprec-metadata-15#section-6.5.1>.
>>        Attributes
>>=20
>>=20
>>=20
>>    Participant has a single defined attribute:
>>=20
>>    o  AoR / Name pair list - This attribute is a list of Name/AoR
>>       tuples.  An AoR MAY be a SIP/SIPS/TEL URI.  Name represents
>>       Participant name(SIP display name) or dialed number (DN) (when
>>       known).  Multiple tuples are allowed for cases where a =
participant
>>       has more than one AoR.  (For example a P-Asserted-identity =
header
>>       [RFC3325  <http://tools.ietf.org/html/rfc3325>] can have both =
SIP and TEL URIs.)
>>=20
>>=20
>> Have to add msrp/msrps to the list.  Does the MSRP To/=46rom HAVE to =
be an
>> msrp/msrps scheme, or can it be a sip AoR?  If the latter, we could =
have
>> a corner case where the SIP AoR and the MSRP AoR were both SIP but
>> different.
>=20
> The MSRP From/To URIs must be MSRP URIs.
>=20
> But, I still don't see why we need to care about preserving those in =
the recording.
>=20
> I must say that this is the kind of discussion I have been hoping to =
have - to nail down the nitty-gritty details.
Happy to be of service as more than a co-chair :)

>=20
> 	Thanks,
> 	Paul
>=20
>>> Thanks,
>>> Paul
>>>=20
>>>> Brian
>>>>=20
>>>> On Jun 26, 2014, at 12:32 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>=20
>>>>> Trying one more time. Please!!!
>>>>>=20
>>>>> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>>>>>> Can I get some people in the wg to review and comment on this =
version?
>>>>>>=20
>>>>>>    Thanks,
>>>>>>    Paul
>>>>>>=20
>>>>>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>>>>>> I've submitted a revised version of the msrp recording draft.
>>>>>>> This one is substantially fleshed out. It certainly needs more
>>>>>>> tweaking,
>>>>>>> but is complete enough that you should be able to make =
meaningful
>>>>>>> comments on the approach.
>>>>>>>=20
>>>>>>>    Thanks,
>>>>>>>    Paul
>>>>>>>=20
>>>>>>>=20
>>>>>>> -------- Original Message --------
>>>>>>> Subject: New Version Notification for
>>>>>>> draft-yan-siprec-msrp-recording-01.txt
>>>>>>> Date: Wed, 28 May 2014 15:03:24 -0700
>>>>>>> From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>>>>>> To: Michael Yan <michael.yan@huawei.com
>>>>>>> <mailto:michael.yan@huawei.com>>,        "Paul H. Kyzivat"
>>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>,
>>>>>>>       "Michael Yan" <michael.yan@huawei.com
>>>>>>> <mailto:michael.yan@huawei.com>>,
>>>>>>>       "Paul Kyzivat" <pkyzivat@alum.mit.edu
>>>>>>> <mailto:pkyzivat@alum.mit.edu>>
>>>>>>>=20
>>>>>>>=20
>>>>>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>>>>>> has been successfully submitted by Paul H. Kyzivat and posted to =
the
>>>>>>> IETF repository.
>>>>>>>=20
>>>>>>> Name:        draft-yan-siprec-msrp-recording
>>>>>>> Revision:    01
>>>>>>> Title:        Overview for MSRP Recording based on SIPREC
>>>>>>> Document date:    2014-05-28
>>>>>>> Group:        Individual Submission
>>>>>>> Pages:        9
>>>>>>> URL:
>>>>>>> =
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt=

>>>>>>>=20
>>>>>>> Status:
>>>>>>> =
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>>>>>> Htmlized:
>>>>>>> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>>>>>> Diff:
>>>>>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-yan-siprec-msrp-recording-01
>>>>>>>=20
>>>>>>> Abstract:
>>>>>>>   SIPREC is capable of recording interactive text media that is
>>>>>>>   transmitted via RTP.  However that format is not commonly used =
for
>>>>>>>   message or chat scenarios.  There is also a need for recording =
text
>>>>>>>   media carried via MSRP.  One case of note is exchange of text
>>>>>>> between
>>>>>>>   hearing-impaired users and emergence service bureaus.  Also,
>>>>>>>   recording support is needed for MSRP used in chat conferences =
and
>>>>>>>   multimedia conferences.
>>>>>>>=20
>>>>>>>   This document describes how to achieve MSRP channel recording
>>>>>>> within
>>>>>>>   the mechanism of SIP Recording (SIPREC).
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> Please note that it may take a couple of minutes from the time =
of
>>>>>>> submission
>>>>>>> until the htmlized version and diff are available at =
tools.ietf.org.
>>>>>>>=20
>>>>>>> The IETF Secretariat
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> siprec mailing list
>>>>>>> siprec@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> siprec mailing list
>>>>>> siprec@ietf.org <mailto:siprec@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> siprec mailing list
>>>>> siprec@ietf.org <mailto:siprec@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From nobody Thu Jul 10 15:00:24 2014
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4421B27CF for <siprec@ietfa.amsl.com>; Thu, 10 Jul 2014 15:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS-Q8geudB-L for <siprec@ietfa.amsl.com>; Thu, 10 Jul 2014 15:00:22 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01C1B27B8 for <siprec@ietf.org>; Thu, 10 Jul 2014 15:00:22 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id QlJ11o0030mv7h05Dm0Mxd; Thu, 10 Jul 2014 22:00:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id Qm0M1o00T3ZTu2S3Xm0MMQ; Thu, 10 Jul 2014 22:00:21 +0000
Message-ID: <53BF0CF5.8090503@alum.mit.edu>
Date: Thu, 10 Jul 2014 18:00:21 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian Rosen <br@brianrosen.net>
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <ECFDDD30-85A7-471C-95FF-767F82C80946@brianrosen.net> <53B58B0B.1060004@alum.mit.edu> <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net> <53BDC0AF.1060906@alum.mit.edu> <0D3E761E-94FE-4C10-98BE-A87ACAE554CA@brianrosen.net>
In-Reply-To: <0D3E761E-94FE-4C10-98BE-A87ACAE554CA@brianrosen.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405029621; bh=VLgg6pwR6Iw0ol3UGKVJEk+LC/FJCWO/K0ZwxXNRSQA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Jx4O1fyySw8qCu7kgpfh6eMvRJN6INYAOGzkcZmlzzIWnjSYZczgHRu6InXWCZxWt Esh0vLweUwiY1xTdSmA1fOeFQl0SP7vZpVvmVPXedDSIs1D6/7r51tKRdedzLst7Kz 1kp7YGiBwT4tdSrbhCARgSCFjrJU4VH1nw/c978aBZ7PK5PPYtkERxokOu/vj3h6WN DVHSBC+3ya8acQzWRkesxt7DZTY+W9OznaGz1RQ9VP0viDJDeWcz2okS1BYCl0XVaY gx+dxwMhmPjlXkSHDyPnwrdzK9/PfV638vQ5008DKrWVnO0DnLljcZ5YDs70RLr+8O R0O/W+ycj2odQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/3hgGCFk1OH6YfWvU26lPMI_0RFU
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jul 2014 22:00:23 -0000

On 7/9/14 6:48 PM, Brian Rosen wrote:
> Hopefully, we aren’t getting too deep in levels

I'll try to thin it out here.

>>>> But reports on the CS are significant information that could be
>>>> important to record.

>>>> I think they can't be sent as MSRP reports. I
>>>> suspect we must find a way to encapsulate them as regular MSRP
>>>> messages. But that seems messy. Ideas are welcome.
>>> Yeah, I think that’s right, and I think it’s messy.  Sending them in
>>> metadata is a possibility.
>>
>> I don't think we can bound the rate that these occur. So I am very reluctant to use the metadata mechanism to deal with them.
> Understand, but encapsulation in MSRP would use a lot of BW also

Really?

I guess for small messages, if getting success reports, the traffic 
could double, or more. Certainly putting it into metadata wouldn't be 
better in that case.

In any case, this is probably much less bandwidth that audio, much less 
video.

One question is whether it is necessary to record success reports. 
Leaving them out would help.

>>> Extending reports in some manner is a
>>> possibility.
>>
>> Yes, this is possible. But it would be nice to avoid modifying MSRP.
> Yeah, but might be lesser of evils

ISTM that we have a variety of extra stuff that we might need to send. 
So a consistent way to do so might be appropriate.

I think that one or more special content types would serve the purpose. 
And we wouldn't have to send those in CPIM wrappers. That would make it 
clear that they are "special".

In addition to Reports, there is a need to send indications when an MSRP 
send failed. And maybe to send a place holder for messages that exceed 
the max-size declared by the SRS.

>>>>> I think there is a problem with the text about adding a CPIM wrapper
>>>>> if there isn’t one.  I think the recording has to know if the
>>>>> original message was sent by some entity other than the one in the
>>>>> CPIM From (that is, we have to preserve the MSRP From).  The SRS has
>>>>> to know whether the original message had a CPIM header, and its
>>>>> contents.   If the SRC changes the message (by adding the wrapper) I
>>>>> think the SRS has to be able to figure that out, and record that fact
>>>>> in some way.
>>>>
>>>> I hear you, though I'm not yet convinced how important it is for the
>>>> SRS to be able to make this distinction.
>>> I think the recording is what the SRC got.  If you can’t effectively
>>> reproduce what the SRC gets, the mechanism is not adequate.
>>
>> Does introducing a CPIM wrapper where there was none (making explict what had been implicit) prevent reproducing what the SRC got?
> Because the SRS can’t distinguish between the SRC receiving a wrapped message from a case where the SRC did the wrapping on the RS.

And AFAICT it doesn't matter.

I will bring this up in Toronto.

>>>> If we only put CPIM wrappers on messages that don't already have them,
>>>> then we could put something *special* in them. But there would be no
>>>> guarantee that the CS didn't use that.
>>> There is always a way.  We can extend CPIM if we need to.
>>
>> Yes we could. If we feel that we must.
>>
>>>> We could also introduce a new mime type similar to CPIM, but specially
>>>> for recording. If we constrained the usage of that then we might be
>>>> able to claim that it could never appear on the CS. But I would prefer
>>>> to avoid this.
>>> I’d rather just extend CPIM
>>
>> This is a matter of taste. I could go either way. It would be nice to not have to extend CPIM.
> Something has to give.  Probably a good topic for the meeting

I looked at CPIM again. It has its own extensibility mechanism built in, 
that we could use. But it has a price. You have to declare the extension 
(with a URI) in every message where it is used. That is in addition to 
the extension header itself. So it will be expensive for passing what is 
fundamentally one bit of information.

I will bring this up in Toronto.

> The SRS has to be able to derive what was MSRP To/From in the CS was.  It’s recording what the SRC saw.

...

> I think the recording has to record what the SRC got.  I don’t think it’s good enough to derive a notion of session, create new session IDs and then just use them.  The recording has to be able to reproduce what the SRC saw.

I don't get it. The MSRP To/From are just artifacts. They aren't 
interesting in a recording.

If I wanted to "reenact" the session, I would expect that the new one 
would have different MSRP URIs. And that would not affect the fidelity 
of the reenactment.

I'll bring it up in Toronto - *what* we aim to capture in the recording, 
and what is not needed.

>> I went back to review the chat stuff that defines Nickname. (It still isn't an RFC!) I remembered wrong - the nickname isn't represented as a URI. Ideally we would manage it in-band in the MSRP. But the way nicknames are managed doesn't work very well for us. An msrp session is bound to at most one nickname at any point in time.
>>
>> We could work with that, sending NICKNAME requests on the RS msrp session as needed to set the nickname to match that of the message we want to send. But that would be unpleasant.
>>
>> An alternative would be to define the use of Use-Nickname with a SEND message. It currently isn't defined, but draft-ietf-simple-chat-18 leaves it open to be defined in the future.
>>
>> We would want to specify that the SRS will be especially lenient (promiscuous) in approving the use of nicknames.
> Hmmm, lots to think about.  Probably want to consult the chat authors.

I sent a query to the authors, and to the simple list (if anybody still 
on it), asking for them to please help with this. Will see if we get any 
response.

	Thanks,
	Paul


From nobody Mon Jul 14 09:27:41 2014
Return-Path: <andrew.hutton@unify.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767AF1A0AF5 for <siprec@ietfa.amsl.com>; Mon, 14 Jul 2014 09:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOZuNlkRnVRD for <siprec@ietfa.amsl.com>; Mon, 14 Jul 2014 09:27:26 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3551A0AD3 for <siprec@ietf.org>; Mon, 14 Jul 2014 09:27:26 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 2ED041EB8493 for <siprec@ietf.org>; Mon, 14 Jul 2014 18:27:25 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Mon, 14 Jul 2014 18:27:24 +0200
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: IETF90 SIPREC Meeting Agenda.
Thread-Index: Ac+fgHzEpDz9RcXUQP+kcIiIbzaaVg==
Date: Mon, 14 Jul 2014 16:27:24 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E23050@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/O5Bjj2-lpAhrji6QdfBhPLvr1dg
Subject: [siprec] IETF90 SIPREC Meeting Agenda.
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jul 2014 16:27:33 -0000

Hi All,

Today is the deadline for updating the agenda for IETF90 meetings.

So far regarding SIPREC we only have one request to present and that is on =
MSRP Recording (http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-=
01)

Our meeting is set for Friday, July 25th 2014, 11:50 - 13:20 GMT (Salon B)

The full agenda can be found at: https://datatracker.ietf.org/meeting/90/ag=
enda/siprec/

Regards
Andy


From nobody Sun Jul 20 10:37:39 2014
Return-Path: <saul@ag-projects.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5241B28F1 for <siprec@ietfa.amsl.com>; Sun, 20 Jul 2014 10:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.51
X-Spam-Level: *
X-Spam-Status: No, score=1.51 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh8kGjPa0sPj for <siprec@ietfa.amsl.com>; Sun, 20 Jul 2014 10:37:36 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id E6E581B28F0 for <siprec@ietf.org>; Sun, 20 Jul 2014 10:37:33 -0700 (PDT)
Received: from imac.saghul.lan (g154115.upc-g.chello.nl [80.57.154.115]) by mail.sipthor.net (Postfix) with ESMTPSA id 3794216DC719 for <siprec@ietf.org>; Sun, 20 Jul 2014 19:37:32 +0200 (CEST)
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_D17EBB4D-0FB8-487B-860B-E0484E544F43"; protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <1F3FB8A4-1EE7-45DA-9796-F0DF4AE5EF4F@ag-projects.com>
Date: Sun, 20 Jul 2014 19:37:47 +0200
To: siprec@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/b-yeK7GBL2XWAIl7T23_pevWFYc
Subject: [siprec] Feddback on draft-yan-siprec-msrp-recording-01
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jul 2014 17:37:38 -0000

--Apple-Mail=_D17EBB4D-0FB8-487B-860B-E0484E544F43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi all,

Paul recently asked if Icould have a look at this draft since I=92ve =
worked on some MSRP implementations and participated on some discussions =
over at SIMPLE, so here it goes :-)

Disclaimer: I=B4m not all that familiar with SIPREC and all prior =
discussions about this draft, so apologies if I guessed something =
incorrectly and / or repeated something.

1. Introduction

Some SIPREC related acronyms are expanded the first time they are used, =
but not all. It might help to do so at least the first time they are =
used. Is this what would go on Section 2?


3.1 MSRP Client acts as SRC

Is there any defined mechanism to notify an endpoint that the session is =
going to be recorded? If a client is going to act as a SRC then I guess =
it should add some indication to the SDP so the other endpoint can =
decide if she wants to maintain that chat conversation, knowing that it =
will be recorded. Now, if recording can be toggled on and off while in =
the middle of a session then some other mechanism might be necessary, =
perhaps a header in an empty SEND chunk?


3.2.  MSRP Relay acts as SRC

I see this section is still on the works. I think there are 2 separate =
cases: using an outbound relay and using an inbound one. A user may =
choose to use an outbound relay for recording purposes, in which case =
this would need to be signalled to the relay somehow. If the recipient =
of an INVITE needs to use an inbound relay for NAT traversal purposes, =
she might also be interested in recording the session.

As mentioned above, perhaps a header in the empty SEND chunk used to =
bind the session could be used to let the other endpoint know the =
session is going to be recorded.


4.  MSRP Media Stream Mixing

I think CPIM should me made a MUST here. There is no way to know who =
sent what (including the switch itself) unless CPIM is in use. Also, =
there would be no way to send private messages across a switch unless =
CPIM is used.

Also, not sure if as part of this draft or perhaps a new one, but the =
recording mechanism could also be used in reverse by the MSRP switch, to =
replay the conference history to new participants who join.


8. Recording Chatrooms

IMHO, if a chatroom record messages it should advertise so in the =
a=3Dchatroom attribute, i.e.: =93a=3Dchatroom:nickname private-messages
 siprec=94.


Again, this is the first time I come across SIPREC, so please take the =
above with a grain of salt.


Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




--Apple-Mail=_D17EBB4D-0FB8-487B-860B-E0484E544F43
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJTy/5rAAoJEN2cyH9ENwiqOrkP/ijLPaKUic9bdhiKL72z4sQe
gpahUyH+S9BDTOp+kEsXwjNGOnlc3XAHBCsuL2QChya/aZkNF3ZnG3Y2guYznsK8
U7hxF0U+OmPvf4YCyjoIIr+soKbQrcklKnDcKguvFWD9EtDO/o97e7xw4Gmp28fe
xtKXFhRrji1UX/qEicCliBrYgEuwgHVqyDqoVL3lSd83AM+KpJEF6nN9h9cDKIIC
B15TwfBMIyuT7KMiec/Z94JIoSaNN3cLCQLHsJMi4oCdr8J+Si3YitUFGDaH8MwQ
bfLC4KEHLRuCvlcnsigTf3JMLTbkuIBcH+sWSPV0JcB70JAU5eBeZBW9ANfBZ/YA
5tf0EBBzOlVVN3C85qb8jlAciMJscF4ZFpY/exCMHLyV3MAvef3EGFIPAnk91AC4
zAQPQM4LHueHgIzS5o5Jcqy6pREdiWBkvVNZyF6H0oIRDNBQI96GGqULxpOqvgLH
qBmR1m1ijAjpkL8avAGD6L9xmMrL93gwdiYxnwBLRFJRhrIkQf0bBN0TuWvWTSyv
bFOZ+bZh//nT4JAmmH1Jm2yBuuh0At/U8giePbuOz1sGcvJDnYlTn++DEFYW9G1n
BaBZXIf+B8zH3FmUV6/fW/pdD1C/e420FXJqvUqDAhbCa52AGrtT5r4lQ2xAA0GJ
jH346dFm5nwZsJOa6GxJ
=sUJB
-----END PGP SIGNATURE-----

--Apple-Mail=_D17EBB4D-0FB8-487B-860B-E0484E544F43--


From nobody Mon Jul 21 05:16:20 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AA11B2DDD; Mon, 21 Jul 2014 05:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-fGIvWs1nEX; Mon, 21 Jul 2014 05:16:14 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C3D1B2DD4; Mon, 21 Jul 2014 05:16:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140721121614.20217.405.idtracker@ietfa.amsl.com>
Date: Mon, 21 Jul 2014 05:16:14 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/iTeOBVYEX3NFE1dd1L_3PbkA2pc
Cc: siprec@ietf.org
Subject: [siprec] I-D Action: draft-ietf-siprec-callflows-03.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 12:16:15 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SIP Recording Working Group of the IETF.

        Title           : Session Initiation Protocol (SIP) Recording Call Flows
        Authors         : Ram Mohan Ravindranath
                          Parthasarathi Ravindran
                          Paul Kyzivat
	Filename        : draft-ietf-siprec-callflows-03.txt
	Pages           : 32
	Date            : 2014-07-21

Abstract:
   Session recording is a critical requirement in many communications
   environments such as call centers and financial trading.  In some of
   these environments, all calls must be recorded for regulatory,
   compliance, and consumer protection reasons.  Recording of a session
   is typically performed by sending a copy of a media stream to a
   recording device.  This document lists call flows that has snapshot
   of metadata sent from SRC to SRS, the metadata format for which is
   described in [I-D.ietf-siprec-metadata] .  This is purely an
   informational document that is written to support the model defined
   in the metadata draft.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-siprec-callflows/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-siprec-callflows-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-callflows-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jul 21 15:11:06 2014
Return-Path: <andrew.hutton@unify.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B7F1A0295 for <siprec@ietfa.amsl.com>; Mon, 21 Jul 2014 15:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RarLIn_4uacY for <siprec@ietfa.amsl.com>; Mon, 21 Jul 2014 15:11:01 -0700 (PDT)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 388CF1A0290 for <siprec@ietf.org>; Mon, 21 Jul 2014 15:11:01 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id CF0E023F0586; Tue, 22 Jul 2014 00:10:59 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 22 Jul 2014 00:10:59 +0200
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, "siprec@ietf.org" <siprec@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
Thread-Index: AQHPlvxNjHZ8hx4HoEuoLv/B3nK8sZuOrBIAgByGYcA=
Date: Mon, 21 Jul 2014 22:10:58 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E2E22F@MCHP04MSX.global-ad.net>
References: <20140703202010.10313.91660.idtracker@ietfa.amsl.com> <CFDB0A51.2D0DE%eckelcu@cisco.com>
In-Reply-To: <CFDB0A51.2D0DE%eckelcu@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/n3lIeHxEUTt9i-t9mfRhNJR8o2g
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 22:11:03 -0000

I reviewed the changes against the WGLC comments and the changes look ok to=
 me.

Andy



> -----Original Message-----
> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Charles
> Eckel (eckelcu)
> Sent: 03 July 2014 16:32
> To: siprec@ietf.org
> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
>=20
> This update addresses the FIR vs. SIP INFO issue as well as the WGLC
> comments. Please have a look and share any comments.
>=20
> Cheers,
> Charles
>=20
> On 7/3/14, 1:20 PM, "internet-drafts@ietf.org" <internet-
> drafts@ietf.org>
> wrote:
>=20
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> > This draft is a work item of the SIP Recording Working Group of the
> IETF.
> >
> >        Title           : Session Recording Protocol
> >        Authors         : Leon Portman
> >                          Henry Lum
> >                          Charles Eckel
> >                          Alan Johnston
> >                          Andrew Hutton
> >	Filename        : draft-ietf-siprec-protocol-13.txt
> >	Pages           : 42
> >	Date            : 2014-07-03
> >
> >Abstract:
> >   This document specifies the use of the Session Initiation Protocol
> >   (SIP), the Session Description Protocol (SDP), and the Real Time
> >   Protocol (RTP) for delivering real-time media and metadata from a
> >   Communication Session (CS) to a recording device.  The Session
> >   Recording Protocol specifies the use of SIP, SDP, and RTP to
> >   establish a Recording Session (RS) between the Session Recording
> >   Client (SRC), which is on the path of the CS, and a Session
> Recording
> >   Server (SRS) at the recording device.
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
> >
> >There's also a htmlized version available at:
> >http://tools.ietf.org/html/draft-ietf-siprec-protocol-13
> >
> >A diff from the previous version is available at:
> >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-13
> >
> >
> >Please note that it may take a couple of minutes from the time of
> >submission
> >until the htmlized version and diff are available at tools.ietf.org.
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >_______________________________________________
> >siprec mailing list
> >siprec@ietf.org
> >https://www.ietf.org/mailman/listinfo/siprec
>=20
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec


From nobody Mon Jul 21 15:25:13 2014
Return-Path: <eckelcu@cisco.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ECC1A02E1 for <siprec@ietfa.amsl.com>; Mon, 21 Jul 2014 15:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwj7nTYazHU4 for <siprec@ietfa.amsl.com>; Mon, 21 Jul 2014 15:25:09 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9621A006B for <siprec@ietf.org>; Mon, 21 Jul 2014 15:25:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3041; q=dns/txt; s=iport; t=1405981511; x=1407191111; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f2bZP6hCIhyq9wv+T0/CT0HSPFSpMpNz2y6xTRax2ww=; b=moGuNK/XfjOxN3B1vcfH//lYoT+1uUKIba4WUif1BmLufyW/AjLkY5Yi jI5v9tBcOV0O946bdtwc6QnAdkW39jU+0wwnEmfwXjTrWAVanSLx/gk97 IFzdLDrH3WzX+6CAFHvOnf3NZ/val8MPYgJLgnONpLNV3qHDLGhoGNMR9 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al0GAJKSzVOtJA2H/2dsb2JhbABZDoMAUlMEBMZwCoZyUwGBGhZ2hAMBAQEEAQEBNzQXBAIBCBEEAQEBHgkHJwsUCQgCBAESCYg5CAW/LBePUgaEQAWbJYFNkmKDAkJsgUU
X-IronPort-AV: E=Sophos;i="5.01,704,1400025600"; d="scan'208";a="341576564"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP; 21 Jul 2014 22:25:10 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6LMP84b007702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 22:25:08 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 17:25:08 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, "siprec@ietf.org" <siprec@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
Thread-Index: AQHPlvxNjHZ8hx4HoEuoLv/B3nK8sZuOrBIAgByGYcCAABW1AA==
Date: Mon, 21 Jul 2014 22:25:08 +0000
Message-ID: <CFF30A93.2F76F%eckelcu@cisco.com>
References: <20140703202010.10313.91660.idtracker@ietfa.amsl.com> <CFDB0A51.2D0DE%eckelcu@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF17E2E22F@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E2E22F@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.90.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <285DE7DCAEBB294AAB4613E41CF03796@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/D3AwnfO_IYS8WqYk_lkrmgVRMBo
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 22:25:11 -0000

Thanks Andy. I encourage others to take a look as well. If there are any
issues, it would be really convenient to address them this week while many
of us are here in Toronto.

Cheers,
Charles

On 7/21/14, 6:10 PM, "Hutton, Andrew" <andrew.hutton@unify.com> wrote:

>I reviewed the changes against the WGLC comments and the changes look ok
>to me.
>
>Andy
>
>
>
>> -----Original Message-----
>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Charles
>> Eckel (eckelcu)
>> Sent: 03 July 2014 16:32
>> To: siprec@ietf.org
>> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
>>=20
>> This update addresses the FIR vs. SIP INFO issue as well as the WGLC
>> comments. Please have a look and share any comments.
>>=20
>> Cheers,
>> Charles
>>=20
>> On 7/3/14, 1:20 PM, "internet-drafts@ietf.org" <internet-
>> drafts@ietf.org>
>> wrote:
>>=20
>> >
>> >A New Internet-Draft is available from the on-line Internet-Drafts
>> >directories.
>> > This draft is a work item of the SIP Recording Working Group of the
>> IETF.
>> >
>> >        Title           : Session Recording Protocol
>> >        Authors         : Leon Portman
>> >                          Henry Lum
>> >                          Charles Eckel
>> >                          Alan Johnston
>> >                          Andrew Hutton
>> >	Filename        : draft-ietf-siprec-protocol-13.txt
>> >	Pages           : 42
>> >	Date            : 2014-07-03
>> >
>> >Abstract:
>> >   This document specifies the use of the Session Initiation Protocol
>> >   (SIP), the Session Description Protocol (SDP), and the Real Time
>> >   Protocol (RTP) for delivering real-time media and metadata from a
>> >   Communication Session (CS) to a recording device.  The Session
>> >   Recording Protocol specifies the use of SIP, SDP, and RTP to
>> >   establish a Recording Session (RS) between the Session Recording
>> >   Client (SRC), which is on the path of the CS, and a Session
>> Recording
>> >   Server (SRS) at the recording device.
>> >
>> >
>> >The IETF datatracker status page for this draft is:
>> >https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
>> >
>> >There's also a htmlized version available at:
>> >http://tools.ietf.org/html/draft-ietf-siprec-protocol-13
>> >
>> >A diff from the previous version is available at:
>> >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-13
>> >
>> >
>> >Please note that it may take a couple of minutes from the time of
>> >submission
>> >until the htmlized version and diff are available at tools.ietf.org.
>> >
>> >Internet-Drafts are also available by anonymous FTP at:
>> >ftp://ftp.ietf.org/internet-drafts/
>> >
>> >_______________________________________________
>> >siprec mailing list
>> >siprec@ietf.org
>> >https://www.ietf.org/mailman/listinfo/siprec
>>=20
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec


From nobody Fri Jul 25 07:50:58 2014
Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04C41B29B1 for <siprec@ietfa.amsl.com>; Fri, 25 Jul 2014 07:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GDIIsLlxH3Y for <siprec@ietfa.amsl.com>; Fri, 25 Jul 2014 07:50:55 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F7F1B29AD for <siprec@ietf.org>; Fri, 25 Jul 2014 07:50:54 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id q58so4316613wes.18 for <siprec@ietf.org>; Fri, 25 Jul 2014 07:50:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=GvapcnLvj0Jbo/PO7b5zJEH/9pedQdOfr48xOCBVo50=; b=ShciBMULV7sSWFFMxLPShBgJYKMjGXhnEpvgWv4J0gOpdTCBbOJgDmhWJYAUColUR7 OhtYJhLpVytYbJbZxAI2jz0vM51pJK6ZFa14jJ5WWgwLyPDhczYdZhYWjofyv5B0DpmR Pv2imKAEMcLay/WMi1a+9DtpZbOeUdT0lOTZtdc9ksHcDqarH0bAmBn0C8dRu4E8AkUH +9wUysSKn8nKs7jq9kXtVBssUxh1e92dc8rXU2HLQmRJZ0p3IJSFYSE1ASoBjFcl3tzV ch86ZLCeKRiPUkTl1Wq6l7DTNID4qWdy/TwJ63k9B2XvIshb5rP4ScdqnLdP8zXUIcxp 4K+A==
MIME-Version: 1.0
X-Received: by 10.180.85.162 with SMTP id i2mr5814676wiz.53.1406299851904; Fri, 25 Jul 2014 07:50:51 -0700 (PDT)
Received: by 10.216.18.200 with HTTP; Fri, 25 Jul 2014 07:50:51 -0700 (PDT)
Date: Fri, 25 Jul 2014 09:50:51 -0500
Message-ID: <CAKhHsXF=UBNy+669j=FKRjV7Zf7zbYyvcF5tDn-163Y0u9CYSw@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Content-Type: multipart/alternative; boundary=f46d0444e9cb1f794f04ff05b336
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/Hv2ZiCJeDwXrENMkQnKrYPPT1mc
Subject: [siprec] Normative Statements in draft-ietf-siprec-protocol-13
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jul 2014 14:50:56 -0000

--f46d0444e9cb1f794f04ff05b336
Content-Type: text/plain; charset=UTF-8

Here's a few comments on some normative statements in
draft-ietf-siprec-protocol-13.

"In order to communicate most effectively, the Session Recording Client
(SRC), the Session Recording Server (SRS), and any Recording aware User
Agents (UAs) SHOULD utilize the mechanisms provided by RTP in a
well-defined and predicable manner."

I question whether this statement should have normative language, since it
isn't testable at all.

"Using the FIR command to recover from errors is explicitly disallowed, and
instead the PLI message SHOULD be used."

The use of "disallowed" seems like a MUST NOT, but then PLI is a SHOULD
which is confusing.  I'd suggest using normative language instead of
disallowed.

There are a bunch of normative statements that are repeated twice in
different sections.  For example:

"If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and
attempt to recover from the loss."

This statement appears in 8.2.2 and 8.2.3 for mixer and endpoint scenarios.
 There are similar things in 8.3.1 and 8.3.2.   Do we really want to repeat
this text?  If not, perhaps we could consolidate these two sections into
three:

- Section with normative statements that apply to both mixing and endpoint
- Section with normative for mixing only
- Section with normative for endpoint only

Or, if we do want to keep the existing structure, maybe the normative
statements could be prefixed with "For RTP mixing..." or "For RTP
endpoint..." so each normative statement is unique.

- Alan -

--f46d0444e9cb1f794f04ff05b336
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Here&#39;s a few comments on some normative statements in =
draft-ietf-siprec-protocol-13.<div><br></div><div><div>&quot;In order to co=
mmunicate most effectively, the Session Recording Client (SRC), the Session=
 Recording Server (SRS), and any Recording aware User Agents (UAs) SHOULD u=
tilize the mechanisms provided by RTP in a well-defined and predicable mann=
er.&quot;</div>
<div><br></div><div>I question whether this statement should have normative=
 language, since it isn&#39;t testable at all.</div><div><br></div><div>&qu=
ot;Using the FIR command to recover from errors is explicitly disallowed, a=
nd instead the PLI message SHOULD be used.&quot;</div>
<div><br></div><div>The use of &quot;disallowed&quot; seems like a MUST NOT=
, but then PLI is a SHOULD which is confusing. =C2=A0I&#39;d suggest using =
normative language instead of disallowed.</div><div><br></div><div>There ar=
e a bunch of normative statements that are repeated twice in different sect=
ions. =C2=A0For example:</div>
<div><br></div><div>&quot;If packet loss occurs from the UA to the SRC, the=
 SRC SHOULD detect and attempt to recover from the loss.&quot;=C2=A0</div><=
div><br></div><div>This statement appears in 8.2.2 and 8.2.3 for mixer and =
endpoint scenarios. =C2=A0There are similar things in 8.3.1 and 8.3.2. =C2=
=A0 Do we really want to repeat this text? =C2=A0If not, perhaps we could c=
onsolidate these two sections into three:</div>
<div><br></div><div>- Section with normative statements that apply to both =
mixing and endpoint</div><div>- Section with normative for mixing only</div=
><div>- Section with normative for endpoint only</div><div><br></div><div>
Or, if we do want to keep the existing structure, maybe the normative state=
ments could be prefixed with &quot;For RTP mixing...&quot; or &quot;For RTP=
 endpoint...&quot; so each normative statement is unique.</div><div><br>
</div><div>- Alan -</div><div><br></div><div><br></div><div><br></div></div=
></div>

--f46d0444e9cb1f794f04ff05b336--