From andrew.hutton@unify.com  Mon Feb  3 06:44:33 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 F00B61A0035 for <siprec@ietfa.amsl.com>; Mon,  3 Feb 2014 06:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.534
X-Spam-Level: 
X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 BC1u1qrdqrS1 for <siprec@ietfa.amsl.com>; Mon,  3 Feb 2014 06:44:31 -0800 (PST)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1041A002B for <siprec@ietf.org>; Mon,  3 Feb 2014 06:44:31 -0800 (PST)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id EBCBE23F04FF for <siprec@ietf.org>; Mon,  3 Feb 2014 15:44:30 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.100]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Mon, 3 Feb 2014 15:44:30 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: SIPREC IETF89 Meeting in London.
Thread-Index: Ac8g7nFoAcJQS01VTjWB+CwWU8Xf3Q==
Date: Mon, 3 Feb 2014 14:44:30 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17CE2D41@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_9F33F40F6F2CD847824537F3C4E37DDF17CE2D41MCHP04MSXglobal_"
MIME-Version: 1.0
Subject: [siprec] SIPREC IETF89 Meeting in London.
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, 03 Feb 2014 14:44:33 -0000

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

Hi All,

If you would like agenda time in the SIPREC meeting at IETF89 please e-mail=
 the chairs (siprec-chairs@tools.ietf.org) .

SIPREC has been allocated the dreaded final meeting slot in the DRAFT agend=
a on Friday March the 7th (See https://datatracker.ietf.org/meeting/89/agen=
da.html).

Of course the draft agenda can change so don't make plans based on this.

Regards
Andy (SIPREC Co-Chair).


--_000_9F33F40F6F2CD847824537F3C4E37DDF17CE2D41MCHP04MSXglobal_
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>If you would like agenda time in the SIPREC meeting at IETF89 please e=
-mail the chairs (siprec-chairs@tools.ietf.org) .</div>
<div>&nbsp;</div>
<div>SIPREC has been allocated the dreaded final meeting slot in the <b>DRA=
FT</b> agenda on Friday March the 7<font size=3D"1"><span style=3D"font-siz=
e:7.3pt;"><sup>th</sup></span></font> (See <a href=3D"https://datatracker.i=
etf.org/meeting/89/agenda.html"><font color=3D"blue"><u>https://datatracker=
.ietf.org/meeting/89/agenda.html</u></font></a>).</div>
<div>&nbsp;</div>
<div>Of course the draft agenda can change so don&#8217;t make plans based =
on this.</div>
<div><font color=3D"#2A3136">&nbsp;</font></div>
<div><font face=3D"Arial" size=3D"2" color=3D"#2A3136"><span style=3D"font-=
size:9pt;"><b>Regards</b></span></font></div>
<div><font face=3D"Arial" size=3D"2" color=3D"#2A3136"><span style=3D"font-=
size:9pt;"><b>Andy (SIPREC Co-Chair).</b></span></font></div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_9F33F40F6F2CD847824537F3C4E37DDF17CE2D41MCHP04MSXglobal_--

From partha@parthasarathi.co.in  Thu Feb  6 08:51:23 2014
Return-Path: <partha@parthasarathi.co.in>
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 C2C5E1A0426; Thu,  6 Feb 2014 08:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] 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 BVolrR65g9Ph; Thu,  6 Feb 2014 08:51:22 -0800 (PST)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.234]) by ietfa.amsl.com (Postfix) with ESMTP id C52661A0434; Thu,  6 Feb 2014 08:51:19 -0800 (PST)
Received: from userPC (unknown [122.166.182.79]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 2DE89639140; Thu,  6 Feb 2014 16:51:12 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1391705478; bh=4kwcp91q7+Gyh8VMzBLoBEmcUYsI+93jdmnj6rpkgrE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Iy1q9QfHuB9DzpT4s8+JNGa/irX3lRutteUat4fNCiw2xxhP4jbI4g6tx6A2lEdqe j4QlowHTMfZBy6am51AfEP8mb64iVEMlaN+oNQGdImTZkBxtOu2ze4dmrCQIznAI3x IWaiv9n6JS8wlWklEvolhstjFSlacjvYolsOXg8k=
From: "Parthasarathi R" <partha@parthasarathi.co.in>
To: "'Ram Mohan R \(rmohanr\)'" <rmohanr@cisco.com>, "'Gerben Stam'" <Gerben.Stam@nice.com>
References: <CF199D4B.7A6E4%rmohanr@cisco.com> <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <CF19B110.7A78A%rmohanr@cisco.com>
In-Reply-To: <CF19B110.7A78A%rmohanr@cisco.com>
Date: Thu, 6 Feb 2014 22:21:06 +0530
Message-ID: <00dd01cf235b$a5401470$efc03d50$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHPI1dDJyXBrcc2c0ma7EaQoC0IX5qobTRg
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020201.52F3BD86.012C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Cc: siprec@ietf.org, dispatch@ietf.org
Subject: Re: [siprec] [dispatch] Lossless Recording in SIPREC
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, 06 Feb 2014 16:51:24 -0000

Hi Gerben,

I agree with Ram that lossless recording is within SIPREC requirement as =
mentioned in RFC 6341. Apart from REQ-5 in RFC 6341, some of the text =
related to High availability is mentioned in the note of this mail.

Also, the lossless recording shall be achieved by multiple means. One of =
the mechanism is explained in draft-ietf-avtext-rtp-duplication-04. IMO, =
let us discuss in SIPREC about the specific technical issue in lossless =
recording which is not possible to be achieved through the existing =
mechanism=20

Including SIPREC mailing alias in this mail thread.

Thanks
Partha

Note:

 Use Case 10: High availability and continuous recording.

      Specific deployment scenarios present different requirements for
      system availability, error handling, etc., including the
      following:

      o  An SRS must always be available at call setup time.

      o  No loss of media recording can occur, including during failure
         of an SRS.

      o  The Communication Session must be terminated (or suitable
         notification given to parties) in the event of a recording
         failure.


REQ-021: The mechanism MUST NOT prevent high-availability
      deployments.=20

> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram
> Mohan R (rmohanr)
> Sent: Thursday, February 06, 2014 9:50 PM
> To: Gerben Stam
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>=20
> Hi,
>=20
> Please see inline
>=20
> -----Original Message-----
> From: Gerben Stam <Gerben.Stam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@cisco.com>
> Cc: "dispatch@ietf.org" <dispatch@ietf.org>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>=20
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of the
> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a good
> >topic to discuss in the team.
>=20
> Ok. I was not aware of this.
>=20
> >
> >What would I need to do to bend this to SIPREC WG instead of =
Dispatch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatch@ietf.org
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch =
and
> >not in SIPREC WG which is meant to discuss the issues around SIP
> >recording ?
> >If you don=C2=B9t have any specific reason to do it here you may want =
to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <Gerben.Stam@nice.com>
> >Cc:  "dispatch@ietf.org" <dispatch@ietf.org>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >Dear DISPATCH group,
> >
> >SIPREC is a great initiative to standardize the interface for
> capturing
> >Communication Sessions.
> >Session Recording is becoming more and more critical due to =
Compliance
> >and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these days
> >Confirmation is needed to acknowledge the entire Communication =
Session
> >was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of RTP
> >content.
> >
> >
> >
> >New requirement is =C5=92lossless=C2=B9 Session Capturing.
>=20
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already
> has
> a requirement for Lossless recording. See REQ 005.
>=20
>=20
> >Lossless indicating handover of content (RTP) is acknowledged by the
> >receiver AND in case of receiving issues, the sender will resend.
> >Reasons for loss may be UDP packet loss or receiver failing(over) and
> >temporary not able to accept content.
> >Current approach to address this =C5=92lossless=C2=B9 requirement is =
using 2
> >independent parallel receivers.
>=20
> There may be other approaches well. For example an SRC may buffer for =
a
> small duration to take care of the loss. Two parallel receivers still
> does
> not guarantee that recording is loseless as you can have UDP packet
> loss
> on both paths.
>=20
> >
> >This requires the sender to send 2 individual streams, in fact 2
> >independent SIPREC sessions.
> >
> >Not sure if this is covered currently as supported SIPREC deployment.
>=20
>=20
> Current SIPREC does not have any such constraints. Depending on your
> implementation model you can have the same CS recorded by multiple SRC
> or
> have same SRC do multiple recordings of same CS.
>=20
> Regards,
> Ram
>=20
> > We do see implementations based on SIPREC supporting it.
> >Alternative is quick failover at receiver in case of failure but as
> >sender will send only once, this may lead to loss during failover.
> >
> >I am not aware of any rfc covering lossless content handover, but
> there
> >may be standards covering this already.
> >
> >
> >Looking forward to discussion on the mailing list. I may be at the
> London
> >event.
> >
> >Regards,
> >
> >Gerben Stam,
> >NICE Systems
> >
> >
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From mary.ietf.barnes@gmail.com  Thu Feb  6 09:12:18 2014
Return-Path: <mary.ietf.barnes@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 276F31A03F2; Thu,  6 Feb 2014 09:12:18 -0800 (PST)
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 jIwwbF7Z4D0L; Thu,  6 Feb 2014 09:12:13 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 927E91A03E1; Thu,  6 Feb 2014 09:12:13 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id lx4so838048iec.13 for <multiple recipients>; Thu, 06 Feb 2014 09:12:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iaUOFBbOtP1LCDT54dZqhbl/gMtjjCahEdBECaBOe3M=; b=yeJCOfzBDSXMjkBR1bYO2GmSsIAJgvFbTlZTDTLdMMF1LzUvN137L6Dd3TeZIXOuwU m4w+uw2Nn1fuYQE77TkuPLyhm+GSXSKYRBTtipPXTWVbV6JRnaqD1s8ixVPRm66v7HZP xNckyfola82e2sPK/hP+V1E7J75bL8hIE5/9IYJDAJUlOBq96nKiDDWMNZ/mG/W7+me7 MOnCl6OgHatZa6Rvb4SEFSD6R2zuMBmytQ0jQUIzcKKhGJw2O0+wFLjw/9t4cJoZMUIu li66cQUYr8FXBeFyhUAn1m7q04cN3rEZl3ZWwGWR56JATQxynfwIItKfmXu2msNsBQv9 pJDA==
MIME-Version: 1.0
X-Received: by 10.50.114.4 with SMTP id jc4mr822953igb.0.1391706722913; Thu, 06 Feb 2014 09:12:02 -0800 (PST)
Received: by 10.43.58.137 with HTTP; Thu, 6 Feb 2014 09:12:02 -0800 (PST)
In-Reply-To: <00dd01cf235b$a5401470$efc03d50$@co.in>
References: <CF199D4B.7A6E4%rmohanr@cisco.com> <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <CF19B110.7A78A%rmohanr@cisco.com> <00dd01cf235b$a5401470$efc03d50$@co.in>
Date: Thu, 6 Feb 2014 11:12:02 -0600
Message-ID: <CAHBDyN7u+Ck2JCPz4GciHh0kkbzW++xacYWzYeu0w+Kcd+Hpww@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Parthasarathi R <partha@parthasarathi.co.in>
Content-Type: multipart/alternative; boundary=047d7b2e0983da759104f1bff830
Cc: Gerben Stam <Gerben.Stam@nice.com>, "siprec@ietf.org" <siprec@ietf.org>, DISPATCH <dispatch@ietf.org>
Subject: Re: [siprec] [dispatch] Lossless Recording in SIPREC
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, 06 Feb 2014 17:12:18 -0000

--047d7b2e0983da759104f1bff830
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Please don't cross post as that makes it a nightmare for people who like to
put emails for various WGs in separate folders.  The IETF email system is
setup to avoid duplicates and also people are not subscribed always to both
lists and that results in messages in moderator queues.

It is a good idea however to post a note to the SIPREC mailing list that
this discussion is happening on the DISPATCH WG mailing list - including a
link to the discussion thread.

Thanks,
Mary.


On Thu, Feb 6, 2014 at 10:51 AM, Parthasarathi R <partha@parthasarathi.co.i=
n
> wrote:

> Hi Gerben,
>
> I agree with Ram that lossless recording is within SIPREC requirement as
> mentioned in RFC 6341. Apart from REQ-5 in RFC 6341, some of the text
> related to High availability is mentioned in the note of this mail.
>
> Also, the lossless recording shall be achieved by multiple means. One of
> the mechanism is explained in draft-ietf-avtext-rtp-duplication-04. IMO,
> let us discuss in SIPREC about the specific technical issue in lossless
> recording which is not possible to be achieved through the existing
> mechanism
>
> Including SIPREC mailing alias in this mail thread.
>
> Thanks
> Partha
>
> Note:
>
>  Use Case 10: High availability and continuous recording.
>
>       Specific deployment scenarios present different requirements for
>       system availability, error handling, etc., including the
>       following:
>
>       o  An SRS must always be available at call setup time.
>
>       o  No loss of media recording can occur, including during failure
>          of an SRS.
>
>       o  The Communication Session must be terminated (or suitable
>          notification given to parties) in the event of a recording
>          failure.
>
>
> REQ-021: The mechanism MUST NOT prevent high-availability
>       deployments.
>
> > -----Original Message-----
> > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram
> > Mohan R (rmohanr)
> > Sent: Thursday, February 06, 2014 9:50 PM
> > To: Gerben Stam
> > Cc: dispatch@ietf.org
> > Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> > Hi,
> >
> > Please see inline
> >
> > -----Original Message-----
> > From: Gerben Stam <Gerben.Stam@nice.com>
> > Date: Thursday, 6 February 2014 8:40 pm
> > To: Cisco Employee <rmohanr@cisco.com>
> > Cc: "dispatch@ietf.org" <dispatch@ietf.org>
> > Subject: RE: [dispatch] Lossless Recording in SIPREC
> >
> > >Hey Ram,
> > >
> > >I have had an off-line discussion with Andrew Hutton, chairman of the
> > >SIPREC group.
> > >He suggested to post this on the IETF dispatch group as it is a good
> > >topic to discuss in the team.
> >
> > Ok. I was not aware of this.
> >
> > >
> > >What would I need to do to bend this to SIPREC WG instead of Dispatch?
> > >
> > >Regards,
> > >
> > >Gerben
> > >
> > >-----Original Message-----
> > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> > >Sent: donderdag 6 februari 2014 15:45
> > >To: Gerben Stam
> > >Cc: dispatch@ietf.org
> > >Subject: Re: [dispatch] Lossless Recording in SIPREC
> > >
> > >Hi,
> > >
> > >Is there a reason why you want to have this discussion in dispatch and
> > >not in SIPREC WG which is meant to discuss the issues around SIP
> > >recording ?
> > >If you don=B9t have any specific reason to do it here you may want to
> > start
> > >this discussion in SIPREC WG.
> > >
> > >I do have some comments on this topic but I think SIPREC WG is the
> > right
> > >place to have those discussions.
> > >
> > >
> > >Regards,
> > >Ram
> > >
> > >From:  Gerben Stam <Gerben.Stam@nice.com>
> > >Date:  Thursday, 6 February 2014 3:58 pm
> > >To:  Gerben Stam <Gerben.Stam@nice.com>
> > >Cc:  "dispatch@ietf.org" <dispatch@ietf.org>
> > >Subject:  [dispatch] Lossless Recording in SIPREC
> > >
> > >
> > >Dear DISPATCH group,
> > >
> > >SIPREC is a great initiative to standardize the interface for
> > capturing
> > >Communication Sessions.
> > >Session Recording is becoming more and more critical due to Compliance
> > >and regulatory changes over the last years.
> > >
> > >The compliance market is requesting more than capture only these days
> > >Confirmation is needed to acknowledge the entire Communication Session
> > >was captured correctly.
> > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP
> > >content.
> > >
> > >
> > >
> > >New requirement is OElossless=B9 Session Capturing.
> >
> > Why is this a new requirement ? RFC 6341 (SIPREC requirements) already
> > has
> > a requirement for Lossless recording. See REQ 005.
> >
> >
> > >Lossless indicating handover of content (RTP) is acknowledged by the
> > >receiver AND in case of receiving issues, the sender will resend.
> > >Reasons for loss may be UDP packet loss or receiver failing(over) and
> > >temporary not able to accept content.
> > >Current approach to address this OElossless=B9 requirement is using 2
> > >independent parallel receivers.
> >
> > There may be other approaches well. For example an SRC may buffer for a
> > small duration to take care of the loss. Two parallel receivers still
> > does
> > not guarantee that recording is loseless as you can have UDP packet
> > loss
> > on both paths.
> >
> > >
> > >This requires the sender to send 2 individual streams, in fact 2
> > >independent SIPREC sessions.
> > >
> > >Not sure if this is covered currently as supported SIPREC deployment.
> >
> >
> > Current SIPREC does not have any such constraints. Depending on your
> > implementation model you can have the same CS recorded by multiple SRC
> > or
> > have same SRC do multiple recordings of same CS.
> >
> > Regards,
> > Ram
> >
> > > We do see implementations based on SIPREC supporting it.
> > >Alternative is quick failover at receiver in case of failure but as
> > >sender will send only once, this may lead to loss during failover.
> > >
> > >I am not aware of any rfc covering lossless content handover, but
> > there
> > >may be standards covering this already.
> > >
> > >
> > >Looking forward to discussion on the mailing list. I may be at the
> > London
> > >event.
> > >
> > >Regards,
> > >
> > >Gerben Stam,
> > >NICE Systems
> > >
> > >
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>

--047d7b2e0983da759104f1bff830
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Please don&#39;t cross post as that makes it a nightmare f=
or people who like to put emails for various WGs in separate folders. &nbsp=
;The IETF email system is setup to avoid duplicates and also people are not=
 subscribed always to both lists and that results in messages in moderator =
queues.<div>
<br></div><div>It is a good idea however to post a note to the SIPREC maili=
ng list that this discussion is happening on the DISPATCH WG mailing list -=
 including a link to the discussion thread.</div><div><br></div><div>Thanks=
,</div>
<div>Mary.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">On Thu, Feb 6, 2014 at 10:51 AM, Parthasarathi R <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:partha@parthasarathi.co.in" target=3D"_blank">partha=
@parthasarathi.co.in</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi Gerben,<br>
<br>
I agree with Ram that lossless recording is within SIPREC requirement as me=
ntioned in RFC 6341. Apart from REQ-5 in RFC 6341, some of the text related=
 to High availability is mentioned in the note of this mail.<br>
<br>
Also, the lossless recording shall be achieved by multiple means. One of th=
e mechanism is explained in draft-ietf-avtext-rtp-duplication-04. IMO, let =
us discuss in SIPREC about the specific technical issue in lossless recordi=
ng which is not possible to be achieved through the existing mechanism<br>

<br>
Including SIPREC mailing alias in this mail thread.<br>
<br>
Thanks<br>
Partha<br>
<br>
Note:<br>
<br>
&nbsp;Use Case 10: High availability and continuous recording.<br>
<br>
&nbsp; &nbsp; &nbsp; Specific deployment scenarios present different requir=
ements for<br>
&nbsp; &nbsp; &nbsp; system availability, error handling, etc., including t=
he<br>
&nbsp; &nbsp; &nbsp; following:<br>
<br>
&nbsp; &nbsp; &nbsp; o &nbsp;An SRS must always be available at call setup =
time.<br>
<br>
&nbsp; &nbsp; &nbsp; o &nbsp;No loss of media recording can occur, includin=
g during failure<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;of an SRS.<br>
<br>
&nbsp; &nbsp; &nbsp; o &nbsp;The Communication Session must be terminated (=
or suitable<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;notification given to parties) in the eve=
nt of a recording<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;failure.<br>
<br>
<br>
REQ-021: The mechanism MUST NOT prevent high-availability<br>
&nbsp; &nbsp; &nbsp; deployments.<br>
<div><div class=3D"h5"><br>
&gt; -----Original Message-----<br>
&gt; From: dispatch [mailto:<a href=3D"mailto:dispatch-bounces@ietf.org">di=
spatch-bounces@ietf.org</a>] On Behalf Of Ram<br>
&gt; Mohan R (rmohanr)<br>
&gt; Sent: Thursday, February 06, 2014 9:50 PM<br>
&gt; To: Gerben Stam<br>
&gt; Cc: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; Subject: Re: [dispatch] Lossless Recording in SIPREC<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; Please see inline<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: Gerben Stam &lt;<a href=3D"mailto:Gerben.Stam@nice.com">Gerben.S=
tam@nice.com</a>&gt;<br>
&gt; Date: Thursday, 6 February 2014 8:40 pm<br>
&gt; To: Cisco Employee &lt;<a href=3D"mailto:rmohanr@cisco.com">rmohanr@ci=
sco.com</a>&gt;<br>
&gt; Cc: &quot;<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a>&q=
uot; &lt;<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a>&gt;<br>
&gt; Subject: RE: [dispatch] Lossless Recording in SIPREC<br>
&gt;<br>
&gt; &gt;Hey Ram,<br>
&gt; &gt;<br>
&gt; &gt;I have had an off-line discussion with Andrew Hutton, chairman of =
the<br>
&gt; &gt;SIPREC group.<br>
&gt; &gt;He suggested to post this on the IETF dispatch group as it is a go=
od<br>
&gt; &gt;topic to discuss in the team.<br>
&gt;<br>
&gt; Ok. I was not aware of this.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;What would I need to do to bend this to SIPREC WG instead of Dispa=
tch?<br>
&gt; &gt;<br>
&gt; &gt;Regards,<br>
&gt; &gt;<br>
&gt; &gt;Gerben<br>
&gt; &gt;<br>
&gt; &gt;-----Original Message-----<br>
&gt; &gt;From: Ram Mohan R (rmohanr) [mailto:<a href=3D"mailto:rmohanr@cisc=
o.com">rmohanr@cisco.com</a>]<br>
&gt; &gt;Sent: donderdag 6 februari 2014 15:45<br>
&gt; &gt;To: Gerben Stam<br>
&gt; &gt;Cc: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; &gt;Subject: Re: [dispatch] Lossless Recording in SIPREC<br>
&gt; &gt;<br>
&gt; &gt;Hi,<br>
&gt; &gt;<br>
&gt; &gt;Is there a reason why you want to have this discussion in dispatch=
 and<br>
&gt; &gt;not in SIPREC WG which is meant to discuss the issues around SIP<b=
r>
&gt; &gt;recording ?<br>
&gt; &gt;If you don=B9t have any specific reason to do it here you may want=
 to<br>
&gt; start<br>
&gt; &gt;this discussion in SIPREC WG.<br>
&gt; &gt;<br>
&gt; &gt;I do have some comments on this topic but I think SIPREC WG is the=
<br>
&gt; right<br>
&gt; &gt;place to have those discussions.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;Regards,<br>
&gt; &gt;Ram<br>
&gt; &gt;<br>
&gt; &gt;From: &nbsp;Gerben Stam &lt;<a href=3D"mailto:Gerben.Stam@nice.com=
">Gerben.Stam@nice.com</a>&gt;<br>
&gt; &gt;Date: &nbsp;Thursday, 6 February 2014 3:58 pm<br>
&gt; &gt;To: &nbsp;Gerben Stam &lt;<a href=3D"mailto:Gerben.Stam@nice.com">=
Gerben.Stam@nice.com</a>&gt;<br>
&gt; &gt;Cc: &nbsp;&quot;<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf=
.org</a>&quot; &lt;<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</=
a>&gt;<br>
&gt; &gt;Subject: &nbsp;[dispatch] Lossless Recording in SIPREC<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;Dear DISPATCH group,<br>
&gt; &gt;<br>
&gt; &gt;SIPREC is a great initiative to standardize the interface for<br>
&gt; capturing<br>
&gt; &gt;Communication Sessions.<br>
&gt; &gt;Session Recording is becoming more and more critical due to Compli=
ance<br>
&gt; &gt;and regulatory changes over the last years.<br>
&gt; &gt;<br>
&gt; &gt;The compliance market is requesting more than capture only these d=
ays<br>
&gt; &gt;Confirmation is needed to acknowledge the entire Communication Ses=
sion<br>
&gt; &gt;was captured correctly.<br>
&gt; &gt;RTCP Reports (rfc3611) will help to confirm complete handover of R=
TP<br>
&gt; &gt;content.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;New requirement is &OElig;lossless=B9 Session Capturing.<br>
&gt;<br>
&gt; Why is this a new requirement ? RFC 6341 (SIPREC requirements) already=
<br>
&gt; has<br>
&gt; a requirement for Lossless recording. See REQ 005.<br>
&gt;<br>
&gt;<br>
&gt; &gt;Lossless indicating handover of content (RTP) is acknowledged by t=
he<br>
&gt; &gt;receiver AND in case of receiving issues, the sender will resend.<=
br>
&gt; &gt;Reasons for loss may be UDP packet loss or receiver failing(over) =
and<br>
&gt; &gt;temporary not able to accept content.<br>
&gt; &gt;Current approach to address this &OElig;lossless=B9 requirement is=
 using 2<br>
&gt; &gt;independent parallel receivers.<br>
&gt;<br>
&gt; There may be other approaches well. For example an SRC may buffer for =
a<br>
&gt; small duration to take care of the loss. Two parallel receivers still<=
br>
&gt; does<br>
&gt; not guarantee that recording is loseless as you can have UDP packet<br=
>
&gt; loss<br>
&gt; on both paths.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;This requires the sender to send 2 individual streams, in fact 2<b=
r>
&gt; &gt;independent SIPREC sessions.<br>
&gt; &gt;<br>
&gt; &gt;Not sure if this is covered currently as supported SIPREC deployme=
nt.<br>
&gt;<br>
&gt;<br>
&gt; Current SIPREC does not have any such constraints. Depending on your<b=
r>
&gt; implementation model you can have the same CS recorded by multiple SRC=
<br>
&gt; or<br>
&gt; have same SRC do multiple recordings of same CS.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Ram<br>
&gt;<br>
&gt; &gt; We do see implementations based on SIPREC supporting it.<br>
&gt; &gt;Alternative is quick failover at receiver in case of failure but a=
s<br>
&gt; &gt;sender will send only once, this may lead to loss during failover.=
<br>
&gt; &gt;<br>
&gt; &gt;I am not aware of any rfc covering lossless content handover, but<=
br>
&gt; there<br>
&gt; &gt;may be standards covering this already.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;Looking forward to discussion on the mailing list. I may be at the=
<br>
&gt; London<br>
&gt; &gt;event.<br>
&gt; &gt;<br>
&gt; &gt;Regards,<br>
&gt; &gt;<br>
&gt; &gt;Gerben Stam,<br>
&gt; &gt;NICE Systems<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dispatch mailing list<br>
&gt; <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_=
blank">https://www.ietf.org/mailman/listinfo/dispatch</a><br>
<br>
</div></div>_______________________________________________<br>
siprec mailing list<br>
<a href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/siprec" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/siprec</a><br>
</blockquote></div><br></div>

--047d7b2e0983da759104f1bff830--

From Gerben.Stam@nice.com  Fri Feb  7 01:05:50 2014
Return-Path: <Gerben.Stam@nice.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 D8C101A05E0 for <siprec@ietfa.amsl.com>; Fri,  7 Feb 2014 01:05:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 wfnMXAy8w2LB for <siprec@ietfa.amsl.com>; Fri,  7 Feb 2014 01:05:49 -0800 (PST)
Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4078A1A00AE for <siprec@ietf.org>; Fri,  7 Feb 2014 01:05:47 -0800 (PST)
Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Feb 2014 09:05:03 +0000
Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Fri, 7 Feb 2014 09:05:03 +0000
From: Gerben Stam <Gerben.Stam@nice.com>
To: Parthasarathi R <partha@parthasarathi.co.in>, "'Ram Mohan R (rmohanr)'" <rmohanr@cisco.com>
Date: Fri, 7 Feb 2014 09:04:57 +0000
Thread-Topic: [dispatch] Lossless Recording in SIPREC
Thread-Index: AQHPI1dDJyXBrcc2c0ma7EaQoC0IX5qobTRggAEOSSA=
Message-ID: <4BEAD79F6904AC4FB1917EBA8006628905C0685ED5@SOUEXC01.eu.nice.com>
References: <CF199D4B.7A6E4%rmohanr@cisco.com> <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <CF19B110.7A78A%rmohanr@cisco.com> <00dd01cf235b$a5401470$efc03d50$@co.in>
In-Reply-To: <00dd01cf235b$a5401470$efc03d50$@co.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Feb 2014 09:05:03.0953 (UTC) FILETIME=[B04EB410:01CF23E3]
X-Mailman-Approved-At: Fri, 07 Feb 2014 02:00:57 -0800
Cc: "siprec@ietf.org" <siprec@ietf.org>
Subject: Re: [siprec] [dispatch] Lossless Recording in SIPREC
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, 07 Feb 2014 09:05:51 -0000

SGkgUGFydGhhIGFuZCBSYW0sDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIG9uIExvc3NsZXNz
LCBJIHdpbGwgY2hlY2sgdGhlIHJmYydzIHlvdSBpbmRpY2F0ZWQgYW5kIGdldCBiYWNrIG9uIHBv
dGVudGlhbCBnYXBzIGluIGxvc3NsZXNzIHJlY29yZGluZyByZXF1aXJlbWVudHMuDQpTbyBmYXIg
SSBoYXZlIG5ldmVyIHNlZW4gbG9zc2xlc3MgaW1wbGVtZW50YXRpb24gY29tYmluZWQgd2l0aCBT
SVBSRUMgYXBhcnQgZnJvbSBIQSAob3B0aW9ucyBwaW5nKS4NCg0KQmUgYXdhcmUgdGhhdCBsb3Nz
bGVzcyBpcyBub3Qgb25seSB0byBjb3ZlciBwYWNrZXQgbG9zcyBpbiBVRFAgdHJhbnNtaXNzaW9u
IChsaWtlIEZFQyBpcyBhZGRpdGlvbmFsIHBhcml0eSBibG9ja3MgdG8gY292ZXIgcGFja2V0IGxv
c3MpLg0KQWxzbyB0aGUgZmFjdCB0aGUgU1JTIG1heSBub3QgYmUgcmVhZHkgdG8gcmVjZWl2ZSB3
b3VsZCBuZWVkIHRvIHRyaWdnZXIgdGhlIFNSQyB0byBidWZmZXIgYXVkaW8uDQpBZ2FpbiBJIHdp
bGwgY2hlY2sgdGhlIHN1Z2dlc3RlZCBleGlzdGluZyBzdGFuZGFyZHMgLg0KDQpSZWdhcmRzLA0K
DQpHZXJiZW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkaXNwYXRj
aCBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXJ0aGFz
YXJhdGhpIFINClNlbnQ6IGRvbmRlcmRhZyA2IGZlYnJ1YXJpIDIwMTQgMTc6NTENClRvOiAnUmFt
IE1vaGFuIFIgKHJtb2hhbnIpJzsgR2VyYmVuIFN0YW0NCkNjOiBzaXByZWNAaWV0Zi5vcmc7IGRp
c3BhdGNoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBMb3NzbGVzcyBSZWNvcmRp
bmcgaW4gU0lQUkVDDQoNCkhpIEdlcmJlbiwNCg0KSSBhZ3JlZSB3aXRoIFJhbSB0aGF0IGxvc3Ns
ZXNzIHJlY29yZGluZyBpcyB3aXRoaW4gU0lQUkVDIHJlcXVpcmVtZW50IGFzIG1lbnRpb25lZCBp
biBSRkMgNjM0MS4gQXBhcnQgZnJvbSBSRVEtNSBpbiBSRkMgNjM0MSwgc29tZSBvZiB0aGUgdGV4
dCByZWxhdGVkIHRvIEhpZ2ggYXZhaWxhYmlsaXR5IGlzIG1lbnRpb25lZCBpbiB0aGUgbm90ZSBv
ZiB0aGlzIG1haWwuDQoNCkFsc28sIHRoZSBsb3NzbGVzcyByZWNvcmRpbmcgc2hhbGwgYmUgYWNo
aWV2ZWQgYnkgbXVsdGlwbGUgbWVhbnMuIE9uZSBvZiB0aGUgbWVjaGFuaXNtIGlzIGV4cGxhaW5l
ZCBpbiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZHVwbGljYXRpb24tMDQuIElNTywgbGV0IHVzIGRp
c2N1c3MgaW4gU0lQUkVDIGFib3V0IHRoZSBzcGVjaWZpYyB0ZWNobmljYWwgaXNzdWUgaW4gbG9z
c2xlc3MgcmVjb3JkaW5nIHdoaWNoIGlzIG5vdCBwb3NzaWJsZSB0byBiZSBhY2hpZXZlZCB0aHJv
dWdoIHRoZSBleGlzdGluZyBtZWNoYW5pc20gDQoNCkluY2x1ZGluZyBTSVBSRUMgbWFpbGluZyBh
bGlhcyBpbiB0aGlzIG1haWwgdGhyZWFkLg0KDQpUaGFua3MNClBhcnRoYQ0KDQpOb3RlOg0KDQog
VXNlIENhc2UgMTA6IEhpZ2ggYXZhaWxhYmlsaXR5IGFuZCBjb250aW51b3VzIHJlY29yZGluZy4N
Cg0KICAgICAgU3BlY2lmaWMgZGVwbG95bWVudCBzY2VuYXJpb3MgcHJlc2VudCBkaWZmZXJlbnQg
cmVxdWlyZW1lbnRzIGZvcg0KICAgICAgc3lzdGVtIGF2YWlsYWJpbGl0eSwgZXJyb3IgaGFuZGxp
bmcsIGV0Yy4sIGluY2x1ZGluZyB0aGUNCiAgICAgIGZvbGxvd2luZzoNCg0KICAgICAgbyAgQW4g
U1JTIG11c3QgYWx3YXlzIGJlIGF2YWlsYWJsZSBhdCBjYWxsIHNldHVwIHRpbWUuDQoNCiAgICAg
IG8gIE5vIGxvc3Mgb2YgbWVkaWEgcmVjb3JkaW5nIGNhbiBvY2N1ciwgaW5jbHVkaW5nIGR1cmlu
ZyBmYWlsdXJlDQogICAgICAgICBvZiBhbiBTUlMuDQoNCiAgICAgIG8gIFRoZSBDb21tdW5pY2F0
aW9uIFNlc3Npb24gbXVzdCBiZSB0ZXJtaW5hdGVkIChvciBzdWl0YWJsZQ0KICAgICAgICAgbm90
aWZpY2F0aW9uIGdpdmVuIHRvIHBhcnRpZXMpIGluIHRoZSBldmVudCBvZiBhIHJlY29yZGluZw0K
ICAgICAgICAgZmFpbHVyZS4NCg0KDQpSRVEtMDIxOiBUaGUgbWVjaGFuaXNtIE1VU1QgTk9UIHBy
ZXZlbnQgaGlnaC1hdmFpbGFiaWxpdHkNCiAgICAgIGRlcGxveW1lbnRzLiANCg0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkaXNwYXRjaCBbbWFpbHRvOmRpc3BhdGNoLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSYW0gDQo+IE1vaGFuIFIgKHJtb2hhbnIpDQo+
IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA5OjUwIFBNDQo+IFRvOiBHZXJiZW4g
U3RhbQ0KPiBDYzogZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkaXNwYXRjaF0g
TG9zc2xlc3MgUmVjb3JkaW5nIGluIFNJUFJFQw0KPiANCj4gSGksDQo+IA0KPiBQbGVhc2Ugc2Vl
IGlubGluZQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogR2VyYmVu
IFN0YW0gPEdlcmJlbi5TdGFtQG5pY2UuY29tPg0KPiBEYXRlOiBUaHVyc2RheSwgNiBGZWJydWFy
eSAyMDE0IDg6NDAgcG0NCj4gVG86IENpc2NvIEVtcGxveWVlIDxybW9oYW5yQGNpc2NvLmNvbT4N
Cj4gQ2M6ICJkaXNwYXRjaEBpZXRmLm9yZyIgPGRpc3BhdGNoQGlldGYub3JnPg0KPiBTdWJqZWN0
OiBSRTogW2Rpc3BhdGNoXSBMb3NzbGVzcyBSZWNvcmRpbmcgaW4gU0lQUkVDDQo+IA0KPiA+SGV5
IFJhbSwNCj4gPg0KPiA+SSBoYXZlIGhhZCBhbiBvZmYtbGluZSBkaXNjdXNzaW9uIHdpdGggQW5k
cmV3IEh1dHRvbiwgY2hhaXJtYW4gb2YgdGhlIA0KPiA+U0lQUkVDIGdyb3VwLg0KPiA+SGUgc3Vn
Z2VzdGVkIHRvIHBvc3QgdGhpcyBvbiB0aGUgSUVURiBkaXNwYXRjaCBncm91cCBhcyBpdCBpcyBh
IGdvb2QgDQo+ID50b3BpYyB0byBkaXNjdXNzIGluIHRoZSB0ZWFtLg0KPiANCj4gT2suIEkgd2Fz
IG5vdCBhd2FyZSBvZiB0aGlzLg0KPiANCj4gPg0KPiA+V2hhdCB3b3VsZCBJIG5lZWQgdG8gZG8g
dG8gYmVuZCB0aGlzIHRvIFNJUFJFQyBXRyBpbnN0ZWFkIG9mIERpc3BhdGNoPw0KPiA+DQo+ID5S
ZWdhcmRzLA0KPiA+DQo+ID5HZXJiZW4NCj4gPg0KPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gPkZyb206IFJhbSBNb2hhbiBSIChybW9oYW5yKSBbbWFpbHRvOnJtb2hhbnJAY2lzY28u
Y29tXQ0KPiA+U2VudDogZG9uZGVyZGFnIDYgZmVicnVhcmkgMjAxNCAxNTo0NQ0KPiA+VG86IEdl
cmJlbiBTdGFtDQo+ID5DYzogZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gPlN1YmplY3Q6IFJlOiBbZGlz
cGF0Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBTSVBSRUMNCj4gPg0KPiA+SGksDQo+ID4NCj4g
PklzIHRoZXJlIGEgcmVhc29uIHdoeSB5b3Ugd2FudCB0byBoYXZlIHRoaXMgZGlzY3Vzc2lvbiBp
biBkaXNwYXRjaCANCj4gPmFuZCBub3QgaW4gU0lQUkVDIFdHIHdoaWNoIGlzIG1lYW50IHRvIGRp
c2N1c3MgdGhlIGlzc3VlcyBhcm91bmQgU0lQIA0KPiA+cmVjb3JkaW5nID8NCj4gPklmIHlvdSBk
b27CuXQgaGF2ZSBhbnkgc3BlY2lmaWMgcmVhc29uIHRvIGRvIGl0IGhlcmUgeW91IG1heSB3YW50
IHRvDQo+IHN0YXJ0DQo+ID50aGlzIGRpc2N1c3Npb24gaW4gU0lQUkVDIFdHLg0KPiA+DQo+ID5J
IGRvIGhhdmUgc29tZSBjb21tZW50cyBvbiB0aGlzIHRvcGljIGJ1dCBJIHRoaW5rIFNJUFJFQyBX
RyBpcyB0aGUNCj4gcmlnaHQNCj4gPnBsYWNlIHRvIGhhdmUgdGhvc2UgZGlzY3Vzc2lvbnMuDQo+
ID4NCj4gPg0KPiA+UmVnYXJkcywNCj4gPlJhbQ0KPiA+DQo+ID5Gcm9tOiAgR2VyYmVuIFN0YW0g
PEdlcmJlbi5TdGFtQG5pY2UuY29tPg0KPiA+RGF0ZTogIFRodXJzZGF5LCA2IEZlYnJ1YXJ5IDIw
MTQgMzo1OCBwbQ0KPiA+VG86ICBHZXJiZW4gU3RhbSA8R2VyYmVuLlN0YW1AbmljZS5jb20+DQo+
ID5DYzogICJkaXNwYXRjaEBpZXRmLm9yZyIgPGRpc3BhdGNoQGlldGYub3JnPg0KPiA+U3ViamVj
dDogIFtkaXNwYXRjaF0gTG9zc2xlc3MgUmVjb3JkaW5nIGluIFNJUFJFQw0KPiA+DQo+ID4NCj4g
PkRlYXIgRElTUEFUQ0ggZ3JvdXAsDQo+ID4NCj4gPlNJUFJFQyBpcyBhIGdyZWF0IGluaXRpYXRp
dmUgdG8gc3RhbmRhcmRpemUgdGhlIGludGVyZmFjZSBmb3INCj4gY2FwdHVyaW5nDQo+ID5Db21t
dW5pY2F0aW9uIFNlc3Npb25zLg0KPiA+U2Vzc2lvbiBSZWNvcmRpbmcgaXMgYmVjb21pbmcgbW9y
ZSBhbmQgbW9yZSBjcml0aWNhbCBkdWUgdG8gDQo+ID5Db21wbGlhbmNlIGFuZCByZWd1bGF0b3J5
IGNoYW5nZXMgb3ZlciB0aGUgbGFzdCB5ZWFycy4NCj4gPg0KPiA+VGhlIGNvbXBsaWFuY2UgbWFy
a2V0IGlzIHJlcXVlc3RpbmcgbW9yZSB0aGFuIGNhcHR1cmUgb25seSB0aGVzZSBkYXlzIA0KPiA+
Q29uZmlybWF0aW9uIGlzIG5lZWRlZCB0byBhY2tub3dsZWRnZSB0aGUgZW50aXJlIENvbW11bmlj
YXRpb24gDQo+ID5TZXNzaW9uIHdhcyBjYXB0dXJlZCBjb3JyZWN0bHkuDQo+ID5SVENQIFJlcG9y
dHMgKHJmYzM2MTEpIHdpbGwgaGVscCB0byBjb25maXJtIGNvbXBsZXRlIGhhbmRvdmVyIG9mIFJU
UCANCj4gPmNvbnRlbnQuDQo+ID4NCj4gPg0KPiA+DQo+ID5OZXcgcmVxdWlyZW1lbnQgaXMgxZJs
b3NzbGVzc8K5IFNlc3Npb24gQ2FwdHVyaW5nLg0KPiANCj4gV2h5IGlzIHRoaXMgYSBuZXcgcmVx
dWlyZW1lbnQgPyBSRkMgNjM0MSAoU0lQUkVDIHJlcXVpcmVtZW50cykgYWxyZWFkeSANCj4gaGFz
IGEgcmVxdWlyZW1lbnQgZm9yIExvc3NsZXNzIHJlY29yZGluZy4gU2VlIFJFUSAwMDUuDQo+IA0K
PiANCj4gPkxvc3NsZXNzIGluZGljYXRpbmcgaGFuZG92ZXIgb2YgY29udGVudCAoUlRQKSBpcyBh
Y2tub3dsZWRnZWQgYnkgdGhlIA0KPiA+cmVjZWl2ZXIgQU5EIGluIGNhc2Ugb2YgcmVjZWl2aW5n
IGlzc3VlcywgdGhlIHNlbmRlciB3aWxsIHJlc2VuZC4NCj4gPlJlYXNvbnMgZm9yIGxvc3MgbWF5
IGJlIFVEUCBwYWNrZXQgbG9zcyBvciByZWNlaXZlciBmYWlsaW5nKG92ZXIpIGFuZCANCj4gPnRl
bXBvcmFyeSBub3QgYWJsZSB0byBhY2NlcHQgY29udGVudC4NCj4gPkN1cnJlbnQgYXBwcm9hY2gg
dG8gYWRkcmVzcyB0aGlzIMWSbG9zc2xlc3PCuSByZXF1aXJlbWVudCBpcyB1c2luZyAyIA0KPiA+
aW5kZXBlbmRlbnQgcGFyYWxsZWwgcmVjZWl2ZXJzLg0KPiANCj4gVGhlcmUgbWF5IGJlIG90aGVy
IGFwcHJvYWNoZXMgd2VsbC4gRm9yIGV4YW1wbGUgYW4gU1JDIG1heSBidWZmZXIgZm9yIA0KPiBh
IHNtYWxsIGR1cmF0aW9uIHRvIHRha2UgY2FyZSBvZiB0aGUgbG9zcy4gVHdvIHBhcmFsbGVsIHJl
Y2VpdmVycyANCj4gc3RpbGwgZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgcmVjb3JkaW5nIGlzIGxv
c2VsZXNzIGFzIHlvdSBjYW4gaGF2ZSANCj4gVURQIHBhY2tldCBsb3NzIG9uIGJvdGggcGF0aHMu
DQo+IA0KPiA+DQo+ID5UaGlzIHJlcXVpcmVzIHRoZSBzZW5kZXIgdG8gc2VuZCAyIGluZGl2aWR1
YWwgc3RyZWFtcywgaW4gZmFjdCAyIA0KPiA+aW5kZXBlbmRlbnQgU0lQUkVDIHNlc3Npb25zLg0K
PiA+DQo+ID5Ob3Qgc3VyZSBpZiB0aGlzIGlzIGNvdmVyZWQgY3VycmVudGx5IGFzIHN1cHBvcnRl
ZCBTSVBSRUMgZGVwbG95bWVudC4NCj4gDQo+IA0KPiBDdXJyZW50IFNJUFJFQyBkb2VzIG5vdCBo
YXZlIGFueSBzdWNoIGNvbnN0cmFpbnRzLiBEZXBlbmRpbmcgb24geW91ciANCj4gaW1wbGVtZW50
YXRpb24gbW9kZWwgeW91IGNhbiBoYXZlIHRoZSBzYW1lIENTIHJlY29yZGVkIGJ5IG11bHRpcGxl
IFNSQyANCj4gb3IgaGF2ZSBzYW1lIFNSQyBkbyBtdWx0aXBsZSByZWNvcmRpbmdzIG9mIHNhbWUg
Q1MuDQo+IA0KPiBSZWdhcmRzLA0KPiBSYW0NCj4gDQo+ID4gV2UgZG8gc2VlIGltcGxlbWVudGF0
aW9ucyBiYXNlZCBvbiBTSVBSRUMgc3VwcG9ydGluZyBpdC4NCj4gPkFsdGVybmF0aXZlIGlzIHF1
aWNrIGZhaWxvdmVyIGF0IHJlY2VpdmVyIGluIGNhc2Ugb2YgZmFpbHVyZSBidXQgYXMgDQo+ID5z
ZW5kZXIgd2lsbCBzZW5kIG9ubHkgb25jZSwgdGhpcyBtYXkgbGVhZCB0byBsb3NzIGR1cmluZyBm
YWlsb3Zlci4NCj4gPg0KPiA+SSBhbSBub3QgYXdhcmUgb2YgYW55IHJmYyBjb3ZlcmluZyBsb3Nz
bGVzcyBjb250ZW50IGhhbmRvdmVyLCBidXQNCj4gdGhlcmUNCj4gPm1heSBiZSBzdGFuZGFyZHMg
Y292ZXJpbmcgdGhpcyBhbHJlYWR5Lg0KPiA+DQo+ID4NCj4gPkxvb2tpbmcgZm9yd2FyZCB0byBk
aXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QuIEkgbWF5IGJlIGF0IHRoZQ0KPiBMb25kb24N
Cj4gPmV2ZW50Lg0KPiA+DQo+ID5SZWdhcmRzLA0KPiA+DQo+ID5HZXJiZW4gU3RhbSwNCj4gPk5J
Q0UgU3lzdGVtcw0KPiA+DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBp
ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNo
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNw
YXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo=

From Gerben.Stam@nice.com  Fri Feb  7 05:57:51 2014
Return-Path: <Gerben.Stam@nice.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 2C3951A03C3 for <siprec@ietfa.amsl.com>; Fri,  7 Feb 2014 05:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.835
X-Spam-Level: 
X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.535] 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 I1pDIBejtGgT for <siprec@ietfa.amsl.com>; Fri,  7 Feb 2014 05:57:48 -0800 (PST)
Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5B01E1A00F6 for <siprec@ietf.org>; Fri,  7 Feb 2014 05:57:48 -0800 (PST)
Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Feb 2014 13:56:21 +0000
Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Fri, 7 Feb 2014 13:56:21 +0000
From: Gerben Stam <Gerben.Stam@nice.com>
To: Parthasarathi R <partha@parthasarathi.co.in>, "'Ram Mohan R (rmohanr)'" <rmohanr@cisco.com>
Date: Fri, 7 Feb 2014 13:56:19 +0000
Thread-Topic: [dispatch] Lossless Recording in SIPREC
Thread-Index: AQHPI1dDJyXBrcc2c0ma7EaQoC0IX5qobTRggAEOSSCAAD3w8A==
Message-ID: <4BEAD79F6904AC4FB1917EBA8006628905C068613B@SOUEXC01.eu.nice.com>
References: <CF199D4B.7A6E4%rmohanr@cisco.com> <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <CF19B110.7A78A%rmohanr@cisco.com> <00dd01cf235b$a5401470$efc03d50$@co.in> <0D3A16BBDECB2C4BB2DF22F87BB87374089E2F29A9@SOUEXC01.eu.nice.com>
In-Reply-To: <0D3A16BBDECB2C4BB2DF22F87BB87374089E2F29A9@SOUEXC01.eu.nice.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Feb 2014 13:56:21.0852 (UTC) FILETIME=[61F271C0:01CF240C]
Cc: Gerben Stam <Gerben.Stam@nice.com>, "siprec@ietf.org" <siprec@ietf.org>
Subject: Re: [siprec] [dispatch] Lossless Recording in SIPREC
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, 07 Feb 2014 13:57:51 -0000

SGV5IGd1eXMsDQoNCkkgaGF2ZSBoYWQgYSBsb29rIGF0IExvc3NsZXNzIHN0YXRlbWVudHMgaW4g
U0lQUkVDIG5vdyAoVXNlcyBDYXNlIDEwIGFuZCBSRVEtMDIxKS4NCkNvbnRyb2wgc3RhcnQgb2Yg
UlRQIHRoZSBtb21lbnQgd2Ugc3RhdGUgYT1zZW5kb25seSBpbiB0aGUgU0RQLg0KVGhpcyBpcyB0
byBjb3ZlciBSUyBzdGFydCBkZWxheSBkdWUgdG8gbGF0ZSBhY2NlcHRhbmNlIGJ5IFNSUywgYnVm
ZmVyaW5nIG9uIHRoZSBTUkMuIEl0IGRvZXMgbm8gY292ZXIgbWlkIFJTIGxvc3Mgb2YgUlRQLg0K
DQpkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZHVwbGljYXRpb24tMDQNCkV4cGxhaW5zIGR1YWwgUlRQ
IHN0cmVhbXMgc2VuZCBieSBTUlMgd2l0aCBvd24gU1NSQy9TUlRQIGtleWluZyBhbmQgZXZlbiBS
VENQLiBVc2luZyBhPXNzcmMtZ3JvdXA6RFVQIDEwMDAgMTAxMC4NClN0cmVhbXMgY2FuIHRha2Ug
c2VwYXJhdGUgbmV0d29yayByb3V0ZXMgdG8gY292ZXIgVURQIHBhY2tldCBsb3NzIGluIHRoZSBu
ZXR3b3JrLg0KQXQgdGhlIFNSUyBzaWRlIHdlIG5lZWQgdG8gY3JlYXRlIHNpbmdsZSByZWNvcmRp
bmcgZnJvbSB0aGUgY29tYmluZWQgc3RyZWFtcyBhbmQgZmlsbCBwb3RlbnRpYWwgUlRQIGdhcHMg
YnkgdGhlIG90aGVyIFJUUCBzdHJlYW0uDQpUaGlzIGlzIHRvIGNvdmVyIFVEUCBwYWNrZXQgbG9z
cyBvciBldmVuIHN0cmVhbSBsb3NzIGluIHRoZSBuZXR3b3JrLg0KDQpJc3N1ZSBub3QgYWRkcmVz
c2VkIHN0aWxsIGlzIHdoYXQgdG8gZG8gaWYgU1JTIGdvZXMgZG93biBtaWQgU1IgYW5kIG5lZWRz
IHRvIGZhaWxvdmVyIChIQSkuDQpCZWZvcmUgdGhlIG91dGFnZSBpcyBkZXRlY3RlZCBieSBTUkMs
IGl0IHdvdWxkIGhhdmUgc2VuZCBSVFAgZm9yIHRoZSBSUywgd2hpY2ggd2FzIG5vdCByZWNlaXZl
ZCBieSBTUlMuDQpSVENQIHJlcG9ydHMgbWF5IG5vdGlmeSB0aGUgbG9zcyBhdCBTUkMgKGF0IGxl
YXN0IGlmIFNSQyBzZW5kcyByZWNlaXZlciByZXBvcnRzIHRvIFNSUykuDQpXaWxsIFJUQ1AgYWxz
byBzdXBwb3J0IHJlLXNlbmRpbmcgYSBjZXJ0YWluIFJUUCBwYWNrZXQgaWYgdGhlIFNSUyBkaWQg
bm90IHJlY2VpdmUgaXQ/IA0KDQpUaGlzIG1heSBsb29rIGxpa2UgYSB0cml2aWFsIGlzc3VlIGFz
IGZvciBlYWNoIG5ldyBDUyBhIG5ldyBTSVAgaW52aXRlIGlzIHNlbmQsIHdoaWNoIGlzIHRydWUg
Zm9yIElQVCAoUGhvbmUpIGVudmlyb25tZW50cy4NCkluIHRyYWRpbmcgcmVjb3JkaW5nIGhvd2V2
ZXIsIGEgQ1MgbGFzdHMgZnJvbSB0aGUgdGltZSB0aGUgVHJhZGVyIGxvZydzIG9uIHRpbGwgaGUg
bG9nJ3Mgb2ZmLiBTbyBhbGwgZGF5Lg0KV2l0aGluIHRoaXMgdmVyeSBsb25nIFNJUCBzZXNzaW9u
LCBtdWx0aXBsZSBSUyBhcmUgdHJpZ2dlcmVkIGVhY2ggd2l0aCBpdHMgTWV0YS4gDQpTU1JDIG1h
eSBzdGF5IGJ1dCBSVFAgaGFzIFZBRCAoYWN0aXZpdHkgZGV0ZWN0aW9uLCBubyBSVFAgc2VuZCBp
ZiBubyBSUykNCldpdGggY3VycmVudCBzdHJpY3QgcmVndWxhdGlvbiwgYW55IGxvc3Mgb2YgcmVj
b3JkaW5nIG5lZWRzIHRvIGJlIHJlcG9ydGVkLiBSVENQIGhlbHBzIGF0IFNSQy4NClN0aWxsIHJl
IHJlcXVpcmVtZW50IGJ5IHRoZSBpbmR1c3RyeSBpcyBtb3ZpbmcgdG93YXJkcyBsb3NzbGVzcy4g
TWFpbmx5IGFja25vd2xlZGdlIFJUUCByZWNlaXZlZCBhbmQgYWJpbGl0eSB0byByZS1zZW5kIGV2
ZW4gbWlkIFJTIGJ5IFNSQy4NCg0KZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWR1cGxpY2F0aW9uLTA0
IG1heSBoZWxwIGJ1dCB0aGF0IHdpbGwgcmVxdWlyZSB0byBjYXB0dXJlIGR1cGxpY2F0ZSBSVFAg
c3RyZWFtcyBvbiBpbmRpdmlkdWFsIFJUUCBsb2dnZXJzLg0KSWYgb25lIFJUUCBsb2dnZXIgd291
bGQgZmFpbCwgQ1MgY29udGludWVzIG9uIG90aGVyIGxvZ2dlci4NClNSQyB3b3VsZCBuZWVkIHRv
IHJlLWludml0ZSBhbiB1cGRhdGUgdGhlIFJUUCBkZXN0aW5hdGlvbiBmb3IgdGhlIGZhaWxpbmcg
UlRQIExvZ2dlciB0byByZS1kaXJlY3QgdGhlIHN0cmVhbSB0byBhbm90aGVyIG5vZGUuDQpUaGF0
IHdvdWxkIGNvdmVyIG1pZCBTUiBSVFAgTG9nZ2VyIG91dGFnZSwgYnV0IHdpbGwgcmFpc2UgY29t
cGxleGl0eSBhdCB0aGUgUlNDIHNpZGUuIA0KU3RpbGwgYW4gb3B0aW9uIHRvdWdoIHdlIG1heSBh
ZHZpY2UgdG8gY3JlYXRlICdsb3NzbGVzcycuDQpkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZHVwbGlj
YXRpb24tMDQgaXMgbW9yZSB0YWlsb3JlZCB0byBjb3ZlciBkdWFsIFJUUCByb3V0ZXMgKGFuZCBk
dWFsIE5JQykgYmV0d2VlbiBzaW5nZSBTUkMgYW5kIFNSUy4NCg0KV2hhdCBkbyB5b3UgdGhpbms/
DQoNCkdlcmJlbg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBH
ZXJiZW4gU3RhbSANClNlbnQ6IHZyaWpkYWcgNyBmZWJydWFyaSAyMDE0IDEwOjA1DQpUbzogJ1Bh
cnRoYXNhcmF0aGkgUic7ICdSYW0gTW9oYW4gUiAocm1vaGFuciknDQpDYzogc2lwcmVjQGlldGYu
b3JnDQpTdWJqZWN0OiBSRTogW2Rpc3BhdGNoXSBMb3NzbGVzcyBSZWNvcmRpbmcgaW4gU0lQUkVD
DQoNCkhpIFBhcnRoYSBhbmQgUmFtLA0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjayBvbiBMb3Nz
bGVzcywgSSB3aWxsIGNoZWNrIHRoZSByZmMncyB5b3UgaW5kaWNhdGVkIGFuZCBnZXQgYmFjayBv
biBwb3RlbnRpYWwgZ2FwcyBpbiBsb3NzbGVzcyByZWNvcmRpbmcgcmVxdWlyZW1lbnRzLg0KU28g
ZmFyIEkgaGF2ZSBuZXZlciBzZWVuIGxvc3NsZXNzIGltcGxlbWVudGF0aW9uIGNvbWJpbmVkIHdp
dGggU0lQUkVDIGFwYXJ0IGZyb20gSEEgKG9wdGlvbnMgcGluZykuDQoNCkJlIGF3YXJlIHRoYXQg
bG9zc2xlc3MgaXMgbm90IG9ubHkgdG8gY292ZXIgcGFja2V0IGxvc3MgaW4gVURQIHRyYW5zbWlz
c2lvbiAobGlrZSBGRUMgaXMgYWRkaXRpb25hbCBwYXJpdHkgYmxvY2tzIHRvIGNvdmVyIHBhY2tl
dCBsb3NzKS4NCkFsc28gdGhlIGZhY3QgdGhlIFNSUyBtYXkgbm90IGJlIHJlYWR5IHRvIHJlY2Vp
dmUgd291bGQgbmVlZCB0byB0cmlnZ2VyIHRoZSBTUkMgdG8gYnVmZmVyIGF1ZGlvLg0KQWdhaW4g
SSB3aWxsIGNoZWNrIHRoZSBzdWdnZXN0ZWQgZXhpc3Rpbmcgc3RhbmRhcmRzIC4NCg0KUmVnYXJk
cywNCg0KR2VyYmVuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGlz
cGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGFy
dGhhc2FyYXRoaSBSDQpTZW50OiBkb25kZXJkYWcgNiBmZWJydWFyaSAyMDE0IDE3OjUxDQpUbzog
J1JhbSBNb2hhbiBSIChybW9oYW5yKSc7IEdlcmJlbiBTdGFtDQpDYzogc2lwcmVjQGlldGYub3Jn
OyBkaXNwYXRjaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gTG9zc2xlc3MgUmVj
b3JkaW5nIGluIFNJUFJFQw0KDQpIaSBHZXJiZW4sDQoNCkkgYWdyZWUgd2l0aCBSYW0gdGhhdCBs
b3NzbGVzcyByZWNvcmRpbmcgaXMgd2l0aGluIFNJUFJFQyByZXF1aXJlbWVudCBhcyBtZW50aW9u
ZWQgaW4gUkZDIDYzNDEuIEFwYXJ0IGZyb20gUkVRLTUgaW4gUkZDIDYzNDEsIHNvbWUgb2YgdGhl
IHRleHQgcmVsYXRlZCB0byBIaWdoIGF2YWlsYWJpbGl0eSBpcyBtZW50aW9uZWQgaW4gdGhlIG5v
dGUgb2YgdGhpcyBtYWlsLg0KDQpBbHNvLCB0aGUgbG9zc2xlc3MgcmVjb3JkaW5nIHNoYWxsIGJl
IGFjaGlldmVkIGJ5IG11bHRpcGxlIG1lYW5zLiBPbmUgb2YgdGhlIG1lY2hhbmlzbSBpcyBleHBs
YWluZWQgaW4gZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWR1cGxpY2F0aW9uLTA0LiBJTU8sIGxldCB1
cyBkaXNjdXNzIGluIFNJUFJFQyBhYm91dCB0aGUgc3BlY2lmaWMgdGVjaG5pY2FsIGlzc3VlIGlu
IGxvc3NsZXNzIHJlY29yZGluZyB3aGljaCBpcyBub3QgcG9zc2libGUgdG8gYmUgYWNoaWV2ZWQg
dGhyb3VnaCB0aGUgZXhpc3RpbmcgbWVjaGFuaXNtIA0KDQpJbmNsdWRpbmcgU0lQUkVDIG1haWxp
bmcgYWxpYXMgaW4gdGhpcyBtYWlsIHRocmVhZC4NCg0KVGhhbmtzDQpQYXJ0aGENCg0KTm90ZToN
Cg0KIFVzZSBDYXNlIDEwOiBIaWdoIGF2YWlsYWJpbGl0eSBhbmQgY29udGludW91cyByZWNvcmRp
bmcuDQoNCiAgICAgIFNwZWNpZmljIGRlcGxveW1lbnQgc2NlbmFyaW9zIHByZXNlbnQgZGlmZmVy
ZW50IHJlcXVpcmVtZW50cyBmb3INCiAgICAgIHN5c3RlbSBhdmFpbGFiaWxpdHksIGVycm9yIGhh
bmRsaW5nLCBldGMuLCBpbmNsdWRpbmcgdGhlDQogICAgICBmb2xsb3dpbmc6DQoNCiAgICAgIG8g
IEFuIFNSUyBtdXN0IGFsd2F5cyBiZSBhdmFpbGFibGUgYXQgY2FsbCBzZXR1cCB0aW1lLg0KDQog
ICAgICBvICBObyBsb3NzIG9mIG1lZGlhIHJlY29yZGluZyBjYW4gb2NjdXIsIGluY2x1ZGluZyBk
dXJpbmcgZmFpbHVyZQ0KICAgICAgICAgb2YgYW4gU1JTLg0KDQogICAgICBvICBUaGUgQ29tbXVu
aWNhdGlvbiBTZXNzaW9uIG11c3QgYmUgdGVybWluYXRlZCAob3Igc3VpdGFibGUNCiAgICAgICAg
IG5vdGlmaWNhdGlvbiBnaXZlbiB0byBwYXJ0aWVzKSBpbiB0aGUgZXZlbnQgb2YgYSByZWNvcmRp
bmcNCiAgICAgICAgIGZhaWx1cmUuDQoNCg0KUkVRLTAyMTogVGhlIG1lY2hhbmlzbSBNVVNUIE5P
VCBwcmV2ZW50IGhpZ2gtYXZhaWxhYmlsaXR5DQogICAgICBkZXBsb3ltZW50cy4gDQoNCj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRj
aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFtIA0KPiBNb2hhbiBSIChybW9oYW5y
KQ0KPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgOTo1MCBQTQ0KPiBUbzogR2Vy
YmVuIFN0YW0NCj4gQ2M6IGRpc3BhdGNoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbZGlzcGF0
Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBTSVBSRUMNCj4gDQo+IEhpLA0KPiANCj4gUGxlYXNl
IHNlZSBpbmxpbmUNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdl
cmJlbiBTdGFtIDxHZXJiZW4uU3RhbUBuaWNlLmNvbT4NCj4gRGF0ZTogVGh1cnNkYXksIDYgRmVi
cnVhcnkgMjAxNCA4OjQwIHBtDQo+IFRvOiBDaXNjbyBFbXBsb3llZSA8cm1vaGFuckBjaXNjby5j
b20+DQo+IENjOiAiZGlzcGF0Y2hAaWV0Zi5vcmciIDxkaXNwYXRjaEBpZXRmLm9yZz4NCj4gU3Vi
amVjdDogUkU6IFtkaXNwYXRjaF0gTG9zc2xlc3MgUmVjb3JkaW5nIGluIFNJUFJFQw0KPiANCj4g
PkhleSBSYW0sDQo+ID4NCj4gPkkgaGF2ZSBoYWQgYW4gb2ZmLWxpbmUgZGlzY3Vzc2lvbiB3aXRo
IEFuZHJldyBIdXR0b24sIGNoYWlybWFuIG9mIHRoZSANCj4gPlNJUFJFQyBncm91cC4NCj4gPkhl
IHN1Z2dlc3RlZCB0byBwb3N0IHRoaXMgb24gdGhlIElFVEYgZGlzcGF0Y2ggZ3JvdXAgYXMgaXQg
aXMgYSBnb29kIA0KPiA+dG9waWMgdG8gZGlzY3VzcyBpbiB0aGUgdGVhbS4NCj4gDQo+IE9rLiBJ
IHdhcyBub3QgYXdhcmUgb2YgdGhpcy4NCj4gDQo+ID4NCj4gPldoYXQgd291bGQgSSBuZWVkIHRv
IGRvIHRvIGJlbmQgdGhpcyB0byBTSVBSRUMgV0cgaW5zdGVhZCBvZiBEaXNwYXRjaD8NCj4gPg0K
PiA+UmVnYXJkcywNCj4gPg0KPiA+R2VyYmVuDQo+ID4NCj4gPi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+ID5Gcm9tOiBSYW0gTW9oYW4gUiAocm1vaGFucikgW21haWx0bzpybW9oYW5yQGNp
c2NvLmNvbV0NCj4gPlNlbnQ6IGRvbmRlcmRhZyA2IGZlYnJ1YXJpIDIwMTQgMTU6NDUNCj4gPlRv
OiBHZXJiZW4gU3RhbQ0KPiA+Q2M6IGRpc3BhdGNoQGlldGYub3JnDQo+ID5TdWJqZWN0OiBSZTog
W2Rpc3BhdGNoXSBMb3NzbGVzcyBSZWNvcmRpbmcgaW4gU0lQUkVDDQo+ID4NCj4gPkhpLA0KPiA+
DQo+ID5JcyB0aGVyZSBhIHJlYXNvbiB3aHkgeW91IHdhbnQgdG8gaGF2ZSB0aGlzIGRpc2N1c3Np
b24gaW4gZGlzcGF0Y2ggDQo+ID5hbmQgbm90IGluIFNJUFJFQyBXRyB3aGljaCBpcyBtZWFudCB0
byBkaXNjdXNzIHRoZSBpc3N1ZXMgYXJvdW5kIFNJUCANCj4gPnJlY29yZGluZyA/DQo+ID5JZiB5
b3UgZG9uwrl0IGhhdmUgYW55IHNwZWNpZmljIHJlYXNvbiB0byBkbyBpdCBoZXJlIHlvdSBtYXkg
d2FudCB0bw0KPiBzdGFydA0KPiA+dGhpcyBkaXNjdXNzaW9uIGluIFNJUFJFQyBXRy4NCj4gPg0K
PiA+SSBkbyBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhpcyB0b3BpYyBidXQgSSB0aGluayBTSVBS
RUMgV0cgaXMgdGhlDQo+IHJpZ2h0DQo+ID5wbGFjZSB0byBoYXZlIHRob3NlIGRpc2N1c3Npb25z
Lg0KPiA+DQo+ID4NCj4gPlJlZ2FyZHMsDQo+ID5SYW0NCj4gPg0KPiA+RnJvbTogIEdlcmJlbiBT
dGFtIDxHZXJiZW4uU3RhbUBuaWNlLmNvbT4NCj4gPkRhdGU6ICBUaHVyc2RheSwgNiBGZWJydWFy
eSAyMDE0IDM6NTggcG0NCj4gPlRvOiAgR2VyYmVuIFN0YW0gPEdlcmJlbi5TdGFtQG5pY2UuY29t
Pg0KPiA+Q2M6ICAiZGlzcGF0Y2hAaWV0Zi5vcmciIDxkaXNwYXRjaEBpZXRmLm9yZz4NCj4gPlN1
YmplY3Q6ICBbZGlzcGF0Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBTSVBSRUMNCj4gPg0KPiA+
DQo+ID5EZWFyIERJU1BBVENIIGdyb3VwLA0KPiA+DQo+ID5TSVBSRUMgaXMgYSBncmVhdCBpbml0
aWF0aXZlIHRvIHN0YW5kYXJkaXplIHRoZSBpbnRlcmZhY2UgZm9yDQo+IGNhcHR1cmluZw0KPiA+
Q29tbXVuaWNhdGlvbiBTZXNzaW9ucy4NCj4gPlNlc3Npb24gUmVjb3JkaW5nIGlzIGJlY29taW5n
IG1vcmUgYW5kIG1vcmUgY3JpdGljYWwgZHVlIHRvIA0KPiA+Q29tcGxpYW5jZSBhbmQgcmVndWxh
dG9yeSBjaGFuZ2VzIG92ZXIgdGhlIGxhc3QgeWVhcnMuDQo+ID4NCj4gPlRoZSBjb21wbGlhbmNl
IG1hcmtldCBpcyByZXF1ZXN0aW5nIG1vcmUgdGhhbiBjYXB0dXJlIG9ubHkgdGhlc2UgZGF5cyAN
Cj4gPkNvbmZpcm1hdGlvbiBpcyBuZWVkZWQgdG8gYWNrbm93bGVkZ2UgdGhlIGVudGlyZSBDb21t
dW5pY2F0aW9uIA0KPiA+U2Vzc2lvbiB3YXMgY2FwdHVyZWQgY29ycmVjdGx5Lg0KPiA+UlRDUCBS
ZXBvcnRzIChyZmMzNjExKSB3aWxsIGhlbHAgdG8gY29uZmlybSBjb21wbGV0ZSBoYW5kb3ZlciBv
ZiBSVFAgDQo+ID5jb250ZW50Lg0KPiA+DQo+ID4NCj4gPg0KPiA+TmV3IHJlcXVpcmVtZW50IGlz
IMWSbG9zc2xlc3PCuSBTZXNzaW9uIENhcHR1cmluZy4NCj4gDQo+IFdoeSBpcyB0aGlzIGEgbmV3
IHJlcXVpcmVtZW50ID8gUkZDIDYzNDEgKFNJUFJFQyByZXF1aXJlbWVudHMpIGFscmVhZHkgDQo+
IGhhcyBhIHJlcXVpcmVtZW50IGZvciBMb3NzbGVzcyByZWNvcmRpbmcuIFNlZSBSRVEgMDA1Lg0K
PiANCj4gDQo+ID5Mb3NzbGVzcyBpbmRpY2F0aW5nIGhhbmRvdmVyIG9mIGNvbnRlbnQgKFJUUCkg
aXMgYWNrbm93bGVkZ2VkIGJ5IHRoZSANCj4gPnJlY2VpdmVyIEFORCBpbiBjYXNlIG9mIHJlY2Vp
dmluZyBpc3N1ZXMsIHRoZSBzZW5kZXIgd2lsbCByZXNlbmQuDQo+ID5SZWFzb25zIGZvciBsb3Nz
IG1heSBiZSBVRFAgcGFja2V0IGxvc3Mgb3IgcmVjZWl2ZXIgZmFpbGluZyhvdmVyKSBhbmQgDQo+
ID50ZW1wb3Jhcnkgbm90IGFibGUgdG8gYWNjZXB0IGNvbnRlbnQuDQo+ID5DdXJyZW50IGFwcHJv
YWNoIHRvIGFkZHJlc3MgdGhpcyDFkmxvc3NsZXNzwrkgcmVxdWlyZW1lbnQgaXMgdXNpbmcgMiAN
Cj4gPmluZGVwZW5kZW50IHBhcmFsbGVsIHJlY2VpdmVycy4NCj4gDQo+IFRoZXJlIG1heSBiZSBv
dGhlciBhcHByb2FjaGVzIHdlbGwuIEZvciBleGFtcGxlIGFuIFNSQyBtYXkgYnVmZmVyIGZvciAN
Cj4gYSBzbWFsbCBkdXJhdGlvbiB0byB0YWtlIGNhcmUgb2YgdGhlIGxvc3MuIFR3byBwYXJhbGxl
bCByZWNlaXZlcnMgDQo+IHN0aWxsIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IHJlY29yZGluZyBp
cyBsb3NlbGVzcyBhcyB5b3UgY2FuIGhhdmUgDQo+IFVEUCBwYWNrZXQgbG9zcyBvbiBib3RoIHBh
dGhzLg0KPiANCj4gPg0KPiA+VGhpcyByZXF1aXJlcyB0aGUgc2VuZGVyIHRvIHNlbmQgMiBpbmRp
dmlkdWFsIHN0cmVhbXMsIGluIGZhY3QgMiANCj4gPmluZGVwZW5kZW50IFNJUFJFQyBzZXNzaW9u
cy4NCj4gPg0KPiA+Tm90IHN1cmUgaWYgdGhpcyBpcyBjb3ZlcmVkIGN1cnJlbnRseSBhcyBzdXBw
b3J0ZWQgU0lQUkVDIGRlcGxveW1lbnQuDQo+IA0KPiANCj4gQ3VycmVudCBTSVBSRUMgZG9lcyBu
b3QgaGF2ZSBhbnkgc3VjaCBjb25zdHJhaW50cy4gRGVwZW5kaW5nIG9uIHlvdXIgDQo+IGltcGxl
bWVudGF0aW9uIG1vZGVsIHlvdSBjYW4gaGF2ZSB0aGUgc2FtZSBDUyByZWNvcmRlZCBieSBtdWx0
aXBsZSBTUkMgDQo+IG9yIGhhdmUgc2FtZSBTUkMgZG8gbXVsdGlwbGUgcmVjb3JkaW5ncyBvZiBz
YW1lIENTLg0KPiANCj4gUmVnYXJkcywNCj4gUmFtDQo+IA0KPiA+IFdlIGRvIHNlZSBpbXBsZW1l
bnRhdGlvbnMgYmFzZWQgb24gU0lQUkVDIHN1cHBvcnRpbmcgaXQuDQo+ID5BbHRlcm5hdGl2ZSBp
cyBxdWljayBmYWlsb3ZlciBhdCByZWNlaXZlciBpbiBjYXNlIG9mIGZhaWx1cmUgYnV0IGFzIA0K
PiA+c2VuZGVyIHdpbGwgc2VuZCBvbmx5IG9uY2UsIHRoaXMgbWF5IGxlYWQgdG8gbG9zcyBkdXJp
bmcgZmFpbG92ZXIuDQo+ID4NCj4gPkkgYW0gbm90IGF3YXJlIG9mIGFueSByZmMgY292ZXJpbmcg
bG9zc2xlc3MgY29udGVudCBoYW5kb3ZlciwgYnV0DQo+IHRoZXJlDQo+ID5tYXkgYmUgc3RhbmRh
cmRzIGNvdmVyaW5nIHRoaXMgYWxyZWFkeS4NCj4gPg0KPiA+DQo+ID5Mb29raW5nIGZvcndhcmQg
dG8gZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0LiBJIG1heSBiZSBhdCB0aGUNCj4gTG9u
ZG9uDQo+ID5ldmVudC4NCj4gPg0KPiA+UmVnYXJkcywNCj4gPg0KPiA+R2VyYmVuIFN0YW0sDQo+
ID5OSUNFIFN5c3RlbXMNCj4gPg0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gZGlzcGF0
Y2hAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNw
YXRjaA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
ZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K

From DAVE.HIGTON@nice.com  Fri Feb  7 06:04:42 2014
Return-Path: <DAVE.HIGTON@nice.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 303DD1A1EFE for <siprec@ietfa.amsl.com>; Fri,  7 Feb 2014 06:04:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.835
X-Spam-Level: 
X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.535] 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 IppTfALhpyHv for <siprec@ietfa.amsl.com>; Fri,  7 Feb 2014 06:04:39 -0800 (PST)
Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id B422F1A1EF8 for <siprec@ietf.org>; Fri,  7 Feb 2014 06:04:38 -0800 (PST)
Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Fri, 7 Feb 2014 14:04:38 +0000
Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Feb 2014 14:04:37 +0000
Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Fri, 7 Feb 2014 14:04:37 +0000
From: "Dave Higton" <DAVE.HIGTON@nice.com>
To: <siprec@ietf.org>
Date: Fri, 7 Feb 2014 14:04:36 +0000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
Thread-Topic: [dispatch] Lossless Recording in SIPREC
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
Thread-Index: AQHPI1dDJyXBrcc2c0ma7EaQoC0IX5qobTRggAEOSSCAAD3w8IAAGqmw
Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B69405E811F545@SOUEXC01.eu.nice.com>
References: <CF199D4B.7A6E4%rmohanr@cisco.com> <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <CF19B110.7A78A%rmohanr@cisco.com> <00dd01cf235b$a5401470$efc03d50$@co.in> <0D3A16BBDECB2C4BB2DF22F87BB87374089E2F29A9@SOUEXC01.eu.nice.com> <4BEAD79F6904AC4FB1917EBA8006628905C068613B@SOUEXC01.eu.nice.com>
In-Reply-To: <4BEAD79F6904AC4FB1917EBA8006628905C068613B@SOUEXC01.eu.nice.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Feb 2014 14:04:37.0645 (UTC) FILETIME=[897673D0:01CF240D]
Subject: Re: [siprec] [dispatch] Lossless Recording in SIPREC
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, 07 Feb 2014 14:04:42 -0000

The tried and tested method to prevent packet loss is to use TCP, isn't =
it?

Dave

-----Original Message-----
From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Gerben Stam
Sent: 07 February 2014 13:56
To: Parthasarathi R; 'Ram Mohan R (rmohanr)'
Cc: Gerben Stam; siprec@ietf.org
Subject: Re: [siprec] [dispatch] Lossless Recording in SIPREC

Hey guys,

I have had a look at Lossless statements in SIPREC now (Uses Case 10 and =
REQ-021).
Control start of RTP the moment we state a=3Dsendonly in the SDP.
This is to cover RS start delay due to late acceptance by SRS, buffering =
on the SRC. It does no cover mid RS loss of RTP.

draft-ietf-avtext-rtp-duplication-04
Explains dual RTP streams send by SRS with own SSRC/SRTP keying and even =
RTCP. Using a=3Dssrc-group:DUP 1000 1010.
Streams can take separate network routes to cover UDP packet loss in the =
network.
At the SRS side we need to create single recording from the combined =
streams and fill potential RTP gaps by the other RTP stream.
This is to cover UDP packet loss or even stream loss in the network.

Issue not addressed still is what to do if SRS goes down mid SR and =
needs to failover (HA).
Before the outage is detected by SRC, it would have send RTP for the RS, =
which was not received by SRS.
RTCP reports may notify the loss at SRC (at least if SRC sends receiver =
reports to SRS).
Will RTCP also support re-sending a certain RTP packet if the SRS did =
not receive it?=20

This may look like a trivial issue as for each new CS a new SIP invite =
is send, which is true for IPT (Phone) environments.
In trading recording however, a CS lasts from the time the Trader log's =
on till he log's off. So all day.
Within this very long SIP session, multiple RS are triggered each with =
its Meta.=20
SSRC may stay but RTP has VAD (activity detection, no RTP send if no RS)
With current strict regulation, any loss of recording needs to be =
reported. RTCP helps at SRC.
Still re requirement by the industry is moving towards lossless. Mainly =
acknowledge RTP received and ability to re-send even mid RS by SRC.

draft-ietf-avtext-rtp-duplication-04 may help but that will require to =
capture duplicate RTP streams on individual RTP loggers.
If one RTP logger would fail, CS continues on other logger.
SRC would need to re-invite an update the RTP destination for the =
failing RTP Logger to re-direct the stream to another node.
That would cover mid SR RTP Logger outage, but will raise complexity at =
the RSC side.=20
Still an option tough we may advice to create 'lossless'.
draft-ietf-avtext-rtp-duplication-04 is more tailored to cover dual RTP =
routes (and dual NIC) between singe SRC and SRS.

What do you think?

Gerben





-----Original Message-----
From: Gerben Stam=20
Sent: vrijdag 7 februari 2014 10:05
To: 'Parthasarathi R'; 'Ram Mohan R (rmohanr)'
Cc: siprec@ietf.org
Subject: RE: [dispatch] Lossless Recording in SIPREC

Hi Partha and Ram,

Thanks for the feedback on Lossless, I will check the rfc's you =
indicated and get back on potential gaps in lossless recording =
requirements.
So far I have never seen lossless implementation combined with SIPREC =
apart from HA (options ping).

Be aware that lossless is not only to cover packet loss in UDP =
transmission (like FEC is additional parity blocks to cover packet =
loss).
Also the fact the SRS may not be ready to receive would need to trigger =
the SRC to buffer audio.
Again I will check the suggested existing standards .

Regards,

Gerben



-----Original Message-----
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of =
Parthasarathi R
Sent: donderdag 6 februari 2014 17:51
To: 'Ram Mohan R (rmohanr)'; Gerben Stam
Cc: siprec@ietf.org; dispatch@ietf.org
Subject: Re: [dispatch] Lossless Recording in SIPREC

Hi Gerben,

I agree with Ram that lossless recording is within SIPREC requirement as =
mentioned in RFC 6341. Apart from REQ-5 in RFC 6341, some of the text =
related to High availability is mentioned in the note of this mail.

Also, the lossless recording shall be achieved by multiple means. One of =
the mechanism is explained in draft-ietf-avtext-rtp-duplication-04. IMO, =
let us discuss in SIPREC about the specific technical issue in lossless =
recording which is not possible to be achieved through the existing =
mechanism=20

Including SIPREC mailing alias in this mail thread.

Thanks
Partha

Note:

 Use Case 10: High availability and continuous recording.

      Specific deployment scenarios present different requirements for
      system availability, error handling, etc., including the
      following:

      o  An SRS must always be available at call setup time.

      o  No loss of media recording can occur, including during failure
         of an SRS.

      o  The Communication Session must be terminated (or suitable
         notification given to parties) in the event of a recording
         failure.


REQ-021: The mechanism MUST NOT prevent high-availability
      deployments.=20

> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram=20
> Mohan R (rmohanr)
> Sent: Thursday, February 06, 2014 9:50 PM
> To: Gerben Stam
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>=20
> Hi,
>=20
> Please see inline
>=20
> -----Original Message-----
> From: Gerben Stam <Gerben.Stam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@cisco.com>
> Cc: "dispatch@ietf.org" <dispatch@ietf.org>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>=20
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of the =

> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a good=20
> >topic to discuss in the team.
>=20
> Ok. I was not aware of this.
>=20
> >
> >What would I need to do to bend this to SIPREC WG instead of =
Dispatch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatch@ietf.org
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch=20
> >and not in SIPREC WG which is meant to discuss the issues around SIP=20
> >recording ?
> >If you don=C2=B9t have any specific reason to do it here you may want =
to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <Gerben.Stam@nice.com>
> >Cc:  "dispatch@ietf.org" <dispatch@ietf.org>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >Dear DISPATCH group,
> >
> >SIPREC is a great initiative to standardize the interface for
> capturing
> >Communication Sessions.
> >Session Recording is becoming more and more critical due to=20
> >Compliance and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these days =

> >Confirmation is needed to acknowledge the entire Communication=20
> >Session was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of RTP=20
> >content.
> >
> >
> >
> >New requirement is =C5=92lossless=C2=B9 Session Capturing.
>=20
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already =

> has a requirement for Lossless recording. See REQ 005.
>=20
>=20
> >Lossless indicating handover of content (RTP) is acknowledged by the=20
> >receiver AND in case of receiving issues, the sender will resend.
> >Reasons for loss may be UDP packet loss or receiver failing(over) and =

> >temporary not able to accept content.
> >Current approach to address this =C5=92lossless=C2=B9 requirement is =
using 2=20
> >independent parallel receivers.
>=20
> There may be other approaches well. For example an SRC may buffer for=20
> a small duration to take care of the loss. Two parallel receivers=20
> still does not guarantee that recording is loseless as you can have=20
> UDP packet loss on both paths.
>=20
> >
> >This requires the sender to send 2 individual streams, in fact 2=20
> >independent SIPREC sessions.
> >
> >Not sure if this is covered currently as supported SIPREC deployment.
>=20
>=20
> Current SIPREC does not have any such constraints. Depending on your=20
> implementation model you can have the same CS recorded by multiple SRC =

> or have same SRC do multiple recordings of same CS.
>=20
> Regards,
> Ram
>=20
> > We do see implementations based on SIPREC supporting it.
> >Alternative is quick failover at receiver in case of failure but as=20
> >sender will send only once, this may lead to loss during failover.
> >
> >I am not aware of any rfc covering lossless content handover, but
> there
> >may be standards covering this already.
> >
> >
> >Looking forward to discussion on the mailing list. I may be at the
> London
> >event.
> >
> >Regards,
> >
> >Gerben Stam,
> >NICE Systems
> >
> >
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

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


NICE Systems UK Limited ("NICE") is registered in England under company =
number, 3403044. The registered office of NICE is at Tollbar Way, Hedge =
End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for =
the above-named persons only and may be confidential and/or legally =
privileged. Any opinions expressed in this communication are not =
necessarily those of NICE. If this communication has come to you in =
error you must take no action based on it, nor must you copy or show it =
to anyone; please delete/destroy and inform the sender by e-mail =
immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail =
and attachments are free from any virus, we advise that in keeping with =
good computing practice the recipient should ensure they are actually =
virus free.

From pkyzivat@alum.mit.edu  Fri Feb  7 08:29:26 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 5F4851A04F5 for <siprec@ietfa.amsl.com>; Fri,  7 Feb 2014 08:29:26 -0800 (PST)
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 5P19dggIGtjv for <siprec@ietfa.amsl.com>; Fri,  7 Feb 2014 08:29:24 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 55FDC1A03F5 for <siprec@ietf.org>; Fri,  7 Feb 2014 08:29:24 -0800 (PST)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta04.westchester.pa.mail.comcast.net with comcast id PQAA1n0050SCNGk54UVQ6R; Fri, 07 Feb 2014 16:29:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id PUVP1n00i3ZTu2S3VUVQmj; Fri, 07 Feb 2014 16:29:24 +0000
Message-ID: <52F509E3.5070700@alum.mit.edu>
Date: Fri, 07 Feb 2014 11:29:23 -0500
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.3.0
MIME-Version: 1.0
To: siprec@ietf.org
References: <CF199D4B.7A6E4%rmohanr@cisco.com> <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <CF19B110.7A78A%rmohanr@cisco.com> <00dd01cf235b$a5401470$efc03d50$@co.in> <4BEAD79F6904AC4FB1917EBA8006628905C0685ED5@SOUEXC01.eu.nice.com>
In-Reply-To: <4BEAD79F6904AC4FB1917EBA8006628905C0685ED5@SOUEXC01.eu.nice.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391790564; bh=ny2Jl3qI6d+A4kMRPoIIdc0F/guk6ioVKzXQ63r0AfY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Jiaepdr5eGqTTWRpb20yiBBhFe2uuzSfqytSnS4KScQEZHKOaobfYMbDOj3Z9b8o0 +msD4Quylwlo6FcRBggEgvWhIvfL5Ef1dwRNmgiNCAp94x8z3J4t+IGbNc6xuvs8OM CDxQrJCjSz4pTBbfb5yVxR7L6cJVIAAG77lsW7JzIYdqHbAzfM9f9vvYZB5uHNmU44 M9nHdAWqdk/7wFuzf20e/gKBspENrtTkyUVHxKAJxAg/8Rw78o+3MX6LMU28yUfdbo 4XuGZLu88pqv63bRmL0INbJBptex6NlWx17r1u5lxkqw/6ysOYJCAK0bFgTAlqH6P9 hUS9828Vt5Qww==
Subject: Re: [siprec] [dispatch] Lossless Recording in SIPREC
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, 07 Feb 2014 16:29:26 -0000

(I'm replying on siprec because that is where I received the message I'm 
replying to. It is fuzzy to me whether this should be on siprec or 
dispatch.)

On 2/7/14 4:04 AM, Gerben Stam wrote:
> Hi Partha and Ram,
>
> Thanks for the feedback on Lossless, I will check the rfc's you indicated and get back on potential gaps in lossless recording requirements.
> So far I have never seen lossless implementation combined with SIPREC apart from HA (options ping).
>
> Be aware that lossless is not only to cover packet loss in UDP transmission (like FEC is additional parity blocks to cover packet loss).
> Also the fact the SRS may not be ready to receive would need to trigger the SRC to buffer audio.
> Again I will check the suggested existing standards .

Note: one possible approach for an SRC that is trying to achieve this is:
- buffer all the media for a CS.
- when it is done, establish an RS, using RTP over TCP
- send all the media and metadata.

That should all be valid now, except maybe use of RTP over TCP for the 
RS might not be covered. (I *think* it is allowed by the existing 
protocol draft, but that probably deserves some discussion.)

*If* you did that, and the RS failed before all was transmitted, you 
could always retry it. That *might* cause a problem at the SRS, getting 
duplicate info. So that might also require some sort of extension.

An intermediate approach would be like above, but starting the RS before 
the CS is complete, but retaining the local buffer for speed matching 
and in case it is necessary to restart the RS.

Of course it is a bigger burden on the SRC to buffer the CS. But it may 
be necessary if you really require a lossless solution.

	Thanks,
	Paul

> Regards,
>
> Gerben
>
>
>
> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R
> Sent: donderdag 6 februari 2014 17:51
> To: 'Ram Mohan R (rmohanr)'; Gerben Stam
> Cc: siprec@ietf.org; dispatch@ietf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>
> Hi Gerben,
>
> I agree with Ram that lossless recording is within SIPREC requirement as mentioned in RFC 6341. Apart from REQ-5 in RFC 6341, some of the text related to High availability is mentioned in the note of this mail.
>
> Also, the lossless recording shall be achieved by multiple means. One of the mechanism is explained in draft-ietf-avtext-rtp-duplication-04. IMO, let us discuss in SIPREC about the specific technical issue in lossless recording which is not possible to be achieved through the existing mechanism
>
> Including SIPREC mailing alias in this mail thread.
>
> Thanks
> Partha
>
> Note:
>
>   Use Case 10: High availability and continuous recording.
>
>        Specific deployment scenarios present different requirements for
>        system availability, error handling, etc., including the
>        following:
>
>        o  An SRS must always be available at call setup time.
>
>        o  No loss of media recording can occur, including during failure
>           of an SRS.
>
>        o  The Communication Session must be terminated (or suitable
>           notification given to parties) in the event of a recording
>           failure.
>
>
> REQ-021: The mechanism MUST NOT prevent high-availability
>        deployments.
>
>> -----Original Message-----
>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram
>> Mohan R (rmohanr)
>> Sent: Thursday, February 06, 2014 9:50 PM
>> To: Gerben Stam
>> Cc: dispatch@ietf.org
>> Subject: Re: [dispatch] Lossless Recording in SIPREC
>>
>> Hi,
>>
>> Please see inline
>>
>> -----Original Message-----
>> From: Gerben Stam <Gerben.Stam@nice.com>
>> Date: Thursday, 6 February 2014 8:40 pm
>> To: Cisco Employee <rmohanr@cisco.com>
>> Cc: "dispatch@ietf.org" <dispatch@ietf.org>
>> Subject: RE: [dispatch] Lossless Recording in SIPREC
>>
>>> Hey Ram,
>>>
>>> I have had an off-line discussion with Andrew Hutton, chairman of the
>>> SIPREC group.
>>> He suggested to post this on the IETF dispatch group as it is a good
>>> topic to discuss in the team.
>>
>> Ok. I was not aware of this.
>>
>>>
>>> What would I need to do to bend this to SIPREC WG instead of Dispatch?
>>>
>>> Regards,
>>>
>>> Gerben
>>>
>>> -----Original Message-----
>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
>>> Sent: donderdag 6 februari 2014 15:45
>>> To: Gerben Stam
>>> Cc: dispatch@ietf.org
>>> Subject: Re: [dispatch] Lossless Recording in SIPREC
>>>
>>> Hi,
>>>
>>> Is there a reason why you want to have this discussion in dispatch
>>> and not in SIPREC WG which is meant to discuss the issues around SIP
>>> recording ?
>>> If you don¹t have any specific reason to do it here you may want to
>> start
>>> this discussion in SIPREC WG.
>>>
>>> I do have some comments on this topic but I think SIPREC WG is the
>> right
>>> place to have those discussions.
>>>
>>>
>>> Regards,
>>> Ram
>>>
>>> From:  Gerben Stam <Gerben.Stam@nice.com>
>>> Date:  Thursday, 6 February 2014 3:58 pm
>>> To:  Gerben Stam <Gerben.Stam@nice.com>
>>> Cc:  "dispatch@ietf.org" <dispatch@ietf.org>
>>> Subject:  [dispatch] Lossless Recording in SIPREC
>>>
>>>
>>> Dear DISPATCH group,
>>>
>>> SIPREC is a great initiative to standardize the interface for
>> capturing
>>> Communication Sessions.
>>> Session Recording is becoming more and more critical due to
>>> Compliance and regulatory changes over the last years.
>>>
>>> The compliance market is requesting more than capture only these days
>>> Confirmation is needed to acknowledge the entire Communication
>>> Session was captured correctly.
>>> RTCP Reports (rfc3611) will help to confirm complete handover of RTP
>>> content.
>>>
>>>
>>>
>>> New requirement is Œlossless¹ Session Capturing.
>>
>> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already
>> has a requirement for Lossless recording. See REQ 005.
>>
>>
>>> Lossless indicating handover of content (RTP) is acknowledged by the
>>> receiver AND in case of receiving issues, the sender will resend.
>>> Reasons for loss may be UDP packet loss or receiver failing(over) and
>>> temporary not able to accept content.
>>> Current approach to address this Œlossless¹ requirement is using 2
>>> independent parallel receivers.
>>
>> There may be other approaches well. For example an SRC may buffer for
>> a small duration to take care of the loss. Two parallel receivers
>> still does not guarantee that recording is loseless as you can have
>> UDP packet loss on both paths.
>>
>>>
>>> This requires the sender to send 2 individual streams, in fact 2
>>> independent SIPREC sessions.
>>>
>>> Not sure if this is covered currently as supported SIPREC deployment.
>>
>>
>> Current SIPREC does not have any such constraints. Depending on your
>> implementation model you can have the same CS recorded by multiple SRC
>> or have same SRC do multiple recordings of same CS.
>>
>> Regards,
>> Ram
>>
>>> We do see implementations based on SIPREC supporting it.
>>> Alternative is quick failover at receiver in case of failure but as
>>> sender will send only once, this may lead to loss during failover.
>>>
>>> I am not aware of any rfc covering lossless content handover, but
>> there
>>> may be standards covering this already.
>>>
>>>
>>> Looking forward to discussion on the mailing list. I may be at the
>> London
>>> event.
>>>
>>> Regards,
>>>
>>> Gerben Stam,
>>> NICE Systems
>>>
>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>


From rmohanr@cisco.com  Tue Feb 11 03:16:25 2014
Return-Path: <rmohanr@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 A96AE1A06BF for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 03:16:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.449
X-Spam-Level: 
X-Spam-Status: No, score=-14.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 hcB1XhQHxKAo for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 03:16:22 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DBC711A00AE for <siprec@ietf.org>; Tue, 11 Feb 2014 03:16:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14172; q=dns/txt; s=iport; t=1392117381; x=1393326981; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jwYHkr9x3sg2/WD3UysVooMvxHf1+7p0y2cpJsgVp88=; b=g/u3H8wWAW7cwRhayv38MiGlSXsDw13PKe0qkThj8czP6K42qJIHA59e hNaQ55DYz9cly6xIayD75xwXa2brncxinKHLVUfkCsHiWBJaNgQTlKrU3 ZlUGrw+4byRa+0T962wZxKhkilwmUS6QqLOvhZBWQjmjUlcqnkDNsur1u k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAKsF+lKtJXHA/2dsb2JhbABZgw44VYMDuH1PGHgWAXSDfQEBAQQBAQEgEToLDAQCAQgRAwEBAQMCIwMCAgIlCxQBCAgCBAENBYgEDahAmUQTBIEpjRUDAQEkKwcEAoJogUgBA5gWkhSDK4FoBQICFwQe
X-IronPort-AV: E=Sophos;i="4.95,825,1384300800"; d="scan'208";a="300237884"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 11 Feb 2014 11:16:21 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1BBGLQ7005339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 11:16:21 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.191]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 05:16:20 -0600
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Gerben Stam <Gerben.Stam@nice.com>, Parthasarathi R <partha@parthasarathi.co.in>
Thread-Topic: [dispatch] Lossless Recording in SIPREC
Thread-Index: AQHPJxqwt8Jn2hui1E6LoRwUDkitrg==
Date: Tue, 11 Feb 2014 11:16:19 +0000
Message-ID: <CF200341.7AE1F%rmohanr@cisco.com>
References: <CF199D4B.7A6E4%rmohanr@cisco.com> <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <CF19B110.7A78A%rmohanr@cisco.com> <00dd01cf235b$a5401470$efc03d50$@co.in> <0D3A16BBDECB2C4BB2DF22F87BB87374089E2F29A9@SOUEXC01.eu.nice.com> <4BEAD79F6904AC4FB1917EBA8006628905C068613B@SOUEXC01.eu.nice.com>
In-Reply-To: <4BEAD79F6904AC4FB1917EBA8006628905C068613B@SOUEXC01.eu.nice.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: [72.163.212.124]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C4E21B95C63B7349BCD1C789D7E0DC4A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "siprec@ietf.org" <siprec@ietf.org>
Subject: Re: [siprec] [dispatch] Lossless Recording in SIPREC
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, 11 Feb 2014 11:16:25 -0000

UGxlYXNlIHNlZSBpbmxpbmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEdl
cmJlbiBTdGFtIDxHZXJiZW4uU3RhbUBuaWNlLmNvbT4NCkRhdGU6IEZyaWRheSwgNyBGZWJydWFy
eSAyMDE0IDc6MjYgcG0NClRvOiBQYXJ0aGFzYXJhdGhpIFIgPHBhcnRoYUBwYXJ0aGFzYXJhdGhp
LmNvLmluPiwgQ2lzY28gRW1wbG95ZWUNCjxybW9oYW5yQGNpc2NvLmNvbT4NCkNjOiAic2lwcmVj
QGlldGYub3JnIiA8c2lwcmVjQGlldGYub3JnPiwgR2VyYmVuIFN0YW0gPEdlcmJlbi5TdGFtQG5p
Y2UuY29tPg0KU3ViamVjdDogUkU6IFtkaXNwYXRjaF0gTG9zc2xlc3MgUmVjb3JkaW5nIGluIFNJ
UFJFQw0KDQo+SGV5IGd1eXMsDQo+DQo+SSBoYXZlIGhhZCBhIGxvb2sgYXQgTG9zc2xlc3Mgc3Rh
dGVtZW50cyBpbiBTSVBSRUMgbm93IChVc2VzIENhc2UgMTAgYW5kDQo+UkVRLTAyMSkuDQo+Q29u
dHJvbCBzdGFydCBvZiBSVFAgdGhlIG1vbWVudCB3ZSBzdGF0ZSBhPXNlbmRvbmx5IGluIHRoZSBT
RFAuDQo+VGhpcyBpcyB0byBjb3ZlciBSUyBzdGFydCBkZWxheSBkdWUgdG8gbGF0ZSBhY2NlcHRh
bmNlIGJ5IFNSUywgYnVmZmVyaW5nDQo+b24gdGhlIFNSQy4gSXQgZG9lcyBubyBjb3ZlciBtaWQg
UlMgbG9zcyBvZiBSVFAuDQo+DQo+ZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWR1cGxpY2F0aW9uLTA0
DQo+RXhwbGFpbnMgZHVhbCBSVFAgc3RyZWFtcyBzZW5kIGJ5IFNSUyB3aXRoIG93biBTU1JDL1NS
VFAga2V5aW5nIGFuZCBldmVuDQo+UlRDUC4gVXNpbmcgYT1zc3JjLWdyb3VwOkRVUCAxMDAwIDEw
MTAuDQo+U3RyZWFtcyBjYW4gdGFrZSBzZXBhcmF0ZSBuZXR3b3JrIHJvdXRlcyB0byBjb3ZlciBV
RFAgcGFja2V0IGxvc3MgaW4gdGhlDQo+bmV0d29yay4NCj5BdCB0aGUgU1JTIHNpZGUgd2UgbmVl
ZCB0byBjcmVhdGUgc2luZ2xlIHJlY29yZGluZyBmcm9tIHRoZSBjb21iaW5lZA0KPnN0cmVhbXMg
YW5kIGZpbGwgcG90ZW50aWFsIFJUUCBnYXBzIGJ5IHRoZSBvdGhlciBSVFAgc3RyZWFtLg0KPlRo
aXMgaXMgdG8gY292ZXIgVURQIHBhY2tldCBsb3NzIG9yIGV2ZW4gc3RyZWFtIGxvc3MgaW4gdGhl
IG5ldHdvcmsuDQo+DQo+SXNzdWUgbm90IGFkZHJlc3NlZCBzdGlsbCBpcyB3aGF0IHRvIGRvIGlm
IFNSUyBnb2VzIGRvd24gbWlkIFNSIGFuZCBuZWVkcw0KPnRvIGZhaWxvdmVyIChIQSkuDQo+QmVm
b3JlIHRoZSBvdXRhZ2UgaXMgZGV0ZWN0ZWQgYnkgU1JDLCBpdCB3b3VsZCBoYXZlIHNlbmQgUlRQ
IGZvciB0aGUgUlMsDQo+d2hpY2ggd2FzIG5vdCByZWNlaXZlZCBieSBTUlMuDQo+UlRDUCByZXBv
cnRzIG1heSBub3RpZnkgdGhlIGxvc3MgYXQgU1JDIChhdCBsZWFzdCBpZiBTUkMgc2VuZHMgcmVj
ZWl2ZXINCj5yZXBvcnRzIHRvIFNSUykuDQo+V2lsbCBSVENQIGFsc28gc3VwcG9ydCByZS1zZW5k
aW5nIGEgY2VydGFpbiBSVFAgcGFja2V0IGlmIHRoZSBTUlMgZGlkIG5vdA0KPnJlY2VpdmUgaXQ/
DQoNClRoZXJlIGNvdWxkIGJlIG1hbnkgd2F5cyB5b3Ugd291bGQgc29sdmUgaXQuIFNvbWUgb2Yg
dGhlbSBhcmU6DQpTUkMgZGV0ZWN0cyB0aGF0IFNSUyBpcyBkb3duIHVzaW5nIHdoYXRldmVyIG1l
YW5zIGl0IGtub3dzIG9mIChPUFRJT05TDQpwaW5nIG9yIHNvbWUgdGhpbmcgZWxzZSkgYW5kIGlt
bWVkaWF0ZWx5IHN3aXRjaGVzIG92ZXIgdG8gYW5vdGhlciBTUlMuDQpTUkMgZGV0ZWN0cyBTUlMg
aXMgZG93biBhbmQgc3RhcnRzIGJ1ZmZlcmluZyB0aGUgbWVkaWEuDQpTUkMgbWF5IGhhdmUgbW9y
ZSB0aGFuIG9uZSByZWNvcmRpbmcgb2YgdGhlIHNhbWUgQ1MgLSByZWR1bmRhbnQgcmVjb3JkaW5n
LA0KdG8gZGlmZmVyZW50IFNSUy4gU28gZXZlbiBpZiBvbmUgU1JTIGdvZXMgZG93biB0aGUgU1JD
IHdvdWxkIGNvbnRpbnVlIHRvDQpyZWNvcmQgdG8gdGhlIHNlY29uZCBvbmUuDQoNClRoZSBjdXJy
ZW50IFNJUFJFQyBkb2VzIG5vdCBzdG9wIHlvdSBmcm9tIGhhdmluZyBhIGltcGxlbWVudGF0aW9u
IHRoYXQNCmRvZXMgYW55IG9yIGFsbCBvZiB0aGUgYWJvdmUuDQoNClJlZ2FyZHMsDQpSYW0NCg0K
PiANCj4NCj5UaGlzIG1heSBsb29rIGxpa2UgYSB0cml2aWFsIGlzc3VlIGFzIGZvciBlYWNoIG5l
dyBDUyBhIG5ldyBTSVAgaW52aXRlIGlzDQo+c2VuZCwgd2hpY2ggaXMgdHJ1ZSBmb3IgSVBUIChQ
aG9uZSkgZW52aXJvbm1lbnRzLg0KPkluIHRyYWRpbmcgcmVjb3JkaW5nIGhvd2V2ZXIsIGEgQ1Mg
bGFzdHMgZnJvbSB0aGUgdGltZSB0aGUgVHJhZGVyIGxvZydzDQo+b24gdGlsbCBoZSBsb2cncyBv
ZmYuIFNvIGFsbCBkYXkuDQo+V2l0aGluIHRoaXMgdmVyeSBsb25nIFNJUCBzZXNzaW9uLCBtdWx0
aXBsZSBSUyBhcmUgdHJpZ2dlcmVkIGVhY2ggd2l0aA0KPml0cyBNZXRhLiANCj5TU1JDIG1heSBz
dGF5IGJ1dCBSVFAgaGFzIFZBRCAoYWN0aXZpdHkgZGV0ZWN0aW9uLCBubyBSVFAgc2VuZCBpZiBu
byBSUykNCj5XaXRoIGN1cnJlbnQgc3RyaWN0IHJlZ3VsYXRpb24sIGFueSBsb3NzIG9mIHJlY29y
ZGluZyBuZWVkcyB0byBiZQ0KPnJlcG9ydGVkLiBSVENQIGhlbHBzIGF0IFNSQy4NCj5TdGlsbCBy
ZSByZXF1aXJlbWVudCBieSB0aGUgaW5kdXN0cnkgaXMgbW92aW5nIHRvd2FyZHMgbG9zc2xlc3Mu
IE1haW5seQ0KPmFja25vd2xlZGdlIFJUUCByZWNlaXZlZCBhbmQgYWJpbGl0eSB0byByZS1zZW5k
IGV2ZW4gbWlkIFJTIGJ5IFNSQy4NCj4NCj5kcmFmdC1pZXRmLWF2dGV4dC1ydHAtZHVwbGljYXRp
b24tMDQgbWF5IGhlbHAgYnV0IHRoYXQgd2lsbCByZXF1aXJlIHRvDQo+Y2FwdHVyZSBkdXBsaWNh
dGUgUlRQIHN0cmVhbXMgb24gaW5kaXZpZHVhbCBSVFAgbG9nZ2Vycy4NCj5JZiBvbmUgUlRQIGxv
Z2dlciB3b3VsZCBmYWlsLCBDUyBjb250aW51ZXMgb24gb3RoZXIgbG9nZ2VyLg0KPlNSQyB3b3Vs
ZCBuZWVkIHRvIHJlLWludml0ZSBhbiB1cGRhdGUgdGhlIFJUUCBkZXN0aW5hdGlvbiBmb3IgdGhl
IGZhaWxpbmcNCj5SVFAgTG9nZ2VyIHRvIHJlLWRpcmVjdCB0aGUgc3RyZWFtIHRvIGFub3RoZXIg
bm9kZS4NCj5UaGF0IHdvdWxkIGNvdmVyIG1pZCBTUiBSVFAgTG9nZ2VyIG91dGFnZSwgYnV0IHdp
bGwgcmFpc2UgY29tcGxleGl0eSBhdA0KPnRoZSBSU0Mgc2lkZS4gDQo+U3RpbGwgYW4gb3B0aW9u
IHRvdWdoIHdlIG1heSBhZHZpY2UgdG8gY3JlYXRlICdsb3NzbGVzcycuDQo+ZHJhZnQtaWV0Zi1h
dnRleHQtcnRwLWR1cGxpY2F0aW9uLTA0IGlzIG1vcmUgdGFpbG9yZWQgdG8gY292ZXIgZHVhbCBS
VFANCj5yb3V0ZXMgKGFuZCBkdWFsIE5JQykgYmV0d2VlbiBzaW5nZSBTUkMgYW5kIFNSUy4NCj4N
Cj5XaGF0IGRvIHlvdSB0aGluaz8NCj4NCj5HZXJiZW4NCj4NCj4NCj4NCj4NCj4NCj4tLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEdlcmJlbiBTdGFtIA0KPlNlbnQ6IHZyaWpkYWcg
NyBmZWJydWFyaSAyMDE0IDEwOjA1DQo+VG86ICdQYXJ0aGFzYXJhdGhpIFInOyAnUmFtIE1vaGFu
IFIgKHJtb2hhbnIpJw0KPkNjOiBzaXByZWNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogW2Rpc3Bh
dGNoXSBMb3NzbGVzcyBSZWNvcmRpbmcgaW4gU0lQUkVDDQo+DQo+SGkgUGFydGhhIGFuZCBSYW0s
DQo+DQo+VGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgb24gTG9zc2xlc3MsIEkgd2lsbCBjaGVjayB0
aGUgcmZjJ3MgeW91IGluZGljYXRlZA0KPmFuZCBnZXQgYmFjayBvbiBwb3RlbnRpYWwgZ2FwcyBp
biBsb3NzbGVzcyByZWNvcmRpbmcgcmVxdWlyZW1lbnRzLg0KPlNvIGZhciBJIGhhdmUgbmV2ZXIg
c2VlbiBsb3NzbGVzcyBpbXBsZW1lbnRhdGlvbiBjb21iaW5lZCB3aXRoIFNJUFJFQw0KPmFwYXJ0
IGZyb20gSEEgKG9wdGlvbnMgcGluZykuDQo+DQo+QmUgYXdhcmUgdGhhdCBsb3NzbGVzcyBpcyBu
b3Qgb25seSB0byBjb3ZlciBwYWNrZXQgbG9zcyBpbiBVRFANCj50cmFuc21pc3Npb24gKGxpa2Ug
RkVDIGlzIGFkZGl0aW9uYWwgcGFyaXR5IGJsb2NrcyB0byBjb3ZlciBwYWNrZXQgbG9zcykuDQo+
QWxzbyB0aGUgZmFjdCB0aGUgU1JTIG1heSBub3QgYmUgcmVhZHkgdG8gcmVjZWl2ZSB3b3VsZCBu
ZWVkIHRvIHRyaWdnZXINCj50aGUgU1JDIHRvIGJ1ZmZlciBhdWRpby4NCj5BZ2FpbiBJIHdpbGwg
Y2hlY2sgdGhlIHN1Z2dlc3RlZCBleGlzdGluZyBzdGFuZGFyZHMgLg0KPg0KPlJlZ2FyZHMsDQo+
DQo+R2VyYmVuDQo+DQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBk
aXNwYXRjaCBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0K
PlBhcnRoYXNhcmF0aGkgUg0KPlNlbnQ6IGRvbmRlcmRhZyA2IGZlYnJ1YXJpIDIwMTQgMTc6NTEN
Cj5UbzogJ1JhbSBNb2hhbiBSIChybW9oYW5yKSc7IEdlcmJlbiBTdGFtDQo+Q2M6IHNpcHJlY0Bp
ZXRmLm9yZzsgZGlzcGF0Y2hAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBMb3Nz
bGVzcyBSZWNvcmRpbmcgaW4gU0lQUkVDDQo+DQo+SGkgR2VyYmVuLA0KPg0KPkkgYWdyZWUgd2l0
aCBSYW0gdGhhdCBsb3NzbGVzcyByZWNvcmRpbmcgaXMgd2l0aGluIFNJUFJFQyByZXF1aXJlbWVu
dCBhcw0KPm1lbnRpb25lZCBpbiBSRkMgNjM0MS4gQXBhcnQgZnJvbSBSRVEtNSBpbiBSRkMgNjM0
MSwgc29tZSBvZiB0aGUgdGV4dA0KPnJlbGF0ZWQgdG8gSGlnaCBhdmFpbGFiaWxpdHkgaXMgbWVu
dGlvbmVkIGluIHRoZSBub3RlIG9mIHRoaXMgbWFpbC4NCj4NCj5BbHNvLCB0aGUgbG9zc2xlc3Mg
cmVjb3JkaW5nIHNoYWxsIGJlIGFjaGlldmVkIGJ5IG11bHRpcGxlIG1lYW5zLiBPbmUgb2YNCj50
aGUgbWVjaGFuaXNtIGlzIGV4cGxhaW5lZCBpbiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZHVwbGlj
YXRpb24tMDQuIElNTywNCj5sZXQgdXMgZGlzY3VzcyBpbiBTSVBSRUMgYWJvdXQgdGhlIHNwZWNp
ZmljIHRlY2huaWNhbCBpc3N1ZSBpbiBsb3NzbGVzcw0KPnJlY29yZGluZyB3aGljaCBpcyBub3Qg
cG9zc2libGUgdG8gYmUgYWNoaWV2ZWQgdGhyb3VnaCB0aGUgZXhpc3RpbmcNCj5tZWNoYW5pc20g
DQo+DQo+SW5jbHVkaW5nIFNJUFJFQyBtYWlsaW5nIGFsaWFzIGluIHRoaXMgbWFpbCB0aHJlYWQu
DQo+DQo+VGhhbmtzDQo+UGFydGhhDQo+DQo+Tm90ZToNCj4NCj4gVXNlIENhc2UgMTA6IEhpZ2gg
YXZhaWxhYmlsaXR5IGFuZCBjb250aW51b3VzIHJlY29yZGluZy4NCj4NCj4gICAgICBTcGVjaWZp
YyBkZXBsb3ltZW50IHNjZW5hcmlvcyBwcmVzZW50IGRpZmZlcmVudCByZXF1aXJlbWVudHMgZm9y
DQo+ICAgICAgc3lzdGVtIGF2YWlsYWJpbGl0eSwgZXJyb3IgaGFuZGxpbmcsIGV0Yy4sIGluY2x1
ZGluZyB0aGUNCj4gICAgICBmb2xsb3dpbmc6DQo+DQo+ICAgICAgbyAgQW4gU1JTIG11c3QgYWx3
YXlzIGJlIGF2YWlsYWJsZSBhdCBjYWxsIHNldHVwIHRpbWUuDQo+DQo+ICAgICAgbyAgTm8gbG9z
cyBvZiBtZWRpYSByZWNvcmRpbmcgY2FuIG9jY3VyLCBpbmNsdWRpbmcgZHVyaW5nIGZhaWx1cmUN
Cj4gICAgICAgICBvZiBhbiBTUlMuDQo+DQo+ICAgICAgbyAgVGhlIENvbW11bmljYXRpb24gU2Vz
c2lvbiBtdXN0IGJlIHRlcm1pbmF0ZWQgKG9yIHN1aXRhYmxlDQo+ICAgICAgICAgbm90aWZpY2F0
aW9uIGdpdmVuIHRvIHBhcnRpZXMpIGluIHRoZSBldmVudCBvZiBhIHJlY29yZGluZw0KPiAgICAg
ICAgIGZhaWx1cmUuDQo+DQo+DQo+UkVRLTAyMTogVGhlIG1lY2hhbmlzbSBNVVNUIE5PVCBwcmV2
ZW50IGhpZ2gtYXZhaWxhYmlsaXR5DQo+ICAgICAgZGVwbG95bWVudHMuDQo+DQo+PiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFtDQo+PiBNb2hhbiBSIChybW9oYW5yKQ0K
Pj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE0IDk6NTAgUE0NCj4+IFRvOiBHZXJi
ZW4gU3RhbQ0KPj4gQ2M6IGRpc3BhdGNoQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW2Rpc3Bh
dGNoXSBMb3NzbGVzcyBSZWNvcmRpbmcgaW4gU0lQUkVDDQo+PiANCj4+IEhpLA0KPj4gDQo+PiBQ
bGVhc2Ugc2VlIGlubGluZQ0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g
RnJvbTogR2VyYmVuIFN0YW0gPEdlcmJlbi5TdGFtQG5pY2UuY29tPg0KPj4gRGF0ZTogVGh1cnNk
YXksIDYgRmVicnVhcnkgMjAxNCA4OjQwIHBtDQo+PiBUbzogQ2lzY28gRW1wbG95ZWUgPHJtb2hh
bnJAY2lzY28uY29tPg0KPj4gQ2M6ICJkaXNwYXRjaEBpZXRmLm9yZyIgPGRpc3BhdGNoQGlldGYu
b3JnPg0KPj4gU3ViamVjdDogUkU6IFtkaXNwYXRjaF0gTG9zc2xlc3MgUmVjb3JkaW5nIGluIFNJ
UFJFQw0KPj4gDQo+PiA+SGV5IFJhbSwNCj4+ID4NCj4+ID5JIGhhdmUgaGFkIGFuIG9mZi1saW5l
IGRpc2N1c3Npb24gd2l0aCBBbmRyZXcgSHV0dG9uLCBjaGFpcm1hbiBvZiB0aGUNCj4+ID5TSVBS
RUMgZ3JvdXAuDQo+PiA+SGUgc3VnZ2VzdGVkIHRvIHBvc3QgdGhpcyBvbiB0aGUgSUVURiBkaXNw
YXRjaCBncm91cCBhcyBpdCBpcyBhIGdvb2QNCj4+ID50b3BpYyB0byBkaXNjdXNzIGluIHRoZSB0
ZWFtLg0KPj4gDQo+PiBPay4gSSB3YXMgbm90IGF3YXJlIG9mIHRoaXMuDQo+PiANCj4+ID4NCj4+
ID5XaGF0IHdvdWxkIEkgbmVlZCB0byBkbyB0byBiZW5kIHRoaXMgdG8gU0lQUkVDIFdHIGluc3Rl
YWQgb2YgRGlzcGF0Y2g/DQo+PiA+DQo+PiA+UmVnYXJkcywNCj4+ID4NCj4+ID5HZXJiZW4NCj4+
ID4NCj4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPkZyb206IFJhbSBNb2hhbiBS
IChybW9oYW5yKSBbbWFpbHRvOnJtb2hhbnJAY2lzY28uY29tXQ0KPj4gPlNlbnQ6IGRvbmRlcmRh
ZyA2IGZlYnJ1YXJpIDIwMTQgMTU6NDUNCj4+ID5UbzogR2VyYmVuIFN0YW0NCj4+ID5DYzogZGlz
cGF0Y2hAaWV0Zi5vcmcNCj4+ID5TdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBMb3NzbGVzcyBSZWNv
cmRpbmcgaW4gU0lQUkVDDQo+PiA+DQo+PiA+SGksDQo+PiA+DQo+PiA+SXMgdGhlcmUgYSByZWFz
b24gd2h5IHlvdSB3YW50IHRvIGhhdmUgdGhpcyBkaXNjdXNzaW9uIGluIGRpc3BhdGNoDQo+PiA+
YW5kIG5vdCBpbiBTSVBSRUMgV0cgd2hpY2ggaXMgbWVhbnQgdG8gZGlzY3VzcyB0aGUgaXNzdWVz
IGFyb3VuZCBTSVANCj4+ID5yZWNvcmRpbmcgPw0KPj4gPklmIHlvdSBkb27CuXQgaGF2ZSBhbnkg
c3BlY2lmaWMgcmVhc29uIHRvIGRvIGl0IGhlcmUgeW91IG1heSB3YW50IHRvDQo+PiBzdGFydA0K
Pj4gPnRoaXMgZGlzY3Vzc2lvbiBpbiBTSVBSRUMgV0cuDQo+PiA+DQo+PiA+SSBkbyBoYXZlIHNv
bWUgY29tbWVudHMgb24gdGhpcyB0b3BpYyBidXQgSSB0aGluayBTSVBSRUMgV0cgaXMgdGhlDQo+
PiByaWdodA0KPj4gPnBsYWNlIHRvIGhhdmUgdGhvc2UgZGlzY3Vzc2lvbnMuDQo+PiA+DQo+PiA+
DQo+PiA+UmVnYXJkcywNCj4+ID5SYW0NCj4+ID4NCj4+ID5Gcm9tOiAgR2VyYmVuIFN0YW0gPEdl
cmJlbi5TdGFtQG5pY2UuY29tPg0KPj4gPkRhdGU6ICBUaHVyc2RheSwgNiBGZWJydWFyeSAyMDE0
IDM6NTggcG0NCj4+ID5UbzogIEdlcmJlbiBTdGFtIDxHZXJiZW4uU3RhbUBuaWNlLmNvbT4NCj4+
ID5DYzogICJkaXNwYXRjaEBpZXRmLm9yZyIgPGRpc3BhdGNoQGlldGYub3JnPg0KPj4gPlN1Ympl
Y3Q6ICBbZGlzcGF0Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBTSVBSRUMNCj4+ID4NCj4+ID4N
Cj4+ID5EZWFyIERJU1BBVENIIGdyb3VwLA0KPj4gPg0KPj4gPlNJUFJFQyBpcyBhIGdyZWF0IGlu
aXRpYXRpdmUgdG8gc3RhbmRhcmRpemUgdGhlIGludGVyZmFjZSBmb3INCj4+IGNhcHR1cmluZw0K
Pj4gPkNvbW11bmljYXRpb24gU2Vzc2lvbnMuDQo+PiA+U2Vzc2lvbiBSZWNvcmRpbmcgaXMgYmVj
b21pbmcgbW9yZSBhbmQgbW9yZSBjcml0aWNhbCBkdWUgdG8NCj4+ID5Db21wbGlhbmNlIGFuZCBy
ZWd1bGF0b3J5IGNoYW5nZXMgb3ZlciB0aGUgbGFzdCB5ZWFycy4NCj4+ID4NCj4+ID5UaGUgY29t
cGxpYW5jZSBtYXJrZXQgaXMgcmVxdWVzdGluZyBtb3JlIHRoYW4gY2FwdHVyZSBvbmx5IHRoZXNl
IGRheXMNCj4+ID5Db25maXJtYXRpb24gaXMgbmVlZGVkIHRvIGFja25vd2xlZGdlIHRoZSBlbnRp
cmUgQ29tbXVuaWNhdGlvbg0KPj4gPlNlc3Npb24gd2FzIGNhcHR1cmVkIGNvcnJlY3RseS4NCj4+
ID5SVENQIFJlcG9ydHMgKHJmYzM2MTEpIHdpbGwgaGVscCB0byBjb25maXJtIGNvbXBsZXRlIGhh
bmRvdmVyIG9mIFJUUA0KPj4gPmNvbnRlbnQuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+TmV3IHJl
cXVpcmVtZW50IGlzIMWSbG9zc2xlc3PCuSBTZXNzaW9uIENhcHR1cmluZy4NCj4+IA0KPj4gV2h5
IGlzIHRoaXMgYSBuZXcgcmVxdWlyZW1lbnQgPyBSRkMgNjM0MSAoU0lQUkVDIHJlcXVpcmVtZW50
cykgYWxyZWFkeQ0KPj4gaGFzIGEgcmVxdWlyZW1lbnQgZm9yIExvc3NsZXNzIHJlY29yZGluZy4g
U2VlIFJFUSAwMDUuDQo+PiANCj4+IA0KPj4gPkxvc3NsZXNzIGluZGljYXRpbmcgaGFuZG92ZXIg
b2YgY29udGVudCAoUlRQKSBpcyBhY2tub3dsZWRnZWQgYnkgdGhlDQo+PiA+cmVjZWl2ZXIgQU5E
IGluIGNhc2Ugb2YgcmVjZWl2aW5nIGlzc3VlcywgdGhlIHNlbmRlciB3aWxsIHJlc2VuZC4NCj4+
ID5SZWFzb25zIGZvciBsb3NzIG1heSBiZSBVRFAgcGFja2V0IGxvc3Mgb3IgcmVjZWl2ZXIgZmFp
bGluZyhvdmVyKSBhbmQNCj4+ID50ZW1wb3Jhcnkgbm90IGFibGUgdG8gYWNjZXB0IGNvbnRlbnQu
DQo+PiA+Q3VycmVudCBhcHByb2FjaCB0byBhZGRyZXNzIHRoaXMgxZJsb3NzbGVzc8K5IHJlcXVp
cmVtZW50IGlzIHVzaW5nIDINCj4+ID5pbmRlcGVuZGVudCBwYXJhbGxlbCByZWNlaXZlcnMuDQo+
PiANCj4+IFRoZXJlIG1heSBiZSBvdGhlciBhcHByb2FjaGVzIHdlbGwuIEZvciBleGFtcGxlIGFu
IFNSQyBtYXkgYnVmZmVyIGZvcg0KPj4gYSBzbWFsbCBkdXJhdGlvbiB0byB0YWtlIGNhcmUgb2Yg
dGhlIGxvc3MuIFR3byBwYXJhbGxlbCByZWNlaXZlcnMNCj4+IHN0aWxsIGRvZXMgbm90IGd1YXJh
bnRlZSB0aGF0IHJlY29yZGluZyBpcyBsb3NlbGVzcyBhcyB5b3UgY2FuIGhhdmUNCj4+IFVEUCBw
YWNrZXQgbG9zcyBvbiBib3RoIHBhdGhzLg0KPj4gDQo+PiA+DQo+PiA+VGhpcyByZXF1aXJlcyB0
aGUgc2VuZGVyIHRvIHNlbmQgMiBpbmRpdmlkdWFsIHN0cmVhbXMsIGluIGZhY3QgMg0KPj4gPmlu
ZGVwZW5kZW50IFNJUFJFQyBzZXNzaW9ucy4NCj4+ID4NCj4+ID5Ob3Qgc3VyZSBpZiB0aGlzIGlz
IGNvdmVyZWQgY3VycmVudGx5IGFzIHN1cHBvcnRlZCBTSVBSRUMgZGVwbG95bWVudC4NCj4+IA0K
Pj4gDQo+PiBDdXJyZW50IFNJUFJFQyBkb2VzIG5vdCBoYXZlIGFueSBzdWNoIGNvbnN0cmFpbnRz
LiBEZXBlbmRpbmcgb24geW91cg0KPj4gaW1wbGVtZW50YXRpb24gbW9kZWwgeW91IGNhbiBoYXZl
IHRoZSBzYW1lIENTIHJlY29yZGVkIGJ5IG11bHRpcGxlIFNSQw0KPj4gb3IgaGF2ZSBzYW1lIFNS
QyBkbyBtdWx0aXBsZSByZWNvcmRpbmdzIG9mIHNhbWUgQ1MuDQo+PiANCj4+IFJlZ2FyZHMsDQo+
PiBSYW0NCj4+IA0KPj4gPiBXZSBkbyBzZWUgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIFNJUFJF
QyBzdXBwb3J0aW5nIGl0Lg0KPj4gPkFsdGVybmF0aXZlIGlzIHF1aWNrIGZhaWxvdmVyIGF0IHJl
Y2VpdmVyIGluIGNhc2Ugb2YgZmFpbHVyZSBidXQgYXMNCj4+ID5zZW5kZXIgd2lsbCBzZW5kIG9u
bHkgb25jZSwgdGhpcyBtYXkgbGVhZCB0byBsb3NzIGR1cmluZyBmYWlsb3Zlci4NCj4+ID4NCj4+
ID5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgcmZjIGNvdmVyaW5nIGxvc3NsZXNzIGNvbnRlbnQgaGFu
ZG92ZXIsIGJ1dA0KPj4gdGhlcmUNCj4+ID5tYXkgYmUgc3RhbmRhcmRzIGNvdmVyaW5nIHRoaXMg
YWxyZWFkeS4NCj4+ID4NCj4+ID4NCj4+ID5Mb29raW5nIGZvcndhcmQgdG8gZGlzY3Vzc2lvbiBv
biB0aGUgbWFpbGluZyBsaXN0LiBJIG1heSBiZSBhdCB0aGUNCj4+IExvbmRvbg0KPj4gPmV2ZW50
Lg0KPj4gPg0KPj4gPlJlZ2FyZHMsDQo+PiA+DQo+PiA+R2VyYmVuIFN0YW0sDQo+PiA+TklDRSBT
eXN0ZW1zDQo+PiA+DQo+PiA+DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+PiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+IGRpc3BhdGNo
QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3Bh
dGNoDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj5kaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj5kaXNwYXRjaEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0K


From andrew.hutton@unify.com  Tue Feb 11 05:58:02 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 C6D271A0310 for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 05:58:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 yMgTSsxzy9mq for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 05:57:56 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CFE841A00BC for <siprec@ietf.org>; Tue, 11 Feb 2014 05:57:55 -0800 (PST)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id A2D661EB84A4 for <siprec@ietf.org>; Tue, 11 Feb 2014 14:57:54 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.100]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 14:57:54 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: SIPREC IETF89 Meeting in London.
Thread-Index: Ac8g7nFoAcJQS01VTjWB+CwWU8Xf3QGPYGkQ
Date: Tue, 11 Feb 2014 13:57:53 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17CF0040@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF17CE2D41@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17CE2D41@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_9F33F40F6F2CD847824537F3C4E37DDF17CF0040MCHP04MSXglobal_"
MIME-Version: 1.0
Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
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, 11 Feb 2014 13:58:02 -0000

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

Any more requests for agenda time during the SIPREC meeting.

So far the only requests we have are from Paul Kyzivat and Gerben Stam rela=
ting to future work.

Regards
Andy



From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: 03 February 2014 14:45
To: siprec@ietf.org
Subject: [siprec] SIPREC IETF89 Meeting in London.

Hi All,

If you would like agenda time in the SIPREC meeting at IETF89 please e-mail=
 the chairs (siprec-chairs@tools.ietf.org<mailto:siprec-chairs@tools.ietf.o=
rg>) .

SIPREC has been allocated the dreaded final meeting slot in the DRAFT agend=
a on Friday March the 7th (See https://datatracker.ietf.org/meeting/89/agen=
da.html).

Of course the draft agenda can change so don't make plans based on this.

Regards
Andy (SIPREC Co-Chair).


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Any more requests for age=
nda time during the SIPREC meeting.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So far the only requests =
we have are from Paul Kyzivat and Gerben Stam relating to future work.<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Andy<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> siprec [=
mailto:siprec-bounces@ietf.org]
<b>On Behalf Of </b>Hutton, Andrew<br>
<b>Sent:</b> 03 February 2014 14:45<br>
<b>To:</b> siprec@ietf.org<br>
<b>Subject:</b> [siprec] SIPREC IETF89 Meeting in London.<o:p></o:p></span>=
</p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Hi All,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">If you would like agenda time in the SI=
PREC meeting at IETF89 please e-mail the chairs (<a href=3D"mailto:siprec-c=
hairs@tools.ietf.org">siprec-chairs@tools.ietf.org</a>) .<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">SIPREC has been allocated the dreaded f=
inal meeting slot in the
<b>DRAFT</b> agenda on Friday March the 7</span><sup><span style=3D"font-si=
ze:7.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">th</span><=
/sup><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;"> (See
<a href=3D"https://datatracker.ietf.org/meeting/89/agenda.html">https://dat=
atracker.ietf.org/meeting/89/agenda.html</a>).<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Of course the draft agenda can change s=
o don&#8217;t make plans based on this.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#2A3136">&nbsp;</span><span style=
=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:9.0pt;font-family:&quot;=
Arial&quot;,&quot;sans-serif&quot;;color:#2A3136">Regards</span></b><span s=
tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=
uot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:9.0pt;font-family:&quot;=
Arial&quot;,&quot;sans-serif&quot;;color:#2A3136">Andy (SIPREC Co-Chair).</=
span></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_9F33F40F6F2CD847824537F3C4E37DDF17CF0040MCHP04MSXglobal_--


From internet-drafts@ietf.org  Tue Feb 11 06:44:32 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 05B0C1A0338; Tue, 11 Feb 2014 06:44:32 -0800 (PST)
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 NzSVxcgQkPWR; Tue, 11 Feb 2014 06:44:30 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1908D1A0326; Tue, 11 Feb 2014 06:44:30 -0800 (PST)
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.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140211144429.14631.32283.idtracker@ietfa.amsl.com>
Date: Tue, 11 Feb 2014 06:44:29 -0800
Cc: siprec@ietf.org
Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-14.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: Tue, 11 Feb 2014 14:44:32 -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 Metadata
        Authors         : Ram Mohan Ravindranath
                          Parthasarathi Ravindran
                          Paul Kyzivat
	Filename        : draft-ietf-siprec-metadata-14.txt
	Pages           : 30
	Date            : 2014-02-11

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 describes the metadata model as
   viewed by Session Recording Server(SRS) and the Recording metadata
   format.


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

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

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


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 rmohanr@cisco.com  Tue Feb 11 06:49:15 2014
Return-Path: <rmohanr@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 74F3F1A03CC for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 06:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.049
X-Spam-Level: 
X-Spam-Status: No, score=-15.049 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.548, 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 Z6F-LPil1XnY for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 06:49:12 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A1C3D1A0338 for <siprec@ietf.org>; Tue, 11 Feb 2014 06:49:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2766; q=dns/txt; s=iport; t=1392130152; x=1393339752; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=692tlkyBdjIxtLLaVjG2zxaQcu4uYHIE7IkcEFoQbH4=; b=j0n1rRZirP7/KJyBTBvw7BxskCkBfE2Y81QHoje/ojbhAPUOUc5SIxID z8fV1W91dtMgbgv0zj4/as0h0U6Fo9973trMXeXJZGb/Fyp/b6F2sSJM+ s6mTuZahC9KFDxtzIpWGlzVATTIgPeMCmmicL5rKNZryfyIoAlP3DgyTf k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMFACY3+lKtJV2a/2dsb2JhbABagww4UQa+Fk+BDxZ0giUBAQEEAQEBNzQXBAIBCBEDAQIfECcLHQgCBBMJh3wIBcg7F44oAQFRBQaEMgSYKoEykG6DLYFxOQ
X-IronPort-AV: E=Sophos;i="4.95,825,1384300800"; d="scan'208";a="303093899"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 11 Feb 2014 14:49:12 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1BEnBRS013480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <siprec@ietf.org>; Tue, 11 Feb 2014 14:49:11 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.191]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 08:49:11 -0600
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-14.txt
Thread-Index: AQHPJzhsVLOWf98/fkO1jtxs4IxJnw==
Date: Tue, 11 Feb 2014 14:49:11 +0000
Message-ID: <CF203617.7AE7E%rmohanr@cisco.com>
References: <20140211144429.14631.32283.idtracker@ietfa.amsl.com>
In-Reply-To: <20140211144429.14631.32283.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.65.65.205]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <53E657C7569DFA4087DDE02A84CA8C8E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-14.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, 11 Feb 2014 14:49:15 -0000

This revision has following changes:

1) Review from Paul and edits to the language part. This is a action item
from this mail thread -
http://www.ietf.org/mail-archive/web/siprec/current/msg03854.html

2) Incorporated text in Security Considerations per the discussions in the
mailer. See the thread here -
http://www.ietf.org/mail-archive/web/siprec/current/msg03888.html

3) Added the representation of participant capabilities taken from RFC
4235 to SIPREC Schema. I copied the schema instead of referring it. Look
for the mail thread here
http://www.ietf.org/mail-archive/web/siprec/current/msg03879.html

Please review and provide your comments.

Regards,
Ram



-----Original Message-----
From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
Date: Tuesday, 11 February 2014 8:14 pm
To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Cc: "siprec@ietf.org" <siprec@ietf.org>
Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-14.txt

>
>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
>Metadata
>        Authors         : Ram Mohan Ravindranath
>                          Parthasarathi Ravindran
>                          Paul Kyzivat
>	Filename        : draft-ietf-siprec-metadata-14.txt
>	Pages           : 30
>	Date            : 2014-02-11
>
>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 describes the metadata model as
>   viewed by Session Recording Server(SRS) and the Recording metadata
>   format.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-siprec-metadata-14
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-14
>
>
>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 pkyzivat@alum.mit.edu  Tue Feb 11 08:27:16 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 AB2F01A01FD for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 08:27:16 -0800 (PST)
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 qypNbrr9qymx for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 08:27:15 -0800 (PST)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 101081A05D7 for <siprec@ietf.org>; Tue, 11 Feb 2014 08:27:13 -0800 (PST)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id R0Dw1n0071swQuc554TDJu; Tue, 11 Feb 2014 16:27:13 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id R4T21n00F3ZTu2S3b4TDUX; Tue, 11 Feb 2014 16:27:13 +0000
Message-ID: <52FA4F56.5060508@alum.mit.edu>
Date: Tue, 11 Feb 2014 11:27:02 -0500
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.3.0
MIME-Version: 1.0
To: siprec@ietf.org
References: <9F33F40F6F2CD847824537F3C4E37DDF17CE2D41@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF17CF0040@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17CF0040@MCHP04MSX.global-ad.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=q20121106; t=1392136033; bh=RuHKIqB447AHPxoavJkUb/1auui/ORkryGFhO/mAJOY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=d0PSyufnCxVIt4x2s3D3ALc5757aXUiGA88PjbTt4Im7i0i2ZId+d6wodDUVUN6J7 nVXfeD60AAlo9vUpL9gVHqdVfqmYcIvffQ2hdW/cghRxGlBihb75ctPygAiaAKp+Pw mmdkdGCl3BskpbRZcz/pGfiQIEE+5yGZy75qcxvo5nwqXksJygVUzOwlB92FVIpW30 n8wgd4EUfct7G1jusXglpKeaOnJf9qHml9ppg0h1R2nptq6D2XvApiEYsEaVTHy2If uDW0i3UCpLIiJJ73L1etzp+RMMlvtdaGqGPTjufGFUo+Mt5R7T6rnXS7anJsWORAWf mzjlg2fwQnDfQ==
Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
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, 11 Feb 2014 16:27:16 -0000

Andy,

Ram just posted a new version of the metadata, and an email that 
explains the changes.

I don't know if you want to use meeting time on it or not.
We think the doc is ready for WGLC. If you agree, that could start now 
and end before London, and we could discuss the results. Or it could 
begin now and end after London, and we could discuss comments received 
at the meeting, or we could wait until the meeting to start WGLC and use 
the meeting to encourage people to comment.

At your pleasure!

	Thanks,
	Paul

On 2/11/14 8:57 AM, Hutton, Andrew wrote:
> Any more requests for agenda time during the SIPREC meeting.
>
> So far the only requests we have are from Paul Kyzivat and Gerben Stam
> relating to future work.
>
> Regards
>
> Andy
>
> *From:*siprec [mailto:siprec-bounces@ietf.org] *On Behalf Of *Hutton, Andrew
> *Sent:* 03 February 2014 14:45
> *To:* siprec@ietf.org
> *Subject:* [siprec] SIPREC IETF89 Meeting in London.
>
> Hi All,
>
> If you would like agenda time in the SIPREC meeting at IETF89 please
> e-mail the chairs (siprec-chairs@tools.ietf.org
> <mailto:siprec-chairs@tools.ietf.org>) .
>
> SIPREC has been allocated the dreaded final meeting slot in the *DRAFT*
> agenda on Friday March the 7^th (See
> https://datatracker.ietf.org/meeting/89/agenda.html).
>
> Of course the draft agenda can change so don�t make plans based on this.
>
> *Regards*
>
> *Andy (SIPREC Co-Chair).*
>
>
>
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>


From eckelcu@cisco.com  Tue Feb 11 08:47:37 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 A87471A061A for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 08:47:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, 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 134R8FWXJIXG for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 08:47:34 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA3C1A05E0 for <siprec@ietf.org>; Tue, 11 Feb 2014 08:47:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10334; q=dns/txt; s=iport; t=1392137253; x=1393346853; h=from:to:subject:date:message-id:mime-version; bh=IUYBkG4Ojnif1wIToamZ1vdgLmSjZYyI9NinuoJzvtU=; b=cRXlLJJNQwy54t+1jTdgXRkBrsDuvAdes8qsjv8ducXfbtrTrF+NlAN/ HzQFQ9eFf9ZP4F0O/87xv6PUxK6RiwTKaUZEeyyR5xiDDYvN54MAF5AzW MADRP8SGP7c4+zZ+nDb7KVkg+hgp0ikMJ8mDD1Xn7jAKFU4gdjjRxRkS9 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAApT+lKtJXG9/2dsb2JhbABagkhEOFe/BIESFnSCJQEBAQQtXgEIEQMBAQEoORQJCgQBEogEAQ3JKhMEjiUwEw0KhDkEmCqSIIMtgio
X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208,217";a="19587420"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-3.cisco.com with ESMTP; 11 Feb 2014 16:47:32 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1BGlWKN000803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 16:47:32 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 10:47:32 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] SIPREC IETF89 Meeting in London.
Thread-Index: AQHPJ0j1AcJQS01VTjWB+CwWU8Xf3Q==
Date: Tue, 11 Feb 2014 16:47:32 +0000
Message-ID: <CF1F925F.1D800%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: [171.68.20.19]
Content-Type: multipart/alternative; boundary="_000_CF1F925F1D800eckelcuciscocom_"
MIME-Version: 1.0
Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
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, 11 Feb 2014 16:47:37 -0000

--_000_CF1F925F1D800eckelcuciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Henry and I synched up on the protocol draft. I will update it with the cha=
nges that were agreed to on the list. I believe there are some open discuss=
ion items that I will collect as I review the archives. Although I will try=
 to close on these on the list, planning a brief slot on the agenda for pro=
tocol draft discussion seems worthwhile to me.

Cheers,
Charles

From: <Hutton>, Andrew <andrew.hutton@unify.com<mailto:andrew.hutton@unify.=
com>>
Date: Tuesday, February 11, 2014 5:57 AM
To: "siprec@ietf.org<mailto:siprec@ietf.org>" <siprec@ietf.org<mailto:sipre=
c@ietf.org>>
Subject: Re: [siprec] SIPREC IETF89 Meeting in London.

Any more requests for agenda time during the SIPREC meeting.

So far the only requests we have are from Paul Kyzivat and Gerben Stam rela=
ting to future work.

Regards
Andy



From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: 03 February 2014 14:45
To: siprec@ietf.org<mailto:siprec@ietf.org>
Subject: [siprec] SIPREC IETF89 Meeting in London.

Hi All,

If you would like agenda time in the SIPREC meeting at IETF89 please e-mail=
 the chairs (siprec-chairs@tools.ietf.org<mailto:siprec-chairs@tools.ietf.o=
rg>) .

SIPREC has been allocated the dreaded final meeting slot in the DRAFT agend=
a on Friday March the 7th (See https://datatracker.ietf.org/meeting/89/agen=
da.html).

Of course the draft agenda can change so don=92t make plans based on this.

Regards
Andy (SIPREC Co-Chair).


--_000_CF1F925F1D800eckelcuciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <430295CE9036FE4F830F5F5C58BE9F30@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</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>Henry and I synched up on the protocol draft. I will update it with th=
e changes that were agreed to on the list. I believe there are some open di=
scussion items that I will collect as I review the archives. Although I wil=
l try to close on these on the list,
 planning a brief slot on the agenda for protocol draft discussion seems wo=
rthwhile to me.</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>Tuesday, February 11, 2014 5:=
57 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>Re: [siprec] SIPREC IETF89=
 Meeting in London.<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 xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Any more requests for agenda time =
during the SIPREC meeting.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">So far the only requests we have a=
re from Paul Kyzivat and Gerben Stam relating to future work.<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Regards<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Andy<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: Taho=
ma, sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; font-fami=
ly: Tahoma, sans-serif; "> siprec [<a href=3D"mailto:siprec-bounces@ietf.or=
g">mailto:siprec-bounces@ietf.org</a>]
<b>On Behalf Of </b>Hutton, Andrew<br>
<b>Sent:</b> 03 February 2014 14:45<br>
<b>To:</b> <a href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br>
<b>Subject:</b> [siprec] SIPREC IETF89 Meeting in London.<o:p></o:p></span>=
</p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; ">Hi All,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; ">If you would like agenda time in the SIPREC meeting at IETF=
89 please e-mail the chairs (<a href=3D"mailto:siprec-chairs@tools.ietf.org=
">siprec-chairs@tools.ietf.org</a>) .<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; ">SIPREC has been allocated the dreaded final meeting slot in=
 the
<b>DRAFT</b> agenda on Friday March the 7</span><sup><span style=3D"font-si=
ze: 7.5pt; font-family: Calibri, sans-serif; ">th</span></sup><span style=
=3D"font-size: 11pt; font-family: Calibri, sans-serif; "> (See
<a href=3D"https://datatracker.ietf.org/meeting/89/agenda.html">https://dat=
atracker.ietf.org/meeting/89/agenda.html</a>).<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; ">Of course the draft agenda can change so don=92t make plans=
 based on this.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(42, 49, 54); ">&nbsp;</span><span style=3D"font-si=
ze: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size: 9pt; font-family: Arial=
, sans-serif; color: rgb(42, 49, 54); ">Regards</span></b><span style=3D"fo=
nt-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size: 9pt; font-family: Arial=
, sans-serif; color: rgb(42, 49, 54); ">Andy (SIPREC Co-Chair).</span></b><=
span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o=
:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; ">&nbsp;<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>

--_000_CF1F925F1D800eckelcuciscocom_--


From br@brianrosen.net  Tue Feb 11 09:02:25 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 331341A05CD for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 09:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Level: 
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NnRQN49o3Jqb for <siprec@ietfa.amsl.com>; Tue, 11 Feb 2014 09:02:21 -0800 (PST)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6E1A0630 for <siprec@ietf.org>; Tue, 11 Feb 2014 09:02:21 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id lx4so669859iec.15 for <siprec@ietf.org>; Tue, 11 Feb 2014 09:02:21 -0800 (PST)
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=XbncPE3Dnbua2gBm0141CpoetRZv5nQuoGukQt01fvs=; b=Vj7WOnCa5TxI2zKKmzO3ByeOa+HxtXuwwPz8JHnXrUwxfvxCV1svn66Pt/XQY8oq0S cGNmTdCBIEYC3Vvm8nK+PBagc8F177keKjAOem4ClG5mvM+oQ1lN+drihPNzh8g137qa L3yRouHda5eNRkHbWR0aDB6GtcmAEvjK4IswnVMa4T4qlzDiT9EqG50Fjb43X+/OhAN1 J5KNbcf11cWZgZYqhaCIftL3O7UI3iIqV22QlKNjQY8dQngueMOHWOiGxrWPEP7+BnaY QbSqUkKOVtwwcE4ClewNFFetgMFvOThfoh9aLyR5MAD2fxLH2btW1Jbp4Q4xo9pbe3vX Wzeg==
X-Gm-Message-State: ALoCoQlY5s5ho9hIqxhgHYEEMBZFFDHye+tVOn0WIa3TFfkH077v0BcKLJ5aIaKEs1fZKDbQmoKf
X-Received: by 10.50.97.6 with SMTP id dw6mr20475748igb.21.1392138141065; Tue, 11 Feb 2014 09:02:21 -0800 (PST)
Received: from [10.33.193.26] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id qb3sm55730511igb.7.2014.02.11.09.02.19 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 09:02:20 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_EF8B73DA-5950-4EE2-9CBF-9ABC2E9477EB"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <CF1F925F.1D800%eckelcu@cisco.com>
Date: Tue, 11 Feb 2014 12:02:18 -0500
Message-Id: <15A1E9D5-9F34-43E5-ABF8-9387FDD3F167@brianrosen.net>
References: <CF1F925F.1D800%eckelcu@cisco.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
X-Mailer: Apple Mail (2.1827)
Cc: "siprec@ietf.org" <siprec@ietf.org>
Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
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, 11 Feb 2014 17:02:25 -0000

--Apple-Mail=_EF8B73DA-5950-4EE2-9CBF-9ABC2E9477EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Let=92s do that.

Brian

On Feb 11, 2014, at 11:47 AM, Charles Eckel (eckelcu) =
<eckelcu@cisco.com> wrote:

> Henry and I synched up on the protocol draft. I will update it with =
the changes that were agreed to on the list. I believe there are some =
open discussion items that I will collect as I review the archives. =
Although I will try to close on these on the list, planning a brief slot =
on the agenda for protocol draft discussion seems worthwhile to me.
>=20
> Cheers,
> Charles
>=20
> From: <Hutton>, Andrew <andrew.hutton@unify.com>
> Date: Tuesday, February 11, 2014 5:57 AM
> To: "siprec@ietf.org" <siprec@ietf.org>
> Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
>=20
>> Any more requests for agenda time during the SIPREC meeting.
>> =20
>> So far the only requests we have are from Paul Kyzivat and Gerben =
Stam relating to future work.
>> =20
>> Regards
>> Andy
>> =20
>> =20
>> =20
>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, =
Andrew
>> Sent: 03 February 2014 14:45
>> To: siprec@ietf.org
>> Subject: [siprec] SIPREC IETF89 Meeting in London.
>> =20
>> Hi All,
>> =20
>> If you would like agenda time in the SIPREC meeting at IETF89 please =
e-mail the chairs (siprec-chairs@tools.ietf.org) .
>> =20
>> SIPREC has been allocated the dreaded final meeting slot in the DRAFT =
agenda on Friday March the 7th (See =
https://datatracker.ietf.org/meeting/89/agenda.html).
>> =20
>> Of course the draft agenda can change so don=92t make plans based on =
this.
>> =20
>> Regards
>> Andy (SIPREC Co-Chair).
>> =20
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec


--Apple-Mail=_EF8B73DA-5950-4EE2-9CBF-9ABC2E9477EB
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;">Let=92s =
do that.<div><br></div><div>Brian</div><div><br><div style=3D""><div>On =
Feb 11, 2014, at 11:47 AM, Charles Eckel (eckelcu) &lt;<a =
href=3D"mailto:eckelcu@cisco.com">eckelcu@cisco.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div style=3D"font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
font-size: 14px; font-family: Calibri, sans-serif;"><div>Henry and I =
synched up on the protocol draft. I will update it with the changes that =
were agreed to on the list. I believe there are some open discussion =
items that I will collect as I review the archives. Although I will try =
to close on these on the list, planning a brief slot on the agenda for =
protocol draft discussion seems worthwhile to =
me.</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; border-width: 1pt medium medium; =
border-style: solid none none; padding: 3pt 0in 0in; border-top-color: =
rgb(181, 196, 223);"><span style=3D"font-weight: bold;">From:<span =
class=3D"Apple-converted-space">&nbsp;</span></span>&lt;Hutton&gt;, =
Andrew &lt;<a href=3D"mailto:andrew.hutton@unify.com" style=3D"color: =
purple; text-decoration: =
underline;">andrew.hutton@unify.com</a>&gt;<br><span style=3D"font-weight:=
 bold;">Date:<span =
class=3D"Apple-converted-space">&nbsp;</span></span>Tuesday, February =
11, 2014 5:57 AM<br><span style=3D"font-weight: bold;">To:<span =
class=3D"Apple-converted-space">&nbsp;</span></span>"<a =
href=3D"mailto:siprec@ietf.org" style=3D"color: purple; text-decoration: =
underline;">siprec@ietf.org</a>" &lt;<a href=3D"mailto:siprec@ietf.org" =
style=3D"color: purple; text-decoration: =
underline;">siprec@ietf.org</a>&gt;<br><span style=3D"font-weight: =
bold;">Subject:<span =
class=3D"Apple-converted-space">&nbsp;</span></span>Re: [siprec] SIPREC =
IETF89 Meeting in London.<br></div><div><br></div><blockquote =
id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"border-left-color: =
rgb(181, 196, 223); border-left-width: 5px; border-left-style: solid; =
padding: 0px 0px 0px 5px; margin: 0px 0px 0px 5px;" type=3D"cite"><div =
xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><div lang=3D"EN-US" =
link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" style=3D"page: =
WordSection1;"><div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif;"><span style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Any more =
requests for agenda time during the SIPREC =
meeting.<o:p></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125);"><o:p>&nbsp;</o:p></span></div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', =
serif;"><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125);">So far the only requests we have =
are from Paul Kyzivat and Gerben Stam relating to future =
work.<o:p></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125);"><o:p>&nbsp;</o:p></span></div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', =
serif;"><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, =
125);">Regards<o:p></o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125);">Andy<o:p></o:p></span></div><div style=3D"margin: 0cm =
0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', =
serif;"><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125);"><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(31, 73, =
125);"><o:p>&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125);"><o:p>&nbsp;</o:p></span></div><div =
style=3D"border-style: none none none solid; border-left-color: blue; =
border-left-width: 1.5pt; padding: 0cm 0cm 0cm 4pt;"><div><div =
style=3D"border-style: solid none none; border-top-color: rgb(181, 196, =
223); border-top-width: 1pt; padding: 3pt 0cm 0cm;"><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', =
serif;"><b><span style=3D"font-size: 10pt; font-family: Tahoma, =
sans-serif;">From:</span></b><span style=3D"font-size: 10pt; =
font-family: Tahoma, sans-serif;"><span =
class=3D"Apple-converted-space">&nbsp;</span>siprec [<a =
href=3D"mailto:siprec-bounces@ietf.org" style=3D"color: purple; =
text-decoration: underline;">mailto:siprec-bounces@ietf.org</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><b>On Behalf Of<span =
class=3D"Apple-converted-space">&nbsp;</span></b>Hutton, =
Andrew<br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>03 February 2014 =
14:45<br><b>To:</b><span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:siprec@ietf.org" style=3D"color: purple; text-decoration: =
underline;">siprec@ietf.org</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>[siprec] SIPREC IETF89 =
Meeting in London.<o:p></o:p></span></div></div></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><o:p>&nbsp;</o:p></div><div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', =
serif;"><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif;">Hi All,<o:p></o:p></span></div></div><div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif;">&nbsp;<o:p></o:p></span></div></div><div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif;">If you would like agenda time in the SIPREC =
meeting at IETF89 please e-mail the chairs (<a =
href=3D"mailto:siprec-chairs@tools.ietf.org" style=3D"color: purple; =
text-decoration: underline;">siprec-chairs@tools.ietf.org</a>) =
.<o:p></o:p></span></div></div><div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif;">&nbsp;<o:p></o:p></span></div></div><div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif;">SIPREC has been allocated the dreaded final =
meeting slot in the<span =
class=3D"Apple-converted-space">&nbsp;</span><b>DRAFT</b><span =
class=3D"Apple-converted-space">&nbsp;</span>agenda on Friday March the =
7</span><sup><span style=3D"font-size: 7.5pt; font-family: Calibri, =
sans-serif;">th</span></sup><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif;"><span =
class=3D"Apple-converted-space">&nbsp;</span>(See<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"https://datatracker.ietf.org/meeting/89/agenda.html" =
style=3D"color: purple; text-decoration: =
underline;">https://datatracker.ietf.org/meeting/89/agenda.html</a>).<o:p>=
</o:p></span></div></div><div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif;">&nbsp;<o:p></o:p></span></div></div><div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif;">Of course the draft agenda can change so don=92t =
make plans based on this.<o:p></o:p></span></div></div><div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(42, 49, 54);">&nbsp;</span><span =
style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif;"><o:p></o:p></span></div></div><div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', =
serif;"><b><span style=3D"font-size: 9pt; font-family: Arial, =
sans-serif; color: rgb(42, 49, 54);">Regards</span></b><span =
style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif;"><o:p></o:p></span></div></div><div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', =
serif;"><b><span style=3D"font-size: 9pt; font-family: Arial, =
sans-serif; color: rgb(42, 49, 54);">Andy (SIPREC =
Co-Chair).</span></b><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif;"><o:p></o:p></span></div></div><div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, =
sans-serif;">&nbsp;<o:p></o:p></span></div></div></div></div></div></div><=
/blockquote></span>_______________________________________________<br>sipr=
ec mailing list<br><a =
href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br>https://www.ietf.or=
g/mailman/listinfo/siprec</div></blockquote></div><br></div></body></html>=

--Apple-Mail=_EF8B73DA-5950-4EE2-9CBF-9ABC2E9477EB--


From internet-drafts@ietf.org  Tue Feb 11 18:45:55 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 DCF971A07EE; Tue, 11 Feb 2014 18:45:55 -0800 (PST)
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 9_cuCBFPJyj1; Tue, 11 Feb 2014 18:45:54 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0F51A0771; Tue, 11 Feb 2014 18:45:54 -0800 (PST)
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.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140212024554.16525.45343.idtracker@ietfa.amsl.com>
Date: Tue, 11 Feb 2014 18:45:54 -0800
Cc: siprec@ietf.org
Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-15.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: Wed, 12 Feb 2014 02:45:56 -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 Metadata
        Authors         : Ram Mohan Ravindranath
                          Parthasarathi Ravindran
                          Paul Kyzivat
	Filename        : draft-ietf-siprec-metadata-15.txt
	Pages           : 29
	Date            : 2014-02-11

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 describes the metadata model as
   viewed by Session Recording Server(SRS) and the Recording metadata
   format.


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

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

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


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 eckelcu@cisco.com  Wed Feb 12 15:26:16 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 770791A002F for <siprec@ietfa.amsl.com>; Wed, 12 Feb 2014 15:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.049
X-Spam-Level: 
X-Spam-Status: No, score=-15.049 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.548, 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 h1dYiudgMnXf for <siprec@ietfa.amsl.com>; Wed, 12 Feb 2014 15:26:12 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A387F1A0022 for <siprec@ietf.org>; Wed, 12 Feb 2014 15:26:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12362; q=dns/txt; s=iport; t=1392247572; x=1393457172; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YaAKAeDbSA1uL/308kEKSH/4VDwcoALUWMVwpDgizvY=; b=ASH+thyO324soEntZdcAa3EnJBcnBPDQK8zCcoaqw73lA1GdyUhRDO96 29iQYtnyQX/zfkpzb+SiNNLgOxi+2Ll2jhvZ6HR6UP1Puh4i/Q1BA0GUv 5i6J1RnOc2XawiV2jRtR/J4aAjwsUCpuCg+shNc8fVr4v/c36j0Ti/RpW M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAA8C/FKtJXG9/2dsb2JhbABZgww4V4MBu2BPGH8WdIIlAQEBBAEBATEgGgQTBAIBCBEEAQEBBCMFAgIlCxQJCAIEARKIBAENig6bdwaiKRMEgSOMfi0QFgwCAgKCY4FPBJRBg2mSIYMtgWhC
X-IronPort-AV: E=Sophos;i="4.95,835,1384300800"; d="scan'208";a="303675348"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 12 Feb 2014 23:26:11 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1CNQBFM001439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 23:26:11 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 17:26:10 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Dave Higton <DAVE.HIGTON@nice.com>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] Feedback from NENA ICE-8 Event
Thread-Index: Ac7wVdmiG0L5lhiHQ7WoOxMUM8dcKgA4sV2AAAAdpwAAAeKAAAAELGoAAAaQG4ABBOWKAAAFitOAAD6CkoAADmHD0AxcCZ0A
Date: Wed, 12 Feb 2014 23:26:09 +0000
Message-ID: <CF2142BF.1E32C%eckelcu@cisco.com>
References: <9B0B6FB9606F4D4AB133C5E9A203B69405E7CEAA2F@SOUEXC01.eu.nice.com> <CECDEEBF.172A9%eckelcu@cisco.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E7CEABD0@SOUEXC01.eu.nice.com>
In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B69405E7CEABD0@SOUEXC01.eu.nice.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: [171.68.20.19]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <A15134FDA0574A499704764219FC9F70@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [siprec] Feedback from NENA ICE-8 Event
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, 12 Feb 2014 23:26:16 -0000

V2UgaGFkIGEgbGVuZ3RoeSBkaXNjdXNzaW9uIG9uIHRoaXMsIGJ1dCBubyByZXNvbHV0aW9uLg0K
DQpEYXZlIGFuZCBJIG9idmlvdXNseSBzZWUgdGhpcyBkaWZmZXJlbnRseS4gVGhpcyBkaXNjdXNz
aW9uIGhhcyBzb21lDQpyZWxhdGlvbiB0byB0aGUgbW9yZSByZWNlbnQgZGlzY3Vzc2lvbiBvbiBs
b3NzbGVzcyByZWNvcmRpbmcuDQpJIGFtIGhhcHB5IHRvIGFkZCB3aGF0ZXZlciB0ZXh0IHRoZSBn
cm91cCB0aGlua3MgaXMgaGVscGZ1bCwgYnV0IEkgYW0gbm90DQpzdXJlIHdoYXQgdG8gYWRkLg0K
DQpDaGVlcnMsDQpDaGFybGVzDQoNCg0KDQpPbiAxMi8xMS8xMyAxMTo0MiBBTSwgIkRhdmUgSGln
dG9uIiA8REFWRS5ISUdUT05AbmljZS5jb20+IHdyb3RlOg0KDQo+SGkgQ2hhcmxlcywNCj4NCj5X
ZSBoYXZlIHRvIGxvb2sgYXQgdGhlIHN5c3RlbSBhcyBhIHdob2xlLiAgVGhlIHN5c3RlbSBoYXMg
dG8gYmUNCj5lbmdpbmVlcmVkIHNvIHRoYXQgYWxsIHJlcXVpcmVkIHJlY29yZGluZyB0YWtlcyBw
bGFjZSB0byBhbiBhZGVxdWF0ZQ0KPnN0YW5kYXJkOyBjb25mb3JtYW5jZSB0byB2YXJpb3VzIFJG
Q3MgaXMgcmVxdWlyZWQgaW4gb3JkZXIgdG8gZ3VhcmFudGVlDQo+dGhpcy4gIEluIHR1cm4sIGNv
bmZvcm1hbmNlIHRvIHRob3NlIFJGQ3Mgc2hvdWxkIGJlIHN1ZmZpY2llbnQgdG8NCj5ndWFyYW50
ZWUgYWRlcXVhdGUgcmVzdWx0cy4NCj4NCj5UaGUgU1JTIGhhcyB0byBiZSBlbmdpbmVlcmVkIHRv
IHJlY29yZCBhbGwgdGhlIG1lZGlhIHRoYXQgdGhlIGN1c3RvbWVyDQo+d2FudHMgdG8gcmVjb3Jk
LiAgSWYgdGhlIGNvbW11bmljYXRpb25zIHN5c3RlbSBpcyBwcmVwYXJlZCB0byBuZWdvdGlhdGUg
YQ0KPnZpZGVvIGNvZGVjIGFuZCB0aGUgY3VzdG9tZXIgd2FudHMgdG8gcmVjb3JkIHRoZSB2aWRl
byBvZiB0aGUgQ1MsIHRoZSBTUlMNCj5hbmQgU1JDIG11c3QgYmUgZW5naW5lZXJlZCBhbmQgcHJv
dmlzaW9uZWQgdG8gd29yayB0b2dldGhlciBpbiB0ZXJtcyBvZg0KPnRoZSBjb2RlY3MgYW5kL29y
IHRyYW5zY29kaW5nLg0KPg0KPkl0J3Mgd29ydGggcG9pbnRpbmcgb3V0LCBhcyB5b3Ugc2F5LCB0
aGF0IG9uZSBvZiB0aGUgb3B0aW9ucyBtdXN0IGJlDQo+dHJ1ZTogZWl0aGVyIHRoZSBTUlMgc3Vw
cG9ydHMgYWxsIHRoZSBjb2RlY3MgdGhhdCB0aGUgU1JDIGRvZXMsIG9yIHRoZQ0KPlNSQyB0cmFu
c2NvZGVzIGFzIG5lY2Vzc2FyeS4NCj4NCj5JdCBhbGwgaGFuZ3Mgb24gdGhlIGNvbmRpdGlvbmFs
ICJpZiByZWNvcmRpbmcgaXMgcmVxdWlyZWQiIC0gYnV0IGlzbid0DQo+dGhhdCB0cnVlIGJ5IGRl
ZmluaXRpb24sIG90aGVyd2lzZSB0aGUgU0lQUkVDIFJGQyB3b3VsZG4ndCBiZSBpbg0KPmNvbnNp
ZGVyYXRpb24/DQo+DQo+RGF2ZQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv
bTogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbV0NCj5T
ZW50OiAxMSBEZWNlbWJlciAyMDEzIDA5OjQ0DQo+VG86IERhdmUgSGlndG9uOyBzaXByZWNAaWV0
Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3NpcHJlY10gRmVlZGJhY2sgZnJvbSBORU5BIElDRS04IEV2
ZW50DQo+DQo+SGkgRGF2ZSwNCj4NCj5JIHNlZSB5b3VyIHBvaW50LCBhbmQgSSBkbyBub3QgbmVj
ZXNzYXJpbHkgZGlzYWdyZWUuIFNJUFJFQw0KPmludGVyb3BlcmFiaWxpdHkgaXMgb2J2aW91c2x5
IGltcG9ydGFudCB0byBtZSBhcyB3ZWxsLiBIb3dldmVyLCB3ZSBkaWQgbm90DQo+Z28gc28gZmFy
IGFzIHRvIG1hbmRhdGUgc3VwcG9ydCBmb3Igc3BlY2lmaWMgYXVkaW8gY29kZWNzIG9yIHNwZWNp
ZmljDQo+dmlkZW8gY29kZWNzLiBXaGF0IGlmIHRoZSBDUyBpcyBuZWdvdGlhdGVkIHRvIHVzZSBj
b2RlY3MgdGhlIFNSUyBkb2VzIG5vdA0KPnN1cHBvcnQ/IERvIHdlIG5lZWQgdG8gbWFuZGF0ZSB0
aGUgU1JDIHRvIHRyYW5zY29kZSwgb3IgbWFuZGF0ZSBzdXBwb3J0DQo+Zm9yIGEgY29tbW9uIHNl
dCBvZiBjb2RlY3M/IEkgd2FzIGx1bXBpbmcgc3VwcG9ydCBmb3IgRklSIGFuZC9vciBTSVAgSU5G
Tw0KPmludG8gcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbnMgcmF0aGVyIHRoYW4g
dGhpbmdzIHdlIG5lZWQgdG8NCj5tYW5kYXRlLiBUaGUgY3VycmVudCBzcGVjIHByb3ZpZGVzIHRo
ZSBndWlkYW5jZSBJIG1lbnRpb25lZCBidXQgZG9lcyBub3QNCj5wcm92aWRlIGFueSBzdHJpY3Qg
cmVxdWlyZW1lbnRzLiBUaGUgcmVjZW50IGZpbmRpbmdzIGF0IHRoZSBORU5BIGV2ZW50IGFyZQ0K
Pm1ha2luZyBtZSByZXRoaW5rIHRoaXMgcG9zaXRpb24sIHNvIEkgYW0gaGFwcHkgdG8gaGVhciBt
b3JlIGFib3V0IHlvdSBhbmQNCj5vdGhlcnMgdGhpbmsuDQo+DQo+Q2hlZXJzLA0KPkNoYXJsZXMN
Cj4NCj5PbiAxMi8xMC8xMyAxMTo1MCBBTSwgIkRhdmUgSGlndG9uIiA8REFWRS5ISUdUT05Abmlj
ZS5jb20+IHdyb3RlOg0KPg0KPj5Zb3Ugc2VlbSB0byBiZSBzYXlpbmcgdGhhdCwgaWYgdmlkZW8g
cmVjb3JkaW5nIGRvZXNuJ3Qgd29yaywgaXQncyBub3Qgb3VyDQo+PnByb2JsZW0uDQo+Pg0KPj5J
dCdzIGV4YWN0bHkgb3VyIHByb2JsZW0uICBJZiBzb21lb25lIHdhbnRzIHRvIHJlY29yZCB2aWRl
bywgYW5kIHRoZXkNCj4+ZW5naW5lZXIgdGhlIHN5c3RlbSBhY2NvcmRpbmcgdG8gdGhlIGV2ZW50
dWFsIFNJUFJFQyBSRkMsIGl0IHNob3VsZCB3b3JrDQo+PmV2ZXJ5IHRpbWUuICBUaGF0J3Mgd2hh
dCB0aGUgU0lQUkVDIFJGQyBpcyBmb3IuDQo+Pg0KPj5EYXZlDQo+Pg0KPj4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBzaXByZWMgW21haWx0bzpzaXByZWMtYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIENoYXJsZXMgRWNrZWwNCj4+KGVja2VsY3UpDQo+PlNlbnQ6IDEw
IERlY2VtYmVyIDIwMTMgMDk6NDYNCj4+VG86IFBhdWwgS3l6aXZhdDsgQnJpYW4gUm9zZW4NCj4+
Q2M6IHNpcHJlY0BpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW3NpcHJlY10gRmVlZGJhY2sgZnJv
bSBORU5BIElDRS04IEV2ZW50DQo+Pg0KPj5JJ20gbm90IHN1cmUgd2UgbmVlZCB0byBwbGFjZSBh
bnkgcmVxdWlyZW1lbnRzIG9uIHRoZSBTUkMgb3IgU1JTLiBXZQ0KPj5jdXJyZW50bHkgcmVjb21t
ZW5kIHRoYXQgU1JDcywgU1JTcywgYW5kIHJlY29yZGluZyBhd2FyZSBVQXMgc3VwcG9ydCBhbmQN
Cj4+dXNlIEZJUiAoUkZDIDUxMDQpLiBXZSBtZW50aW9uIHRoZSBwb3RlbnRpYWwgdXNlIG9mIFNJ
UCBJTkZPIChSRkMgNTE2OCkNCj4+YnV0IHN0YXRlIGl0IGlzIHRvIGJlIHVzZWQgZm9yIGJhY2t3
YXJkIGNvbXBhdGliaWxpdHkgcHVycG9zZXMuIEZJUiBpcw0KPj5wcmVmZXJyZWQuIFNlZSBzZWN0
aW9uIDguMS43LjEuDQo+PklmIHRoZSBTUkMgZG9lcyBub3Qgc3VwcG9ydCBTSVAgSU5GTyAoUkZD
IDUxNjgpIGFuZCBhIFVBIHdpdGhpbiBhIGdpdmVuDQo+PkNTDQo+Pm9ubHkgc3VwcG9ydHMgU0lQ
IElORk8sIHRoZSBTUkMgd2lsbCBub3QgYmUgYWJsZSB0byByZWNvcmQgdGhhdCBDUy4gVmlkZW8N
Cj4+bWlnaHQgbm90IGV2ZW4gd29yayBpbiB0aGUgZmlyc3QgcGxhY2UuIEkgdGhpbmsgdGhpcyBh
IHF1YWxpdHkgb2YNCj4+aW1wbGVtZW50YXRpb24gcXVlc3Rpb24sIG5vdCBzb21ldGhpbmcgU0lQ
UkVDIHNob3VsZCBtYW5kYXRlLiBTYW1lIGZvcg0KPj50aGUNCj4+U1JTLiBBIG1pc21hdGNoIGlu
IEZJUi9TSVAgSU5GTyBiZXR3ZWVuIHRoZSBTUkMgYW5kIFNSUyBzaG91bGQgcmVzdWx0IGluDQo+
PnRoZSBSUyBlc3RhYmxpc2hpbmcgYXMgYXVkaW8gb25seSBpbiBteSBvcGluaW9uLiBXZSBjb3Vs
ZCBtYWtlIHRoZQ0KPj5leGlzdGluZyByZWNvbW1lbmRhdGlvbiBzdHJvbmdlciwgYnV0IEkgdGhp
bmsgaXQgaXMgZmluZSBhcyBpcy4NCj4+U2VjdGlvbiA4LjIgcHJvdmlkZXMgaW5mb3JtYXRpb24g
b24gaG93IGFuIFNSQyBhbmQgU1JTIHNob3VsZCBkZWFsIHdpdGgNCj4+cGFja2V0IGxvc3MuIEkg
dGhvdWdodCBvZiB0aGlzIGFzIGNvdmVyaW5nIHRoZSBpbml0aWFsIEktZnJhbWUgY2FzZSwgYnV0
DQo+PnBlcmhhcHMgbW9yZSBkZXRhaWxzIGFyZSBuZWVkZWQgaGVyZT8NCj4+DQo+PkNoZWVycywN
Cj4+Q2hhcmxlcw0KPj4NCj4+T24gMTIvNC8xMyAxOjM5IFBNLCAiUGF1bCBLeXppdmF0IiA8cGt5
eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4+DQo+Pj5PbiAxMi80LzEzIDE6MzEgUE0sIEJy
aWFuIFJvc2VuIHdyb3RlOg0KPj4+PiBCdXQsIHRoZSBTUkMgcmVhbGx5LCByZWFsbHkgd2FudHMg
dG8gYmUgYWJsZSB0byBnZXQgYSBGSVIgdG8gdGhlIFVBIGluDQo+Pj4+dGhlIENTLiAgVGhlcmVm
b3JlLCBpdCBoYXMgdG8gc3VwcG9ydCBib3RoLiAgTm8gbGltaXRhdGlvbiBvZiB0aGUgU1JDDQo+
Pj4+aW4NCj4+Pj50aGlzIHJlZ2FyZCBjYW4gYmUgbWFkZSB1cCBieSBzbWFydHMgaW4gdGhlIFNS
Uy4gIFNvIHRoZSBTUkMgaGFzIHRvDQo+Pj4+c3VwcG9ydCBib3RoIDUxMDQgYW5kIDUxNjguICBZ
b3UgY291bGQsIEkgc3VwcG9zZSBzYXkgdGhhdCBpZiB0aGUgU1JDDQo+Pj4+a25vd3MsIGZvciBz
dXJlLCB0aGF0IGVhY2ggYW5kIGV2ZXJ5IG9uZSBvZiB0aGUgVUFzIGluIHRoZSBDUyBzdXBwb3J0
cw0KPj4+Pm9uZSBvZiB0aGVtLCB0aGVuIGl0IGRvZXNuqfZ0IGhhdmUgdG8gc3VwcG9ydCB0aGUg
b3RoZXIuDQo+Pj4+DQo+Pj4+IElmIHRoZSBTUkMgc3VwcG9ydHMgYm90aCwgdGhlbiB0aGUgU1JT
IGNvdWxkLCBpbiB0aGVvcnksIHN1cHBvcnQNCj4+Pj5laXRoZXIuICBJIHRoaW5rIHRoYXQgaXMg
YSBtaXN0YWtlLiAgSXQgc2hvdWxkIHN1cHBvcnQgNTEwNCwgaXSp9nMgYQ0KPj4+PmJldHRlciBt
ZWNoYW5pc20uICA1MTY4IGRvY3VtZW50cyBhbiBvbGQgbWVjaGFuaXNtLg0KPj4+Pg0KPj4+PiBJ
bnRlcndvcmtpbmcgdGhlIHR3byBpcyBwcmV0dHkgZWFzeS4gIElmIHlvdSByZWFsbHkgdGhpbmsg
dGhhdCBpdKn2cyBhDQo+Pj4+YnVyZGVuLCB0aGVuIHN1cHBvcnRpbmcgYm90aCBvbiB0aGUgU1JT
IHdvdWxkIGZpeCB0aGF0Lg0KPj4+DQo+Pj5JJ20gdGhpbmtpbmcgb2YgYSBVQSB0aGF0IGFjdHMg
YXMgaXRzIG93biBTUkMuIE1heWJlIGl0IG9ubHkgc3VwcG9ydHMNCj4+Pm9uZSBvZiB0aGUgbWVj
aGFuaXNtcywgc28gaXQga25vd3MgdGhlIG9uZSBpdCBzdXBwb3J0cyBpcyB1c2VkIG9uIHRoZQ0K
Pj4+Q1MuIFNvIGl0IGNhbiB1c2UgdGhhdCBvbmUgb24gdGhlIFJTIHRvby4NCj4+Pg0KPj4+CVRo
YW5rcywNCj4+PglQYXVsDQo+Pj4NCj4+Pj4gQnJpYW4NCj4+Pj4NCj4+Pj4gT24gRGVjIDQsIDIw
MTMsIGF0IDExOjMxIEFNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4NCj4+
Pj53cm90ZToNCj4+Pj4NCj4+Pj4+IE9uIDEyLzQvMTMgMTA6MzcgQU0sIEJyaWFuIFJvc2VuIHdy
b3RlOg0KPj4+Pj4+IEFjdHVhbGx5LCBJIHRoaW5rIHlvdSBoYXZlIHRvIHJlcXVpcmUgdGhlIFNS
QyB0byBzdXBwb3J0IGJvdGgNCj4+Pj4+Pm1lY2hhbmlzbXMsIGJlY2F1c2UgeW91IHdhbnQgdGhl
IGJlc3QgY2hhbmNlIGl0IGNhbiBzZW5kIGEgRklSIHRvIHRoZQ0KPj4+Pj4+b3RoZXIgVUEgaW4g
dGhlIENTLiAgWW91IGNvdWxkIGFsbG93IHRoZSBTUlMgdG8gY2hvb3NlLCBidXQgYWN0dWFsbHks
DQo+Pj4+Pj5JqfZkIHNheSByZXF1aXJlIDUxMDQuDQo+Pj4+Pg0KPj4+Pj4gSSBtZW50aW9uIHRo
ZSBTUlMgZmlyc3QgYmVjYXVzZSBpdCBpcyBnZW5lcmFsbHkgdGhlIG1vc3QgY2FwYWJsZQ0KPj4+
Pj5kZXZpY2UsIGFuZCB0aGUgb25lIHRoZXJlIGFyZSB0aGUgZmV3ZXN0IG9mLg0KPj4+Pj4NCj4+
Pj4+IFNSQ3MgbWF5IGJlIGluY29ycG9yYXRlZCBpbnRvIGFsbCBzb3J0cyBvZiB0aGluZ3MsIHNv
bWUgZmFpcmx5DQo+Pj4+PmxpbWl0ZWQuDQo+Pj4+Pg0KPj4+Pj4gSWYgYW4gU1JDIGlzIGp1c3Qg
cmVsYXlpbmcgdGhlIGZyYW1lIHJlZnJlc2ggcmVxdWVzdHMsIGl0IG1heSBiZQ0KPj4+Pj5lYXNp
ZXIgZm9yIGl0IHRvIG9ubHkgc3VwcG9ydCB3aGF0IHRoZSBDUyBzdXBwb3J0cyByYXRoZXIgdGhh
bg0KPj4+Pj5pbnRlcndvcmtpbmcgdHdvIG1lY2hhbmlzbXMuDQo+Pj4+Pg0KPj4+Pj4gQnV0IEkg
aGF2ZW4ndCB0aG91Z2h0IHRocm91Z2ggZnVsbHkgd2hldGhlciB0aGVyZSBhcmUgcHJvYmxlbXMg
d2l0aA0KPj4+Pj50aGlzLg0KPj4+Pj4NCj4+Pj4+IAlUaGFua3MsDQo+Pj4+PiAJUGF1bA0KPj4+
Pj4NCj4+Pj4+PiBCcmlhbg0KPj4+Pj4+DQo+Pj4+Pj4gT24gRGVjIDQsIDIwMTMsIGF0IDEwOjM0
IEFNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4NCj4+Pj4+Pndyb3RlOg0K
Pj4+Pj4+DQo+Pj4+Pj4+IE9uIDEyLzMvMTMgMTozMiBQTSwgU2ltb24gRmFycm93IHdyb3RlOg0K
Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSW4gdGhlIGkzIGRvY3VtZW50IHRoZSBmb2xsb3dpbmcgdGV4dCB3
YXMgYWRkZWQgdG8gaGVscCBhZGRyZXNzDQo+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj5pc3N1ZQ0KPj4+
Pj4+Pj4gYnV0IHRvIG1lIHRoaXMgZG9lcyBoZWxwIHRoZSBTSVBSRUMgc3BlY2lmaWNhdGlvbg0K
Pj4+Pj4+Pj4gIlVzZXIgQWdlbnRzIGluIHRoZSBFU0luZXQgbXVzdCBzdXBwb3J0IGJvdGggUkZD
NTEwNCBbMTYwXSBhbmQNCj4+Pj4+Pj4+UkZDNTE2OCBbMTYxXQ0KPj4+Pj4+Pj4gZm9yIGZ1bGwg
ZnJhbWUgcmVmcmVzaCByZXF1ZXN0cy4gIFRoZSBSRkM1MTA0IFJUQ1AgbWV0aG9kIGlzDQo+Pj4+
Pj4+PnByZWZlcnJlZCB3aXRoDQo+Pj4+Pj4+PiBmYWxsIGJhY2sgdG8gUkZDNTE2OCBJTkZPIG1l
dGhvZCB3aGVuIHRoZSBzZW5kZXIgZG9lcyBub3QNCj4+Pj4+Pj4+aW1wbGVtZW50DQo+Pj4+Pj4+
PlJGQzUxMDQiDQo+Pj4+Pj4+DQo+Pj4+Pj4+IElTVE0gdGhhdCB3ZSBuZWVkIHRvIGhhdmUgc29t
ZSB0ZXh0IGFib3V0IGhvdyB0byBkZWFsIHdpdGggdGhlIHR3bw0KPj4+Pj4+Pm1lY2hhbmlzbXMu
IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIHJlcXVpcmUgVUFzIGluIHRoZSBDUyB0byBzdXBwb3J0DQo+
Pj4+Pj4+Ym90aCBtZWNoYW5pc21zLiBTbyBJIHRoaW5rIHdlIG11c3QgbWFrZSBpdCBhIHJlcXVp
cmVtZW50IG9uIHRoZSBTUkMNCj4+Pj4+Pj5hbmQvb3IgdGhlIFNSUyB0byBkZWFsIHdpdGggaW50
ZXJ3b3JraW5nLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJU1RNIHRoYXQgd2UgY2FuIHJlYXNvbmFibHkg
cHV0IGEgcmVxdWlyZW1lbnQgb24gdGhlIFNSUyB0byBzdXBwb3J0DQo+Pj4+Pj4+Ym90aCBtZWNo
YW5pc21zLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAJVGhhbmtzLA0KPj4+Pj4+PiAJUGF1bA0KPj4+Pj4+
Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPj4+Pj4+PiBzaXByZWMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IHNpcHJlY0BpZXRmLm9yZw0K
Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHJlYw0KPj4+
Pj4+DQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5zaXByZWMgbWFpbGluZyBsaXN0DQo+
Pj5zaXByZWNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vc2lwcmVjDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPj5zaXByZWMgbWFpbGluZyBsaXN0DQo+PnNpcHJlY0BpZXRmLm9yZw0KPj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHJlYw0KPj4NCj4+DQo+Pk5JQ0Ug
U3lzdGVtcyBVSyBMaW1pdGVkICgiTklDRSIpIGlzIHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCB1bmRl
ciBjb21wYW55DQo+Pm51bWJlciwgMzQwMzA0NC4gVGhlIHJlZ2lzdGVyZWQgb2ZmaWNlIG9mIE5J
Q0UgaXMgYXQgVG9sbGJhciBXYXksIEhlZGdlDQo+PkVuZCwgU291dGhhbXB0b24sIEhhbXBzaGly
ZSBTTzMwIDJaUC4NCj4+DQo+PkNvbmZpZGVudGlhbGl0eTogVGhpcyBjb21tdW5pY2F0aW9uIGFu
ZCBhbnkgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvcg0KPj50aGUgYWJvdmUtbmFtZWQgcGVy
c29ucyBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsIGFuZC9vciBsZWdhbGx5DQo+PnByaXZp
bGVnZWQuIEFueSBvcGluaW9ucyBleHByZXNzZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGFyZSBu
b3QNCj4+bmVjZXNzYXJpbHkgdGhvc2Ugb2YgTklDRS4gSWYgdGhpcyBjb21tdW5pY2F0aW9uIGhh
cyBjb21lIHRvIHlvdSBpbiBlcnJvcg0KPj55b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBv
biBpdCwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyBpdCB0bw0KPj5hbnlvbmU7IHBsZWFzZSBk
ZWxldGUvZGVzdHJveSBhbmQgaW5mb3JtIHRoZSBzZW5kZXIgYnkgZS1tYWlsDQo+PmltbWVkaWF0
ZWx5Lg0KPj4NCj4+TW9uaXRvcmluZzogTklDRSBtYXkgbW9uaXRvciBpbmNvbWluZyBhbmQgb3V0
Z29pbmcgZS1tYWlscy4NCj4+DQo+PlZpcnVzZXM6IEFsdGhvdWdoIHdlIGhhdmUgdGFrZW4gc3Rl
cHMgdG93YXJkIGVuc3VyaW5nIHRoYXQgdGhpcyBlLW1haWwNCj4+YW5kIGF0dGFjaG1lbnRzIGFy
ZSBmcmVlIGZyb20gYW55IHZpcnVzLCB3ZSBhZHZpc2UgdGhhdCBpbiBrZWVwaW5nIHdpdGgNCj4+
Z29vZCBjb21wdXRpbmcgcHJhY3RpY2UgdGhlIHJlY2lwaWVudCBzaG91bGQgZW5zdXJlIHRoZXkg
YXJlIGFjdHVhbGx5DQo+PnZpcnVzIGZyZWUuDQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+PnNpcHJlYyBtYWlsaW5nIGxpc3QNCj4+c2lwcmVjQGll
dGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwcmVjDQo+
DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaXBy
ZWMgbWFpbGluZyBsaXN0DQo+c2lwcmVjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9zaXByZWMNCg0K


From eckelcu@cisco.com  Wed Feb 12 16:48:51 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 509D41A0047 for <siprec@ietfa.amsl.com>; Wed, 12 Feb 2014 16:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Level: 
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 bptarqXOeztK for <siprec@ietfa.amsl.com>; Wed, 12 Feb 2014 16:48:48 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id B59331A0091 for <siprec@ietf.org>; Wed, 12 Feb 2014 16:48:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4023; q=dns/txt; s=iport; t=1392252528; x=1393462128; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xslRUzl8i1Mg59BosIu2PRsGzKdkw2onp5wKXnDFwi4=; b=YTBRIw1cEDw4N4TNes3dd25nizrMqUQu7tiHohnF9IEkd7nks7reoMvE 4H2A7jbdTU5PP3FuJ9Ysnb3dRksQd8E32Fc3rqwall3VGawqyaUEJPalK Wro7q+VGM6zji32o7UBhP7motqszGPj8ofUjAuhpBIfeAAkk5HK4z0Trc I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAJ0V/FKtJXG9/2dsb2JhbABZgww4V75hT4EXFnSCJgEBBAEBATc0GwIBCDYQJwslAgQBEogEAQ3IIxMEjwCEOASYKpIhgW+BPoIq
X-IronPort-AV: E=Sophos;i="4.95,835,1384300800"; d="scan'208";a="20032428"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 13 Feb 2014 00:48:47 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1D0mlfm009404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <siprec@ietf.org>; Thu, 13 Feb 2014 00:48:47 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 18:48:46 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] Text on how often(soon) SRC should send metadata/updates to SRS in protocol draft
Thread-Index: AQHO+vRJ3ij54lx6jUmlffEKhsdcgJqyk0KA
Date: Thu, 13 Feb 2014 00:48:46 +0000
Message-ID: <CF21431F.1E339%eckelcu@cisco.com>
References: <CED5F30C.742EB%rmohanr@cisco.com>
In-Reply-To: <CED5F30C.742EB%rmohanr@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: [171.68.20.19]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5ADE48FC4610164C9CC2665F34BA1478@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [siprec] Text on how often(soon) SRC should send metadata/updates to SRS in protocol draft
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, 13 Feb 2014 00:48:51 -0000

We never reached a conclusion on this. I agree with Ram that section 9.1
is the place to address this. The current text in section 9.1 contains
some redundancy and does not flow all that well. I had a difficult
inserting new text into it. I propose replacing with the following, which
also addresses the issue raised by Paul and Ram.
--------

9. Metadata

Some metadata attributes are contained in SDP, and others are contained in
a new content type
"application/rs-metadata". The format of the metadata is described as part
of the mechanism in [I-D.ietf-siprec-metadata]. A new "disposition-type"
of Content-Disposition is defined for the
purpose of carrying metadata. The value is "recording-session", which
indicates the "application/rs-metadata" content contains metadata to be
handled by the SRS.


9.1 Procedures at the SRC

The SRC MUST send metadata to the SRS in an RS. The SRC SHOULD send
metadata as soon as it becomes available and whenever it changes.

Metadata sent by the SRC is categorized as either a full metadata snapshot
or a partial update. A full metadata snapshot describes all metadata
associated with the RS. The SRC MAY send a full metadata snapshot at any
time. The SRC MAY send a partial update only if a full metadata snapshot
has been sent previously.
=20

The SRC MAY send metadata (either a full metadata shapshot or a partial
update) in an INVITE request, an UPDATE request [RFC3311], or an 200
response to an offerless INVITE from the SRS. If the metadata contains a
reference to any SDP labels, the request containing the metadata MUST also
contain an SDP offer that defines those labels.

When a SIP message contains both an SDP offer and metadata, the request
body MUST have content type multipart/mixed, with one subordinate body
part containing the SDP offer and another containing the metadata. When a
SIP message contains only an SDP offer or metadata, the multipart/mixed
container is optional.



The SRC SHOULD include a full metadata snapshot in the initial INVITE
request establishing the RS. If metadata is not yet available (e.g an RS
established in absence of a CS), the SRC SHOULD send a full metadata
snapshot as soon as metadata becomes available.

If the SRC receives a snapshot request from the SRS, it MUST immediately
send a full metadata snapshot.
--------------

Comments welcome.

Cheers,
Charles


On 12/17/13 7:50 AM, "Ram Mohan R (rmohanr)" <rmohanr@cisco.com> wrote:

>When Paul and me were reviewing the metadata draft we were discussing on
>how quickly a SRC has to send updates to SRS. The updates can any
>update(of CS changes ) from SRC from SRS. Currently we don't have any
>recommendation / text on this in Protocol or Metadata draft.
>
>
>For example, Suppose there is a sequence of changes on a single
><participantstreamassoc> XML element as below:
>
>T1: associate-time (A participant starts contributing to a stream)
> -- snapshot 1 sent from SRC to SRS
>T2: disassociate-time ((A participant stops contributing to a stream)
>T3: associate-time (starts contributing again)
>-- snapshot 2
>T4: disassociate
>T5: associate
>T6: disassociate
>-- snapshot 3
>
>
>Any of the above can happen. Ideally an SRC is expected to send snapshot
>updates as soon as possible (i.e after every transaction of CS). We have
>discussed this point earlier in mailing list.
>
>The question is - Should we mandate this (MUST ?) with some text or just
>add it as RECOMMENDATION. I am inclined with having it as RECOMMENDATION
>and leave it to the implementors on deciding how soon they want to send
>the updates from SRC to SRS.
>
>In any case we need some text and I believe section 9 of Protocol draft
>that talks about=20
>
>Sending metadata from SRC to SRS is the right place to have this text.
>
>Comments ?
>
>Regards,
>Ram
>
>_______________________________________________
>siprec mailing list
>siprec@ietf.org
>https://www.ietf.org/mailman/listinfo/siprec


From michael.yan@huawei.com  Thu Feb 13 00:16:00 2014
Return-Path: <michael.yan@huawei.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 3AEB11A0169 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 00:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.149
X-Spam-Level: 
X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 45K31Z5l5Zx8 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 00:15:58 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 99B4C1A0113 for <siprec@ietf.org>; Thu, 13 Feb 2014 00:15:57 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBB58212; Thu, 13 Feb 2014 08:15:55 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 08:15:35 +0000
Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 08:15:51 +0000
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.12]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 16:15:47 +0800
From: "Yanqiang (Michael)" <michael.yan@huawei.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
Thread-Index: Ac8ok8vdnZz5K15QSrWfQbh18NrXcg==
Date: Thu, 13 Feb 2014 08:15:46 +0000
Message-ID: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.173.14.125]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 08:16:00 -0000

SGkgZ3V5cywNCg0KCVJlY2VudGx5IHRoZXJlIGFyZSBkaXNjdXNzaW9ucyBhYm91dCBzZXZlcmFs
IHNpbWlsYXIgaXNzdWVzIGluIG1haWxpbmcgbGlzdC4gVGhlICdsb3NzbGVzcyByZWNvcmRpbmcn
LCAnSEEgcmVjb3JkaW5nJywgJ21lZGlhIGNsaXBwaW5nJyBhcmUga2V5IHdvcmRzLiBHZXJiZW4g
aGFkIG1lbnRpb25lZCAnIExvc3NsZXNzIFJlY29yZGluZycgYXQgaHR0cDovL3d3dy5pZXRmLm9y
Zy9tYWlsLWFyY2hpdmUvd2ViL3NpcHJlYy9jdXJyZW50L21zZzAzODkzLmh0bWwgKG5vdCAxc3Qg
dmVyc2lvbiBmb3IgdGhlIGlzc3VlIGJ1dCB0aGUgZXhwbGljaXQgdmVyc2lvbiBpbiB0aGlzIFdH
KS4gQW5kIFNpbW9uIGhhZCBtZW50aW9uZWQgJ21lZGlhIGNsaXBwaW5nJyBhdCBodHRwOi8vd3d3
LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwcmVjL2N1cnJlbnQvbXNnMDM4MzkuaHRtbCAu
IEFyZSB0aG9zZSBpc3N1ZXMgc3RpbGwgb3BlbiBmb3IgdXM/DQoNCglJIHRyaWVkIHRvIGNvbGxl
Y3QgYWxsIHRoZSBpc3N1ZXMgYW5kIHNvbHV0aW9ucyB0byBtYWtlIHRoZW0gZWFzeS10by1kaXNj
dXNzOg0KDQoxLiBVRFAgUGFja2FnZSBsb3NzIGluIHRyYW5zbWlzc2lvbg0KCVRoZSBzb2x1dGlv
biBtaWdodCBiZToNCglhLiBGRUMNCgliLiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZHVwbGljYXRp
b24tMDUNCgliLiBSVFAgb3ZlciBUQ1AgdG8gc2FtZSBTUlM/DQoNCjIuIG1lZGlhIGNsaXBwaW5n
LCBlc3AgZm9yIHZpZGVvIGNsaXBwaW5nIGNhdXNlZCBieSBJLWZyYW1lIGxvc3QNCglUaGUgc29s
dXRpb24gbWlnaHQgYmU6DQoJYS4gRklSIChSRkMgNTEwNCkuIGJ1ZmZlcmluZyBpbiBTUkMgKHJl
YWR5IGZvciBmdWxsIGZyYW1lIHJlZnJlc2gpLCBjaGVjayBhbmQgc3RhcnQgZnJvbSBJLWZyYW1l
IGluIFJTDQoJYi4gYSBwZXJzaXN0ZW50IFJTLi4uKGFscmVhZHkgaGF2ZSBpbiBTSVBSRUMpDQoN
CjMuIFNSUyBpcyBub3QgcmVhZHkgdG8gcmVjZWl2ZSBvciBnb2VzIGRvd24gaW4gdGhlIG1pZCBv
ZiBSUw0KCVRoZSBzb2x1dGlvbiBtaWdodCBiZToNCglhLiBidWZmZXJpbmcgaW4gU1JDKGEgc21h
bGwgZHVyYXRpb24gb3IgYWxsIHNlc3Npb24pLCB0aGVuIGRldGVjdCBhbmQgcmVzZW5kDQoJYi4g
aGF2ZSB0d28gaW5kZXBlbmRlbnQgcGFyYWxsZWwgU1JTLCB3aXRoIHN5bmNocm9uaXphdGlvbiBt
ZWNoYW5pc20gDQoJYy4gb3RoZXIgd2F5cz8gU3dpdGNoIHRvIGJhY2t1cCBTUlMgKHN0aWxsIGxv
c3MgZHVyaW5nIHN3aXRjaGluZyk/IA0KDQpUaGVuLCBsZXQncyBiYWNrIHRvIGN1cnJlbnQgZG9j
dW1lbnRzLg0KDQoxLiBJIHRoaW5rIFJGQzYzNDEgY292ZXJzIGFsbCBpc3N1ZXMgaW4gZGlmZmVy
ZW50IHdheS4NCglhLiBVc2UgQ2FzZSAxMDogTm8gbG9zcyBvZiBtZWRpYSByZWNvcmRpbmcgY2Fu
IG9jY3VyLCBpbmNsdWRpbmcgZHVyaW5nIGZhaWx1cmUgb2YgYW4gU1JTIChpc3N1ZSAjMSYjMykN
CgliLiBSRVEtMDA1OiBUaGUgbWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byBy
ZWNvcmQgYSBDUyB3aXRob3V0IGxvc3Mgb2YgbWVkaWEgb2YgUlMgKGZvciBleGFtcGxlLCBjbGlw
cGluZyBtZWRpYSBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBDUykgKGlzc3VlICMyKQ0KCWMuIFJF
US0wMjE6IFRoZSBtZWNoYW5pc20gTVVTVCBOT1QgcHJldmVudCBoaWdoLWF2YWlsYWJpbGl0eSBk
ZXBsb3ltZW50cyAoaXNzdWUgIzEjMiMzKQ0KDQoyLiBkcmFmdC1zaXByZWMtYXJjaGl0ZWN0dXJl
IGFuZCBkcmFmdC1zaXByZWMtcHJvdG9jb2wgZG9jdW1lbnRzIHNlZW0gbm90IGNvdmVyIGVub3Vn
aCBkZXRhaWxzIGFib3V0IGhvdyB0byBoYW5kbGUgdGhlc2UgaXNzdWVzLg0KCWEuIFRoZSBhcmNo
aXRlY3R1cmUgZG9jdW1lbnQgbWlnaHQgcmVjb25zaWRlciB0aGUgZGVzY3JpcHRpb24gaW4gU2Vj
dGlvbiBJbnRyb2R1Y3Rpb24gdG8gYXZvaWQgYW1iaWd1aXR5OiBUaGUgUmVwbGljYXRlZCBNZWRp
YSBpcyByZXF1aXJlZCB0byBiZSBzZW50IGluIHJlYWwtdGltZSB0byB0aGUgU1JTIGFuZCBpcyAq
bm90IGJ1ZmZlcmVkKiBieSB0aGUgU1JDIHRvIGFsbG93IGZvciByZWFsLXRpbWUgYW5hbHlzaXMg
b2YgdGhlIG1lZGlhIGJ5IHRoZSBTUlMuDQoJYi4gVGhlIHByb3RvY29sIGRvY3VtZW50IGhhcyBz
ZWN0aW9uIDguMS43IGZvciB0aGUgdXNlIG9mIEZJUiBmb3IgZ2VuZXJhdGluZyBhIGZ1bGwgSS1m
cmFtZS4uLkFueSBtb3JlIGRldGFpbHMgbmVlZGVkPw0KDQpBcmUgdGhvc2UgdGhlIHF1YWxpdHkg
b2YgaW1wbGVtZW50YXRpb24gaXNzdWVzLCBub3QgYSBzdGFuZGFyZGl6YXRpb24gaXNzdWVzPyBB
bnkgY29tbWVudHM/DQoNClRoYW5rcywNCk1pY2hhZWwNCg==


From DAVE.HIGTON@nice.com  Thu Feb 13 06:25:01 2014
Return-Path: <DAVE.HIGTON@nice.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 7A2301A0295 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 06:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.548] 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 g8GfGdm4lygX for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 06:24:58 -0800 (PST)
Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 86D6D1A0237 for <siprec@ietf.org>; Thu, 13 Feb 2014 06:24:58 -0800 (PST)
Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Thu, 13 Feb 2014 14:24:55 +0000
Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 14:23:55 +0000
Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Thu, 13 Feb 2014 14:23:48 +0000
From: "Dave Higton" <DAVE.HIGTON@nice.com>
To: <siprec@ietf.org>
Date: Thu, 13 Feb 2014 14:23:47 +0000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
Thread-Topic: Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
Thread-Index: Ac8ok8vdnZz5K15QSrWfQbh18NrXcgAM1PvA
Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FBF1@SOUEXC01.eu.nice.com>
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com>
In-Reply-To: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Feb 2014 14:23:55.0523 (UTC) FILETIME=[3A171D30:01CF28C7]
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 14:25:01 -0000

That looks to me like a complete collection.

Dave

-----Original Message-----
From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang =
(Michael)
Sent: 13 February 2014 08:16
To: siprec@ietf.org
Subject: [siprec] Lossless recording/HA recording/media clipping? Open =
issues to SIPRECers?

Hi guys,

	Recently there are discussions about several similar issues in mailing =
list. The 'lossless recording', 'HA recording', 'media clipping' are key =
words. Gerben had mentioned ' Lossless Recording' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html (not =
1st version for the issue but the explicit version in this WG). And =
Simon had mentioned 'media clipping' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html . Are =
those issues still open for us?

	I tried to collect all the issues and solutions to make them =
easy-to-discuss:

1. UDP Package loss in transmission
	The solution might be:
	a. FEC
	b. draft-ietf-avtext-rtp-duplication-05
	b. RTP over TCP to same SRS?

2. media clipping, esp for video clipping caused by I-frame lost
	The solution might be:
	a. FIR (RFC 5104). buffering in SRC (ready for full frame refresh), =
check and start from I-frame in RS
	b. a persistent RS...(already have in SIPREC)

3. SRS is not ready to receive or goes down in the mid of RS
	The solution might be:
	a. buffering in SRC(a small duration or all session), then detect and =
resend
	b. have two independent parallel SRS, with synchronization mechanism=20
	c. other ways? Switch to backup SRS (still loss during switching)?=20

Then, let's back to current documents.

1. I think RFC6341 covers all issues in different way.
	a. Use Case 10: No loss of media recording can occur, including during =
failure of an SRS (issue #1&#3)
	b. REQ-005: The mechanism MUST support the ability to record a CS =
without loss of media of RS (for example, clipping media at the =
beginning of the CS) (issue #2)
	c. REQ-021: The mechanism MUST NOT prevent high-availability =
deployments (issue #1#2#3)

2. draft-siprec-architecture and draft-siprec-protocol documents seem =
not cover enough details about how to handle these issues.
	a. The architecture document might reconsider the description in =
Section Introduction to avoid ambiguity: The Replicated Media is =
required to be sent in real-time to the SRS and is *not buffered* by the =
SRC to allow for real-time analysis of the media by the SRS.
	b. The protocol document has section 8.1.7 for the use of FIR for =
generating a full I-frame...Any more details needed?

Are those the quality of implementation issues, not a standardization =
issues? Any comments?

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


NICE Systems UK Limited ("NICE") is registered in England under company =
number, 3403044. The registered office of NICE is at Tollbar Way, Hedge =
End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for =
the above-named persons only and may be confidential and/or legally =
privileged. Any opinions expressed in this communication are not =
necessarily those of NICE. If this communication has come to you in =
error you must take no action based on it, nor must you copy or show it =
to anyone; please delete/destroy and inform the sender by e-mail =
immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail =
and attachments are free from any virus, we advise that in keeping with =
good computing practice the recipient should ensure they are actually =
virus free.


From DAVE.HIGTON@nice.com  Thu Feb 13 06:47:09 2014
Return-Path: <DAVE.HIGTON@nice.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 7A24D1A01EB for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 06:47:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.548] 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 7vx-Xpb6lIYc for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 06:47:07 -0800 (PST)
Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 438DB1A02CC for <siprec@ietf.org>; Thu, 13 Feb 2014 06:46:53 -0800 (PST)
Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Thu, 13 Feb 2014 14:46:52 +0000
Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 14:46:34 +0000
Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Thu, 13 Feb 2014 14:46:34 +0000
From: "Dave Higton" <DAVE.HIGTON@nice.com>
To: <siprec@ietf.org>
Date: Thu, 13 Feb 2014 14:46:33 +0000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
Thread-Topic: Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
Thread-Index: Ac8ok8vdnZz5K15QSrWfQbh18NrXcgAM2q2Q
Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com>
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com>
In-Reply-To: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Feb 2014 14:46:34.0671 (UTC) FILETIME=[6434A3F0:01CF28CA]
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 14:47:09 -0000

Here are a few assumptions on topics 1 and 3 for everybody to check out:

* The network is engineered to have all the required bandwidth.

* We can only cure occasional dropped packets.

* If there is a hard failure, e.g. a network switch dies, no simple =
retry-based mechanism is going to solve it.  For those cases you need =
redundancy, eliminating all single points of failure.

* We want to use an existing, tried and trusted, protocol; we don't want =
to engineer a new one.

* We don't have significant numbers of implementations of lossless =
recording in the field, so whatever we do is going to be a change from =
what we do now.

* Any SRC that implements SIPREC is engineered with enough RAM to buffer =
the media for long enough to deal with some retries.

* SIPREC should cover lossless recording in enough detail that people =
can implement to it, referring to other RFCs where necessary.

Based on the above assumptions, I'm suggesting that TCP is a tried and =
trusted solution to the problem of occasional dropped packets to the =
SRS.  TCP is usually discounted for RTP because of the increase in =
latency.  Clearly that is not a consideration for recording, because =
recording is inherently a time delay mechanism.

RFC 4571 would appear to pretty much cover what is necessary for RTP =
over TCP, including an update to SDP to specify TCP.

Comments?  Better suggestions?

Dave

-----Original Message-----
From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang =
(Michael)
Sent: 13 February 2014 08:16
To: siprec@ietf.org
Subject: [siprec] Lossless recording/HA recording/media clipping? Open =
issues to SIPRECers?

Hi guys,

	Recently there are discussions about several similar issues in mailing =
list. The 'lossless recording', 'HA recording', 'media clipping' are key =
words. Gerben had mentioned ' Lossless Recording' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html (not =
1st version for the issue but the explicit version in this WG). And =
Simon had mentioned 'media clipping' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html . Are =
those issues still open for us?

	I tried to collect all the issues and solutions to make them =
easy-to-discuss:

1. UDP Package loss in transmission
	The solution might be:
	a. FEC
	b. draft-ietf-avtext-rtp-duplication-05
	b. RTP over TCP to same SRS?

2. media clipping, esp for video clipping caused by I-frame lost
	The solution might be:
	a. FIR (RFC 5104). buffering in SRC (ready for full frame refresh), =
check and start from I-frame in RS
	b. a persistent RS...(already have in SIPREC)

3. SRS is not ready to receive or goes down in the mid of RS
	The solution might be:
	a. buffering in SRC(a small duration or all session), then detect and =
resend
	b. have two independent parallel SRS, with synchronization mechanism=20
	c. other ways? Switch to backup SRS (still loss during switching)?=20

Then, let's back to current documents.

1. I think RFC6341 covers all issues in different way.
	a. Use Case 10: No loss of media recording can occur, including during =
failure of an SRS (issue #1&#3)
	b. REQ-005: The mechanism MUST support the ability to record a CS =
without loss of media of RS (for example, clipping media at the =
beginning of the CS) (issue #2)
	c. REQ-021: The mechanism MUST NOT prevent high-availability =
deployments (issue #1#2#3)

2. draft-siprec-architecture and draft-siprec-protocol documents seem =
not cover enough details about how to handle these issues.
	a. The architecture document might reconsider the description in =
Section Introduction to avoid ambiguity: The Replicated Media is =
required to be sent in real-time to the SRS and is *not buffered* by the =
SRC to allow for real-time analysis of the media by the SRS.
	b. The protocol document has section 8.1.7 for the use of FIR for =
generating a full I-frame...Any more details needed?

Are those the quality of implementation issues, not a standardization =
issues? Any comments?

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


NICE Systems UK Limited ("NICE") is registered in England under company =
number, 3403044. The registered office of NICE is at Tollbar Way, Hedge =
End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for =
the above-named persons only and may be confidential and/or legally =
privileged. Any opinions expressed in this communication are not =
necessarily those of NICE. If this communication has come to you in =
error you must take no action based on it, nor must you copy or show it =
to anyone; please delete/destroy and inform the sender by e-mail =
immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail =
and attachments are free from any virus, we advise that in keeping with =
good computing practice the recipient should ensure they are actually =
virus free.


From br@brianrosen.net  Thu Feb 13 07:15:44 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 740E11A02AC for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 07:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.221
X-Spam-Level: 
X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 B6fkqoOPXAze for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 07:15:40 -0800 (PST)
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB30F1A008E for <siprec@ietf.org>; Thu, 13 Feb 2014 07:15:36 -0800 (PST)
Received: by mail-ig0-f172.google.com with SMTP id k19so13171658igc.5 for <siprec@ietf.org>; Thu, 13 Feb 2014 07:15:35 -0800 (PST)
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=OdTJJnL5KFVgf4hiIQGUvNLrQ7Ss4GOVkq3i9t/l4KI=; b=Zw24U065HUIJFlV1j9JR442Z0dJtKeQGr6DO+JPWmHYGEZTEVH0bb0pjz9U2HTqvxL sXLynBLQZMLYTLoQQg/nwTozpZ+DIvR+UWllj6JLTWiBGRQs3FkphsVchjv73q69Jood vocEhaGMo6bm3WOGhVd7OlZ/MefWFVvRNQ3zaS1mC+aBf9ft2ItEWoQ5hcOujuBDEt8Q qJjk9pECEkItkACSrZxJS/WiRwvqzmk4QXz+qpJ7tgLrvYFtfeIeII1SdgGW+THUK7wh B5/Js4R/Q7ng7UFYilYyAhCA3nOBisZjNU9PvnoVA2th1Sn65c1Nakzb6q0hoDI8/cka Bv4A==
X-Gm-Message-State: ALoCoQlZqaUp1vqsyOtP8eI41EL5i2uV5q+llKnkUh6RaF2s9QPq7P5eDggNPBnFArztU0IA1YWU
X-Received: by 10.51.17.40 with SMTP id gb8mr3660774igd.18.1392304535680; Thu, 13 Feb 2014 07:15:35 -0800 (PST)
Received: from [10.33.193.26] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id r6sm7749005igg.10.2014.02.13.07.15.33 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 07:15:34 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com>
Date: Thu, 13 Feb 2014 10:15:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D217034D-0DD6-4548-AECF-F6A9132D7DA9@brianrosen.net>
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com>
To: Dave Higton <DAVE.HIGTON@nice.com>
X-Mailer: Apple Mail (2.1827)
Cc: siprec@ietf.org
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 15:15:44 -0000

That=92s pretty radical.

Are you assuming that you record at least twice (two SRSs)?  That is a =
required part of HA, no matter what.

Then we have to determine if we need to improve the reliability of a =
single instance of an SRS.

That=92s a matter of the final required reliability, and is also related =
to how many copies you are making =3D the larger the number of SRSs, the =
lower the reliability of each one of them needed to get the overall =
reliability.

What=92s the goal?  4 nines?  5?

If you are trying to achieve 4 nines, you have 2 instances, then you =
need a fairly high reliability for each one of the instances, and we may =
need something like TCP to accomplish that.

If you have 3 instances, you might not need it.  Having said that, the =
math to determine what any real implementation needs is non trivial.

We might look at this as a tool box, support mechanisms to both increase =
reliability of a single instance and support more than one instance, and =
let the system designer determine how to achieve their reliability =
requirements with the tools.

Brian

On Feb 13, 2014, at 9:46 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:

> Here are a few assumptions on topics 1 and 3 for everybody to check =
out:
>=20
> * The network is engineered to have all the required bandwidth.
>=20
> * We can only cure occasional dropped packets.
>=20
> * If there is a hard failure, e.g. a network switch dies, no simple =
retry-based mechanism is going to solve it.  For those cases you need =
redundancy, eliminating all single points of failure.
>=20
> * We want to use an existing, tried and trusted, protocol; we don't =
want to engineer a new one.
>=20
> * We don't have significant numbers of implementations of lossless =
recording in the field, so whatever we do is going to be a change from =
what we do now.
>=20
> * Any SRC that implements SIPREC is engineered with enough RAM to =
buffer the media for long enough to deal with some retries.
>=20
> * SIPREC should cover lossless recording in enough detail that people =
can implement to it, referring to other RFCs where necessary.
>=20
> Based on the above assumptions, I'm suggesting that TCP is a tried and =
trusted solution to the problem of occasional dropped packets to the =
SRS.  TCP is usually discounted for RTP because of the increase in =
latency.  Clearly that is not a consideration for recording, because =
recording is inherently a time delay mechanism.
>=20
> RFC 4571 would appear to pretty much cover what is necessary for RTP =
over TCP, including an update to SDP to specify TCP.
>=20
> Comments?  Better suggestions?
>=20
> Dave
>=20
> -----Original Message-----
> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang =
(Michael)
> Sent: 13 February 2014 08:16
> To: siprec@ietf.org
> Subject: [siprec] Lossless recording/HA recording/media clipping? Open =
issues to SIPRECers?
>=20
> Hi guys,
>=20
> 	Recently there are discussions about several similar issues in =
mailing list. The 'lossless recording', 'HA recording', 'media clipping' =
are key words. Gerben had mentioned ' Lossless Recording' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html (not =
1st version for the issue but the explicit version in this WG). And =
Simon had mentioned 'media clipping' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html . Are =
those issues still open for us?
>=20
> 	I tried to collect all the issues and solutions to make them =
easy-to-discuss:
>=20
> 1. UDP Package loss in transmission
> 	The solution might be:
> 	a. FEC
> 	b. draft-ietf-avtext-rtp-duplication-05
> 	b. RTP over TCP to same SRS?
>=20
> 2. media clipping, esp for video clipping caused by I-frame lost
> 	The solution might be:
> 	a. FIR (RFC 5104). buffering in SRC (ready for full frame =
refresh), check and start from I-frame in RS
> 	b. a persistent RS...(already have in SIPREC)
>=20
> 3. SRS is not ready to receive or goes down in the mid of RS
> 	The solution might be:
> 	a. buffering in SRC(a small duration or all session), then =
detect and resend
> 	b. have two independent parallel SRS, with synchronization =
mechanism=20
> 	c. other ways? Switch to backup SRS (still loss during =
switching)?=20
>=20
> Then, let's back to current documents.
>=20
> 1. I think RFC6341 covers all issues in different way.
> 	a. Use Case 10: No loss of media recording can occur, including =
during failure of an SRS (issue #1&#3)
> 	b. REQ-005: The mechanism MUST support the ability to record a =
CS without loss of media of RS (for example, clipping media at the =
beginning of the CS) (issue #2)
> 	c. REQ-021: The mechanism MUST NOT prevent high-availability =
deployments (issue #1#2#3)
>=20
> 2. draft-siprec-architecture and draft-siprec-protocol documents seem =
not cover enough details about how to handle these issues.
> 	a. The architecture document might reconsider the description in =
Section Introduction to avoid ambiguity: The Replicated Media is =
required to be sent in real-time to the SRS and is *not buffered* by the =
SRC to allow for real-time analysis of the media by the SRS.
> 	b. The protocol document has section 8.1.7 for the use of FIR =
for generating a full I-frame...Any more details needed?
>=20
> Are those the quality of implementation issues, not a standardization =
issues? Any comments?
>=20
> Thanks,
> Michael
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>=20
>=20
> NICE Systems UK Limited ("NICE") is registered in England under =
company number, 3403044. The registered office of NICE is at Tollbar =
Way, Hedge End, Southampton, Hampshire SO30 2ZP.
>=20
> Confidentiality: This communication and any attachments are intended =
for the above-named persons only and may be confidential and/or legally =
privileged. Any opinions expressed in this communication are not =
necessarily those of NICE. If this communication has come to you in =
error you must take no action based on it, nor must you copy or show it =
to anyone; please delete/destroy and inform the sender by e-mail =
immediately.
>=20
> Monitoring: NICE may monitor incoming and outgoing e-mails.
>=20
> Viruses: Although we have taken steps toward ensuring that this e-mail =
and attachments are free from any virus, we advise that in keeping with =
good computing practice the recipient should ensure they are actually =
virus free.
>=20
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec


From pkyzivat@alum.mit.edu  Thu Feb 13 07:50: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 96BAF1A02F8 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 07:50:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level: 
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_62=0.6, 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 xpjghmVzfQ2i for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 07:50:44 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 7193C1A0294 for <siprec@ietf.org>; Thu, 13 Feb 2014 07:50:43 -0800 (PST)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta15.westchester.pa.mail.comcast.net with comcast id RqWd1n0030vyq2s5FrqiXH; Thu, 13 Feb 2014 15:50:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Rrqh1n00y3ZTu2S3Rrqi24; Thu, 13 Feb 2014 15:50:42 +0000
Message-ID: <52FCE9D1.4000506@alum.mit.edu>
Date: Thu, 13 Feb 2014 10:50:41 -0500
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.3.0
MIME-Version: 1.0
To: siprec@ietf.org
References: <CED5F30C.742EB%rmohanr@cisco.com> <CF21431F.1E339%eckelcu@cisco.com>
In-Reply-To: <CF21431F.1E339%eckelcu@cisco.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=q20121106; t=1392306642; bh=P9Y5zaSaIz4k7c7Ulx81VOCrtoV8VOkxJ6elmValP34=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kYofQj4hxObZDXjyS1JunF6H6Y4DYO0Hag8VhB8wzFj+gaI9wnVEU6jTBrXXaOgjJ HHJSs/YM1NHzr2GyDwiFjT2MDFsJc03o0rWjVzbi/B8k2SZ2l/irsa01cmiG1owxss BmUfb1IokitChoORas399z3HABZmDpPRCwTl/IkgvQ5ua4xBy73TaYT8C6Sa1QSV4V MKWBdvNjWGVLHaywUORjGoAjPWGleJ3rhuZtBAjYDOhLeX6aC3droKdYTbHtmeZqQu N/FzjUrAWrPBl2aQ5b2DtrnIwcoWQsKtQxZ5bKejZg9gc3l8KBEU5EOi9jT3jZCJpX GIqlb+w0/WdLw==
Subject: Re: [siprec] Text on how often(soon) SRC should send metadata/updates to SRS in protocol draft
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, 13 Feb 2014 15:50:46 -0000

I think this sounds pretty good. The one thing I wonder if whether we 
should add some discussion of conditions that might justify not 
following the SHOULD in "The SRC SHOULD send metadata as soon as it 
becomes available and whenever it changes."

Some things that come to mind are:

- Can't, or don't want to, send a new update until the prior one has
   completed. (If accompanied by an O/A you can't. Otherwise, using
   UPDATE you *can* but might not want to.)

- desire to generally constrain the signaling rate on the RS

- simplifying the SRC implementation by only sending updates when
   certain key events occur, not every event that *could* be
   reflected in an update.

- desire to suppress certain metadata out of concern for privacy
   and perceived lack of need for it to be included in the recording.
   (This is fundamentally different from the others.)

I'm not suggesting I believe all of the above are *good* justifications, 
I'm just trying to be exhaustive.

	Thanks,
	Paul

On 2/12/14 7:48 PM, Charles Eckel (eckelcu) wrote:
> We never reached a conclusion on this. I agree with Ram that section 9.1
> is the place to address this. The current text in section 9.1 contains
> some redundancy and does not flow all that well. I had a difficult
> inserting new text into it. I propose replacing with the following, which
> also addresses the issue raised by Paul and Ram.
> --------
>
> 9. Metadata
>
> Some metadata attributes are contained in SDP, and others are contained in
> a new content type
> "application/rs-metadata". The format of the metadata is described as part
> of the mechanism in [I-D.ietf-siprec-metadata]. A new "disposition-type"
> of Content-Disposition is defined for the
> purpose of carrying metadata. The value is "recording-session", which
> indicates the "application/rs-metadata" content contains metadata to be
> handled by the SRS.
>
>
> 9.1 Procedures at the SRC
>
> The SRC MUST send metadata to the SRS in an RS. The SRC SHOULD send
> metadata as soon as it becomes available and whenever it changes.
>
> Metadata sent by the SRC is categorized as either a full metadata snapshot
> or a partial update. A full metadata snapshot describes all metadata
> associated with the RS. The SRC MAY send a full metadata snapshot at any
> time. The SRC MAY send a partial update only if a full metadata snapshot
> has been sent previously.
>
>
> The SRC MAY send metadata (either a full metadata shapshot or a partial
> update) in an INVITE request, an UPDATE request [RFC3311], or an 200
> response to an offerless INVITE from the SRS. If the metadata contains a
> reference to any SDP labels, the request containing the metadata MUST also
> contain an SDP offer that defines those labels.
>
> When a SIP message contains both an SDP offer and metadata, the request
> body MUST have content type multipart/mixed, with one subordinate body
> part containing the SDP offer and another containing the metadata. When a
> SIP message contains only an SDP offer or metadata, the multipart/mixed
> container is optional.
>
>
>
> The SRC SHOULD include a full metadata snapshot in the initial INVITE
> request establishing the RS. If metadata is not yet available (e.g an RS
> established in absence of a CS), the SRC SHOULD send a full metadata
> snapshot as soon as metadata becomes available.
>
> If the SRC receives a snapshot request from the SRS, it MUST immediately
> send a full metadata snapshot.
> --------------
>
> Comments welcome.
>
> Cheers,
> Charles
>
>
> On 12/17/13 7:50 AM, "Ram Mohan R (rmohanr)" <rmohanr@cisco.com> wrote:
>
>> When Paul and me were reviewing the metadata draft we were discussing on
>> how quickly a SRC has to send updates to SRS. The updates can any
>> update(of CS changes ) from SRC from SRS. Currently we don't have any
>> recommendation / text on this in Protocol or Metadata draft.
>>
>>
>> For example, Suppose there is a sequence of changes on a single
>> <participantstreamassoc> XML element as below:
>>
>> T1: associate-time (A participant starts contributing to a stream)
>> -- snapshot 1 sent from SRC to SRS
>> T2: disassociate-time ((A participant stops contributing to a stream)
>> T3: associate-time (starts contributing again)
>> -- snapshot 2
>> T4: disassociate
>> T5: associate
>> T6: disassociate
>> -- snapshot 3
>>
>>
>> Any of the above can happen. Ideally an SRC is expected to send snapshot
>> updates as soon as possible (i.e after every transaction of CS). We have
>> discussed this point earlier in mailing list.
>>
>> The question is - Should we mandate this (MUST ?) with some text or just
>> add it as RECOMMENDATION. I am inclined with having it as RECOMMENDATION
>> and leave it to the implementors on deciding how soon they want to send
>> the updates from SRC to SRS.
>>
>> In any case we need some text and I believe section 9 of Protocol draft
>> that talks about
>>
>> Sending metadata from SRC to SRS is the right place to have this text.
>>
>> Comments ?
>>
>> Regards,
>> Ram
>>
>> _______________________________________________
>> 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 DAVE.HIGTON@nice.com  Thu Feb 13 08:01:01 2014
Return-Path: <DAVE.HIGTON@nice.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 AE5341A030C for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 08:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.548, 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 WL1wvaGnzDY5 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 08:00:57 -0800 (PST)
Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id B746B1A030D for <siprec@ietf.org>; Thu, 13 Feb 2014 08:00:48 -0800 (PST)
Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Thu, 13 Feb 2014 16:00:46 +0000
Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 16:00:21 +0000
Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Thu, 13 Feb 2014 16:00:21 +0000
From: "Dave Higton" <DAVE.HIGTON@nice.com>
To: <siprec@ietf.org>
Date: Thu, 13 Feb 2014 16:00:20 +0000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
Thread-Topic: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
Thread-Index: Ac8oznYJkCh5quFNT+u8NU/1I1CrwQABZwog
Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC57@SOUEXC01.eu.nice.com>
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com> <D217034D-0DD6-4548-AECF-F6A9132D7DA9@brianrosen.net>
In-Reply-To: <D217034D-0DD6-4548-AECF-F6A9132D7DA9@brianrosen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Feb 2014 16:00:21.0924 (UTC) FILETIME=[B30DD640:01CF28D4]
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 16:01:01 -0000

We're talking about two different issues here.  I'm talking about preventin=
g clipping and loss of occasional packets.  You're talking about redundancy=
 and high availability.  Simply adding redundant recording is going to do n=
othing to prevent clipping and loss of occasional packets, AFAICS.

Recording systems for NG911, for example, are going to have to address both=
 issues.

Dave

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]=20
Sent: 13 February 2014 15:16
To: Dave Higton
Cc: siprec@ietf.org
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open =
issues to SIPRECers?

That's pretty radical.

Are you assuming that you record at least twice (two SRSs)?  That is a requ=
ired part of HA, no matter what.

Then we have to determine if we need to improve the reliability of a single=
 instance of an SRS.

That's a matter of the final required reliability, and is also related to h=
ow many copies you are making =3D the larger the number of SRSs, the lower =
the reliability of each one of them needed to get the overall reliability.

What's the goal?  4 nines?  5?

If you are trying to achieve 4 nines, you have 2 instances, then you need a=
 fairly high reliability for each one of the instances, and we may need som=
ething like TCP to accomplish that.

If you have 3 instances, you might not need it.  Having said that, the math=
 to determine what any real implementation needs is non trivial.

We might look at this as a tool box, support mechanisms to both increase re=
liability of a single instance and support more than one instance, and let =
the system designer determine how to achieve their reliability requirements=
 with the tools.

Brian

On Feb 13, 2014, at 9:46 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:

> Here are a few assumptions on topics 1 and 3 for everybody to check out:
>=20
> * The network is engineered to have all the required bandwidth.
>=20
> * We can only cure occasional dropped packets.
>=20
> * If there is a hard failure, e.g. a network switch dies, no simple retry=
-based mechanism is going to solve it.  For those cases you need redundancy=
, eliminating all single points of failure.
>=20
> * We want to use an existing, tried and trusted, protocol; we don't want =
to engineer a new one.
>=20
> * We don't have significant numbers of implementations of lossless record=
ing in the field, so whatever we do is going to be a change from what we do=
 now.
>=20
> * Any SRC that implements SIPREC is engineered with enough RAM to buffer =
the media for long enough to deal with some retries.
>=20
> * SIPREC should cover lossless recording in enough detail that people can=
 implement to it, referring to other RFCs where necessary.
>=20
> Based on the above assumptions, I'm suggesting that TCP is a tried and tr=
usted solution to the problem of occasional dropped packets to the SRS.  TC=
P is usually discounted for RTP because of the increase in latency.  Clearl=
y that is not a consideration for recording, because recording is inherentl=
y a time delay mechanism.
>=20
> RFC 4571 would appear to pretty much cover what is necessary for RTP over=
 TCP, including an update to SDP to specify TCP.
>=20
> Comments?  Better suggestions?
>=20
> Dave
>=20
> -----Original Message-----
> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang (Mich=
ael)
> Sent: 13 February 2014 08:16
> To: siprec@ietf.org
> Subject: [siprec] Lossless recording/HA recording/media clipping? Open is=
sues to SIPRECers?
>=20
> Hi guys,
>=20
> 	Recently there are discussions about several similar issues in mailing l=
ist. The 'lossless recording', 'HA recording', 'media clipping' are key wor=
ds. Gerben had mentioned ' Lossless Recording' at http://www.ietf.org/mail-=
archive/web/siprec/current/msg03893.html (not 1st version for the issue but=
 the explicit version in this WG). And Simon had mentioned 'media clipping'=
 at http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html . Are=
 those issues still open for us?
>=20
> 	I tried to collect all the issues and solutions to make them easy-to-dis=
cuss:
>=20
> 1. UDP Package loss in transmission
> 	The solution might be:
> 	a. FEC
> 	b. draft-ietf-avtext-rtp-duplication-05
> 	b. RTP over TCP to same SRS?
>=20
> 2. media clipping, esp for video clipping caused by I-frame lost
> 	The solution might be:
> 	a. FIR (RFC 5104). buffering in SRC (ready for full frame refresh), chec=
k and start from I-frame in RS
> 	b. a persistent RS...(already have in SIPREC)
>=20
> 3. SRS is not ready to receive or goes down in the mid of RS
> 	The solution might be:
> 	a. buffering in SRC(a small duration or all session), then detect and re=
send
> 	b. have two independent parallel SRS, with synchronization mechanism=20
> 	c. other ways? Switch to backup SRS (still loss during switching)?=20
>=20
> Then, let's back to current documents.
>=20
> 1. I think RFC6341 covers all issues in different way.
> 	a. Use Case 10: No loss of media recording can occur, including during f=
ailure of an SRS (issue #1&#3)
> 	b. REQ-005: The mechanism MUST support the ability to record a CS withou=
t loss of media of RS (for example, clipping media at the beginning of the =
CS) (issue #2)
> 	c. REQ-021: The mechanism MUST NOT prevent high-availability deployments=
 (issue #1#2#3)
>=20
> 2. draft-siprec-architecture and draft-siprec-protocol documents seem not=
 cover enough details about how to handle these issues.
> 	a. The architecture document might reconsider the description in Section=
 Introduction to avoid ambiguity: The Replicated Media is required to be se=
nt in real-time to the SRS and is *not buffered* by the SRC to allow for re=
al-time analysis of the media by the SRS.
> 	b. The protocol document has section 8.1.7 for the use of FIR for genera=
ting a full I-frame...Any more details needed?
>=20
> Are those the quality of implementation issues, not a standardization iss=
ues? Any comments?
>=20
> Thanks,
> Michael
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>=20
>=20
> NICE Systems UK Limited ("NICE") is registered in England under company n=
umber, 3403044. The registered office of NICE is at Tollbar Way, Hedge End,=
 Southampton, Hampshire SO30 2ZP.
>=20
> Confidentiality: This communication and any attachments are intended for =
the above-named persons only and may be confidential and/or legally privile=
ged. Any opinions expressed in this communication are not necessarily those=
 of NICE. If this communication has come to you in error you must take no a=
ction based on it, nor must you copy or show it to anyone; please delete/de=
stroy and inform the sender by e-mail immediately.
>=20
> Monitoring: NICE may monitor incoming and outgoing e-mails.
>=20
> Viruses: Although we have taken steps toward ensuring that this e-mail an=
d attachments are free from any virus, we advise that in keeping with good =
computing practice the recipient should ensure they are actually virus free=
.
>=20
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec


From partha@parthasarathi.co.in  Thu Feb 13 08:39:58 2014
Return-Path: <partha@parthasarathi.co.in>
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 500A91A033F for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 08:39:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level: 
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] 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 TMini1EIzMGM for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 08:39:54 -0800 (PST)
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id C06A91A030C for <siprec@ietf.org>; Thu, 13 Feb 2014 08:39:54 -0800 (PST)
Received: from userPC (unknown [122.167.96.102]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 318ADA2804E; Thu, 13 Feb 2014 16:39:49 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1392309592; bh=szkF6liVotZ62LzDm1z3S1UCVLAC4SL1XxWpuhRbC9c=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bF6VC4Leax13tEp3By+i0AkinOLLlHaKG8w0MB2SBgemHZjRTD651eJvDtBtnUyfO PURHXUyx7JmQTJVoCjV8csCYcbrrAOHMgWr/HrnNox6/qlFcveuZSDM+K6t0mlQrcZ wIRrpidVseRhlPILFFkwzeSLwCqPCYJujhqGKjn8=
From: "Parthasarathi R" <partha@parthasarathi.co.in>
To: "'Dave Higton'" <DAVE.HIGTON@nice.com>, <siprec@ietf.org>
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com> <D217034D-0DD6-4548-AECF-F6A9132D7DA9@brianrosen.net> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC57@SOUEXC01.eu.nice.com>
In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC57@SOUEXC01.eu.nice.com>
Date: Thu, 13 Feb 2014 22:09:42 +0530
Message-ID: <023601cf28da$347f6720$9d7e3560$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac8oznYJkCh5quFNT+u8NU/1I1CrwQABZwogAAC6DiA=
Content-Language: en-us
x-cr-hashedpuzzle: AHq2 A0Wc DryE EtIN F2S5 GQ2e Ga/2 JcCs KeEs OtVQ O0dE Qled SCA7 SYw6 UXoe VHJw; 2; ZABhAHYAZQAuAGgAaQBnAHQAbwBuAEAAbgBpAGMAZQAuAGMAbwBtADsAcwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {116590FB-BE19-44C3-A862-CDD96E422779}; cABhAHIAdABoAGEAQABwAGEAcgB0AGgAYQBzAGEAcgBhAHQAaABpAC4AYwBvAC4AaQBuAA==; Thu, 13 Feb 2014 16:39:38 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABMAG8AcwBzAGwAZQBzAHMAIAByAGUAYwBvAHIAZABpAG4AZwAvAEgAQQAgAHIAZQBjAG8AcgBkAGkAbgBnAC8AbQBlAGQAaQBhACAAYwBsAGkAcABwAGkAbgBnAD8AIABPAHAAZQBuAAkAaQBzAHMAdQBlAHMAIAB0AG8AIABTAEkAUABSAEUAQwBlAHIAcwA/AA==
x-cr-puzzleid: {116590FB-BE19-44C3-A862-CDD96E422779}
X-CTCH-RefID: str=0001.0A020203.52FCF559.00B7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open	issues to SIPRECers?
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, 13 Feb 2014 16:39:58 -0000

Hi Dave,

Initial Clipping shall be avoided in case RS callflow is designed in a
better way. Please note that I'm not talking only about persistent RS. If
required, we will add more example callflow to illustrate the same. 

Thanks
Partha


> -----Original Message-----
> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Dave Higton
> Sent: Thursday, February 13, 2014 9:30 PM
> To: siprec@ietf.org
> Subject: Re: [siprec] Lossless recording/HA recording/media clipping?
> Open issues to SIPRECers?
> 
> We're talking about two different issues here.  I'm talking about
> preventing clipping and loss of occasional packets.  You're talking
> about redundancy and high availability.  Simply adding redundant
> recording is going to do nothing to prevent clipping and loss of
> occasional packets, AFAICS.
> 
> Recording systems for NG911, for example, are going to have to address
> both issues.
> 
> Dave
> 
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: 13 February 2014 15:16
> To: Dave Higton
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Lossless recording/HA recording/media clipping?
> Open issues to SIPRECers?
> 
> That's pretty radical.
> 
> Are you assuming that you record at least twice (two SRSs)?  That is a
> required part of HA, no matter what.
> 
> Then we have to determine if we need to improve the reliability of a
> single instance of an SRS.
> 
> That's a matter of the final required reliability, and is also related
> to how many copies you are making = the larger the number of SRSs, the
> lower the reliability of each one of them needed to get the overall
> reliability.
> 
> What's the goal?  4 nines?  5?
> 
> If you are trying to achieve 4 nines, you have 2 instances, then you
> need a fairly high reliability for each one of the instances, and we
> may need something like TCP to accomplish that.
> 
> If you have 3 instances, you might not need it.  Having said that, the
> math to determine what any real implementation needs is non trivial.
> 
> We might look at this as a tool box, support mechanisms to both
> increase reliability of a single instance and support more than one
> instance, and let the system designer determine how to achieve their
> reliability requirements with the tools.
> 
> Brian
> 
> On Feb 13, 2014, at 9:46 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:
> 
> > Here are a few assumptions on topics 1 and 3 for everybody to check
> out:
> >
> > * The network is engineered to have all the required bandwidth.
> >
> > * We can only cure occasional dropped packets.
> >
> > * If there is a hard failure, e.g. a network switch dies, no simple
> retry-based mechanism is going to solve it.  For those cases you need
> redundancy, eliminating all single points of failure.
> >
> > * We want to use an existing, tried and trusted, protocol; we don't
> want to engineer a new one.
> >
> > * We don't have significant numbers of implementations of lossless
> recording in the field, so whatever we do is going to be a change from
> what we do now.
> >
> > * Any SRC that implements SIPREC is engineered with enough RAM to
> buffer the media for long enough to deal with some retries.
> >
> > * SIPREC should cover lossless recording in enough detail that people
> can implement to it, referring to other RFCs where necessary.
> >
> > Based on the above assumptions, I'm suggesting that TCP is a tried
> and trusted solution to the problem of occasional dropped packets to
> the SRS.  TCP is usually discounted for RTP because of the increase in
> latency.  Clearly that is not a consideration for recording, because
> recording is inherently a time delay mechanism.
> >
> > RFC 4571 would appear to pretty much cover what is necessary for RTP
> over TCP, including an update to SDP to specify TCP.
> >
> > Comments?  Better suggestions?
> >
> > Dave
> >
> > -----Original Message-----
> > From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang
> (Michael)
> > Sent: 13 February 2014 08:16
> > To: siprec@ietf.org
> > Subject: [siprec] Lossless recording/HA recording/media clipping?
> Open issues to SIPRECers?
> >
> > Hi guys,
> >
> > 	Recently there are discussions about several similar issues in
> mailing list. The 'lossless recording', 'HA recording', 'media
> clipping' are key words. Gerben had mentioned ' Lossless Recording' at
> http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html (not
> 1st version for the issue but the explicit version in this WG). And
> Simon had mentioned 'media clipping' at http://www.ietf.org/mail-
> archive/web/siprec/current/msg03839.html . Are those issues still open
> for us?
> >
> > 	I tried to collect all the issues and solutions to make them
> easy-to-discuss:
> >
> > 1. UDP Package loss in transmission
> > 	The solution might be:
> > 	a. FEC
> > 	b. draft-ietf-avtext-rtp-duplication-05
> > 	b. RTP over TCP to same SRS?
> >
> > 2. media clipping, esp for video clipping caused by I-frame lost
> > 	The solution might be:
> > 	a. FIR (RFC 5104). buffering in SRC (ready for full frame
> refresh), check and start from I-frame in RS
> > 	b. a persistent RS...(already have in SIPREC)
> >
> > 3. SRS is not ready to receive or goes down in the mid of RS
> > 	The solution might be:
> > 	a. buffering in SRC(a small duration or all session), then detect
> and resend
> > 	b. have two independent parallel SRS, with synchronization
> mechanism
> > 	c. other ways? Switch to backup SRS (still loss during
> switching)?
> >
> > Then, let's back to current documents.
> >
> > 1. I think RFC6341 covers all issues in different way.
> > 	a. Use Case 10: No loss of media recording can occur, including
> during failure of an SRS (issue #1&#3)
> > 	b. REQ-005: The mechanism MUST support the ability to record a CS
> without loss of media of RS (for example, clipping media at the
> beginning of the CS) (issue #2)
> > 	c. REQ-021: The mechanism MUST NOT prevent high-availability
> deployments (issue #1#2#3)
> >
> > 2. draft-siprec-architecture and draft-siprec-protocol documents seem
> not cover enough details about how to handle these issues.
> > 	a. The architecture document might reconsider the description in
> Section Introduction to avoid ambiguity: The Replicated Media is
> required to be sent in real-time to the SRS and is *not buffered* by
> the SRC to allow for real-time analysis of the media by the SRS.
> > 	b. The protocol document has section 8.1.7 for the use of FIR for
> generating a full I-frame...Any more details needed?
> >
> > Are those the quality of implementation issues, not a standardization
> issues? Any comments?
> >
> > Thanks,
> > Michael
> > _______________________________________________
> > siprec mailing list
> > siprec@ietf.org
> > https://www.ietf.org/mailman/listinfo/siprec
> >
> >
> > NICE Systems UK Limited ("NICE") is registered in England under
> company number, 3403044. The registered office of NICE is at Tollbar
> Way, Hedge End, Southampton, Hampshire SO30 2ZP.
> >
> > Confidentiality: This communication and any attachments are intended
> for the above-named persons only and may be confidential and/or legally
> privileged. Any opinions expressed in this communication are not
> necessarily those of NICE. If this communication has come to you in
> error you must take no action based on it, nor must you copy or show it
> to anyone; please delete/destroy and inform the sender by e-mail
> immediately.
> >
> > Monitoring: NICE may monitor incoming and outgoing e-mails.
> >
> > Viruses: Although we have taken steps toward ensuring that this e-
> mail and attachments are free from any virus, we advise that in keeping
> with good computing practice the recipient should ensure they are
> actually virus free.
> >
> > _______________________________________________
> > 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 br@brianrosen.net  Thu Feb 13 09:17: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 6F9C41A02BC for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 09:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.221
X-Spam-Level: 
X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 hc4inNaiQH4a for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 09:17:32 -0800 (PST)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id BCC9A1A02B5 for <siprec@ietf.org>; Thu, 13 Feb 2014 09:17:32 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id k4so16687763qaq.15 for <siprec@ietf.org>; Thu, 13 Feb 2014 09:17:31 -0800 (PST)
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=Dpzt3hRE9nCsZkyfK7zjBQR4r4I1qs/qTIsTy3UIfGk=; b=NAJas6NoWT/WruYMcuONkx/tgIv6J+Q/oZddBTGCq36iWS+1pEDHtfwJZnqaB0P29/ oKwXr/KhGMsaJh/9GzCRRB+sjXfbcmDcYIpccUSpGnrP0UZP+Qnw+mQ0zBfzXcX94avs 99L89HC9zRzSpROZL0qAH625+0RzZOm75nv+2+q6/8sNqdbobK3Ac6a5+iWhqpx5OV4R 1GRyica5fDVpclL+vgDPN5LLAuTX/iSzIhi0zj/4tfO6hqksr3Znv6vDF0WQFC8myihQ YQyz2/xFk2+7bIMcW3c3Oknr8DrMVRvvndNdTIZXwP8XvhOTUF7M8n+eWXA2WH41l6Gv cvGA==
X-Gm-Message-State: ALoCoQnL7x86XdqyOEIH4oScr2bQln7s+UJHqUMc1rr3UIsqsms8MyHJkh2ftVB3arzr9ljA2s6w
X-Received: by 10.140.22.39 with SMTP id 36mr4116471qgm.59.1392311851433; Thu, 13 Feb 2014 09:17:31 -0800 (PST)
Received: from [10.33.193.26] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id y71sm3482826qgd.3.2014.02.13.09.17.29 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 09:17:30 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC57@SOUEXC01.eu.nice.com>
Date: Thu, 13 Feb 2014 12:17:28 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <872CCB08-4D96-4C42-AAC1-331AA8695D01@brianrosen.net>
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com> <D217034D-0DD6-4548-AECF-F6A9132D7DA9@brianrosen.net> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC57@SOUEXC01.eu.nice.com>
To: Dave Higton <DAVE.HIGTON@nice.com>
X-Mailer: Apple Mail (2.1827)
Cc: siprec@ietf.org
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 17:17:35 -0000

Huh.  You said you were addressing points 1 and 3 (packet loss and SRS =
failure).  Clipping is point 2.

Confusion.  I was addressing mostly 3, but usually if you have two =
independent copies of a stream, you could get 1 covered as long as you =
can somehow merge the streams (since the packets will have the same =
samples in them).

Brian


On Feb 13, 2014, at 11:00 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:

> We're talking about two different issues here.  I'm talking about =
preventing clipping and loss of occasional packets.  You're talking =
about redundancy and high availability.  Simply adding redundant =
recording is going to do nothing to prevent clipping and loss of =
occasional packets, AFAICS.
>=20
> Recording systems for NG911, for example, are going to have to address =
both issues.
>=20
> Dave
>=20
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]=20
> Sent: 13 February 2014 15:16
> To: Dave Higton
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Lossless recording/HA recording/media clipping? =
Open issues to SIPRECers?
>=20
> That's pretty radical.
>=20
> Are you assuming that you record at least twice (two SRSs)?  That is a =
required part of HA, no matter what.
>=20
> Then we have to determine if we need to improve the reliability of a =
single instance of an SRS.
>=20
> That's a matter of the final required reliability, and is also related =
to how many copies you are making =3D the larger the number of SRSs, the =
lower the reliability of each one of them needed to get the overall =
reliability.
>=20
> What's the goal?  4 nines?  5?
>=20
> If you are trying to achieve 4 nines, you have 2 instances, then you =
need a fairly high reliability for each one of the instances, and we may =
need something like TCP to accomplish that.
>=20
> If you have 3 instances, you might not need it.  Having said that, the =
math to determine what any real implementation needs is non trivial.
>=20
> We might look at this as a tool box, support mechanisms to both =
increase reliability of a single instance and support more than one =
instance, and let the system designer determine how to achieve their =
reliability requirements with the tools.
>=20
> Brian
>=20
> On Feb 13, 2014, at 9:46 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:
>=20
>> Here are a few assumptions on topics 1 and 3 for everybody to check =
out:
>>=20
>> * The network is engineered to have all the required bandwidth.
>>=20
>> * We can only cure occasional dropped packets.
>>=20
>> * If there is a hard failure, e.g. a network switch dies, no simple =
retry-based mechanism is going to solve it.  For those cases you need =
redundancy, eliminating all single points of failure.
>>=20
>> * We want to use an existing, tried and trusted, protocol; we don't =
want to engineer a new one.
>>=20
>> * We don't have significant numbers of implementations of lossless =
recording in the field, so whatever we do is going to be a change from =
what we do now.
>>=20
>> * Any SRC that implements SIPREC is engineered with enough RAM to =
buffer the media for long enough to deal with some retries.
>>=20
>> * SIPREC should cover lossless recording in enough detail that people =
can implement to it, referring to other RFCs where necessary.
>>=20
>> Based on the above assumptions, I'm suggesting that TCP is a tried =
and trusted solution to the problem of occasional dropped packets to the =
SRS.  TCP is usually discounted for RTP because of the increase in =
latency.  Clearly that is not a consideration for recording, because =
recording is inherently a time delay mechanism.
>>=20
>> RFC 4571 would appear to pretty much cover what is necessary for RTP =
over TCP, including an update to SDP to specify TCP.
>>=20
>> Comments?  Better suggestions?
>>=20
>> Dave
>>=20
>> -----Original Message-----
>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang =
(Michael)
>> Sent: 13 February 2014 08:16
>> To: siprec@ietf.org
>> Subject: [siprec] Lossless recording/HA recording/media clipping? =
Open issues to SIPRECers?
>>=20
>> Hi guys,
>>=20
>> 	Recently there are discussions about several similar issues in =
mailing list. The 'lossless recording', 'HA recording', 'media clipping' =
are key words. Gerben had mentioned ' Lossless Recording' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html (not =
1st version for the issue but the explicit version in this WG). And =
Simon had mentioned 'media clipping' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html . Are =
those issues still open for us?
>>=20
>> 	I tried to collect all the issues and solutions to make them =
easy-to-discuss:
>>=20
>> 1. UDP Package loss in transmission
>> 	The solution might be:
>> 	a. FEC
>> 	b. draft-ietf-avtext-rtp-duplication-05
>> 	b. RTP over TCP to same SRS?
>>=20
>> 2. media clipping, esp for video clipping caused by I-frame lost
>> 	The solution might be:
>> 	a. FIR (RFC 5104). buffering in SRC (ready for full frame =
refresh), check and start from I-frame in RS
>> 	b. a persistent RS...(already have in SIPREC)
>>=20
>> 3. SRS is not ready to receive or goes down in the mid of RS
>> 	The solution might be:
>> 	a. buffering in SRC(a small duration or all session), then =
detect and resend
>> 	b. have two independent parallel SRS, with synchronization =
mechanism=20
>> 	c. other ways? Switch to backup SRS (still loss during =
switching)?=20
>>=20
>> Then, let's back to current documents.
>>=20
>> 1. I think RFC6341 covers all issues in different way.
>> 	a. Use Case 10: No loss of media recording can occur, including =
during failure of an SRS (issue #1&#3)
>> 	b. REQ-005: The mechanism MUST support the ability to record a =
CS without loss of media of RS (for example, clipping media at the =
beginning of the CS) (issue #2)
>> 	c. REQ-021: The mechanism MUST NOT prevent high-availability =
deployments (issue #1#2#3)
>>=20
>> 2. draft-siprec-architecture and draft-siprec-protocol documents seem =
not cover enough details about how to handle these issues.
>> 	a. The architecture document might reconsider the description in =
Section Introduction to avoid ambiguity: The Replicated Media is =
required to be sent in real-time to the SRS and is *not buffered* by the =
SRC to allow for real-time analysis of the media by the SRS.
>> 	b. The protocol document has section 8.1.7 for the use of FIR =
for generating a full I-frame...Any more details needed?
>>=20
>> Are those the quality of implementation issues, not a standardization =
issues? Any comments?
>>=20
>> Thanks,
>> Michael
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>>=20
>>=20
>> NICE Systems UK Limited ("NICE") is registered in England under =
company number, 3403044. The registered office of NICE is at Tollbar =
Way, Hedge End, Southampton, Hampshire SO30 2ZP.
>>=20
>> Confidentiality: This communication and any attachments are intended =
for the above-named persons only and may be confidential and/or legally =
privileged. Any opinions expressed in this communication are not =
necessarily those of NICE. If this communication has come to you in =
error you must take no action based on it, nor must you copy or show it =
to anyone; please delete/destroy and inform the sender by e-mail =
immediately.
>>=20
>> Monitoring: NICE may monitor incoming and outgoing e-mails.
>>=20
>> Viruses: Although we have taken steps toward ensuring that this =
e-mail and attachments are free from any virus, we advise that in =
keeping with good computing practice the recipient should ensure they =
are actually virus free.
>>=20
>> _______________________________________________
>> 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 Thu Feb 13 09:35:04 2014
Return-Path: <DAVE.HIGTON@nice.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 6DE051A02F5 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 09:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.548, 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 DKAkLu6nV4yS for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 09:34:58 -0800 (PST)
Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id BE6171A02D4 for <siprec@ietf.org>; Thu, 13 Feb 2014 09:34:57 -0800 (PST)
Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Thu, 13 Feb 2014 17:34:56 +0000
Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 17:34:55 +0000
Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Thu, 13 Feb 2014 17:34:54 +0000
From: "Dave Higton" <DAVE.HIGTON@nice.com>
To: <siprec@ietf.org>
Date: Thu, 13 Feb 2014 17:34:54 +0000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
Thread-Topic: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
Thread-Index: Ac8o34Gybe7Pf2aBQoagKR+1FhHANwAAVFdA
Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC88@SOUEXC01.eu.nice.com>
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com> <D217034D-0DD6-4548-AECF-F6A9132D7DA9@brianrosen.net> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC57@SOUEXC01.eu.nice.com> <872CCB08-4D96-4C42-AAC1-331AA8695D01@brianrosen.net>
In-Reply-To: <872CCB08-4D96-4C42-AAC1-331AA8695D01@brianrosen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Feb 2014 17:34:55.0450 (UTC) FILETIME=[E8BD33A0:01CF28E1]
Archived-At: http://mailarchive.ietf.org/archive/details/siprec/4d4SSrZJJs0QwLgVspCpE9bvNcs
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 17:35:01 -0000

Ah, my apologies.  I wasn't paying enough attention to the contents of the =
issues.  I saw video in 2 and dismissed it as "I don't know enough about th=
is", whereas it's actually about clipping of any media stream.

Perhaps I should start again...

But I believe that redundancy does not address clipping at all, and cannot =
be relied upon to fix occasional loss of packets.

Dave

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]=20
Sent: 13 February 2014 17:17
To: Dave Higton
Cc: siprec@ietf.org
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open =
issues to SIPRECers?

Huh.  You said you were addressing points 1 and 3 (packet loss and SRS fail=
ure).  Clipping is point 2.

Confusion.  I was addressing mostly 3, but usually if you have two independ=
ent copies of a stream, you could get 1 covered as long as you can somehow =
merge the streams (since the packets will have the same samples in them).

Brian


On Feb 13, 2014, at 11:00 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:

> We're talking about two different issues here.  I'm talking about prevent=
ing clipping and loss of occasional packets.  You're talking about redundan=
cy and high availability.  Simply adding redundant recording is going to do=
 nothing to prevent clipping and loss of occasional packets, AFAICS.
>=20
> Recording systems for NG911, for example, are going to have to address bo=
th issues.
>=20
> Dave
>=20
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]=20
> Sent: 13 February 2014 15:16
> To: Dave Higton
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Ope=
n issues to SIPRECers?
>=20
> That's pretty radical.
>=20
> Are you assuming that you record at least twice (two SRSs)?  That is a re=
quired part of HA, no matter what.
>=20
> Then we have to determine if we need to improve the reliability of a sing=
le instance of an SRS.
>=20
> That's a matter of the final required reliability, and is also related to=
 how many copies you are making =3D the larger the number of SRSs, the lowe=
r the reliability of each one of them needed to get the overall reliability=
.
>=20
> What's the goal?  4 nines?  5?
>=20
> If you are trying to achieve 4 nines, you have 2 instances, then you need=
 a fairly high reliability for each one of the instances, and we may need s=
omething like TCP to accomplish that.
>=20
> If you have 3 instances, you might not need it.  Having said that, the ma=
th to determine what any real implementation needs is non trivial.
>=20
> We might look at this as a tool box, support mechanisms to both increase =
reliability of a single instance and support more than one instance, and le=
t the system designer determine how to achieve their reliability requiremen=
ts with the tools.
>=20
> Brian
>=20
> On Feb 13, 2014, at 9:46 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:
>=20
>> Here are a few assumptions on topics 1 and 3 for everybody to check out:
>>=20
>> * The network is engineered to have all the required bandwidth.
>>=20
>> * We can only cure occasional dropped packets.
>>=20
>> * If there is a hard failure, e.g. a network switch dies, no simple retr=
y-based mechanism is going to solve it.  For those cases you need redundanc=
y, eliminating all single points of failure.
>>=20
>> * We want to use an existing, tried and trusted, protocol; we don't want=
 to engineer a new one.
>>=20
>> * We don't have significant numbers of implementations of lossless recor=
ding in the field, so whatever we do is going to be a change from what we d=
o now.
>>=20
>> * Any SRC that implements SIPREC is engineered with enough RAM to buffer=
 the media for long enough to deal with some retries.
>>=20
>> * SIPREC should cover lossless recording in enough detail that people ca=
n implement to it, referring to other RFCs where necessary.
>>=20
>> Based on the above assumptions, I'm suggesting that TCP is a tried and t=
rusted solution to the problem of occasional dropped packets to the SRS.  T=
CP is usually discounted for RTP because of the increase in latency.  Clear=
ly that is not a consideration for recording, because recording is inherent=
ly a time delay mechanism.
>>=20
>> RFC 4571 would appear to pretty much cover what is necessary for RTP ove=
r TCP, including an update to SDP to specify TCP.
>>=20
>> Comments?  Better suggestions?
>>=20
>> Dave
>>=20
>> -----Original Message-----
>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang (Mic=
hael)
>> Sent: 13 February 2014 08:16
>> To: siprec@ietf.org
>> Subject: [siprec] Lossless recording/HA recording/media clipping? Open i=
ssues to SIPRECers?
>>=20
>> Hi guys,
>>=20
>> 	Recently there are discussions about several similar issues in mailing =
list. The 'lossless recording', 'HA recording', 'media clipping' are key wo=
rds. Gerben had mentioned ' Lossless Recording' at http://www.ietf.org/mail=
-archive/web/siprec/current/msg03893.html (not 1st version for the issue bu=
t the explicit version in this WG). And Simon had mentioned 'media clipping=
' at http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html . Ar=
e those issues still open for us?
>>=20
>> 	I tried to collect all the issues and solutions to make them easy-to-di=
scuss:
>>=20
>> 1. UDP Package loss in transmission
>> 	The solution might be:
>> 	a. FEC
>> 	b. draft-ietf-avtext-rtp-duplication-05
>> 	b. RTP over TCP to same SRS?
>>=20
>> 2. media clipping, esp for video clipping caused by I-frame lost
>> 	The solution might be:
>> 	a. FIR (RFC 5104). buffering in SRC (ready for full frame refresh), che=
ck and start from I-frame in RS
>> 	b. a persistent RS...(already have in SIPREC)
>>=20
>> 3. SRS is not ready to receive or goes down in the mid of RS
>> 	The solution might be:
>> 	a. buffering in SRC(a small duration or all session), then detect and r=
esend
>> 	b. have two independent parallel SRS, with synchronization mechanism=20
>> 	c. other ways? Switch to backup SRS (still loss during switching)?=20
>>=20
>> Then, let's back to current documents.
>>=20
>> 1. I think RFC6341 covers all issues in different way.
>> 	a. Use Case 10: No loss of media recording can occur, including during =
failure of an SRS (issue #1&#3)
>> 	b. REQ-005: The mechanism MUST support the ability to record a CS witho=
ut loss of media of RS (for example, clipping media at the beginning of the=
 CS) (issue #2)
>> 	c. REQ-021: The mechanism MUST NOT prevent high-availability deployment=
s (issue #1#2#3)
>>=20
>> 2. draft-siprec-architecture and draft-siprec-protocol documents seem no=
t cover enough details about how to handle these issues.
>> 	a. The architecture document might reconsider the description in Sectio=
n Introduction to avoid ambiguity: The Replicated Media is required to be s=
ent in real-time to the SRS and is *not buffered* by the SRC to allow for r=
eal-time analysis of the media by the SRS.
>> 	b. The protocol document has section 8.1.7 for the use of FIR for gener=
ating a full I-frame...Any more details needed?
>>=20
>> Are those the quality of implementation issues, not a standardization is=
sues? Any comments?
>>=20
>> Thanks,
>> Michael
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>>=20
>>=20
>> NICE Systems UK Limited ("NICE") is registered in England under company =
number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End=
, Southampton, Hampshire SO30 2ZP.
>>=20
>> Confidentiality: This communication and any attachments are intended for=
 the above-named persons only and may be confidential and/or legally privil=
eged. Any opinions expressed in this communication are not necessarily thos=
e of NICE. If this communication has come to you in error you must take no =
action based on it, nor must you copy or show it to anyone; please delete/d=
estroy and inform the sender by e-mail immediately.
>>=20
>> Monitoring: NICE may monitor incoming and outgoing e-mails.
>>=20
>> Viruses: Although we have taken steps toward ensuring that this e-mail a=
nd attachments are free from any virus, we advise that in keeping with good=
 computing practice the recipient should ensure they are actually virus fre=
e.
>>=20
>> _______________________________________________
>> 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 Thu Feb 13 10:49:25 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 1827A1A03F2 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 10:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level: 
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, 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 UvbULllfJ-Kt for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 10:49:20 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id A83DF1A03F7 for <siprec@ietf.org>; Thu, 13 Feb 2014 10:49:19 -0800 (PST)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id RpPb1n0060Fqzac54upHMy; Thu, 13 Feb 2014 18:49:17 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id RupH1n00W3ZTu2S3UupHy2; Thu, 13 Feb 2014 18:49:17 +0000
Message-ID: <52FD13AD.6060209@alum.mit.edu>
Date: Thu, 13 Feb 2014 13:49:17 -0500
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.3.0
MIME-Version: 1.0
To: siprec@ietf.org
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com> <D217034D-0DD6-4548-AECF-F6A9132D7DA9@brianrosen.net> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC57@SOUEXC01.eu.nice.com> <872CCB08-4D96-4C42-AAC1-331AA8695D01@brianrosen.net> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC88@SOUEXC01.eu.nice.com>
In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC88@SOUEXC01.eu.nice.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=q20121106; t=1392317357; bh=C/tIf6Hg/H7e8mirulFWqmjYehGXHtE9/ytFUV4LVJ8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=opJrzep76T9R5tTxogGZCDLvfB/t4GZdo4dtSnCpg7Y5FlGBgtB9mIYx0SdoLGRf8 CyK/Q7LDirUWYpUsd6KkX3lM3tMveOwH9UrKTdeOAZnctHlJK+FbjoEjOuVXESXfgH cd5oSsvWkDUn/xVVPW8MqFAvQVLih5yGoRK8h5ymfEoQy7Z+0PXDu8ZPka7nV1xHhA I36yC2xpfJfoBMTfcFFC8Pb6r0jc/iuWNWQuB54Rkkcaq5ArhSh/w5lyNx85ajxwEc 7VIdW46Y5rwJGRzf6JQIqYDAeKT6AARGy9NwuLhwxtACZdkPAAg1xlH3nsAZ5nwyEh jpl+ROI/rayhg==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/IGR__dn-VjbrNFt21xDvH2hdX_0
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 18:49:23 -0000

On 2/13/14 12:34 PM, Dave Higton wrote:
> Ah, my apologies.  I wasn't paying enough attention to the contents of the issues.  I saw video in 2 and dismissed it as "I don't know enough about this", whereas it's actually about clipping of any media stream.
>
> Perhaps I should start again...
>
> But I believe that redundancy does not address clipping at all, and cannot be relied upon to fix occasional loss of packets.

Redundancy could fix the occasional loss of packets, with some effort, 
if the redundant paths are completely independent. (Synchronize the two 
recordings after the fact, with each filling holes in the other. This 
assumes that probability of dropping the same packet on both paths is low.)

I guess addressing clipping requires local buffering, and sufficient 
bandwidth to catch up once you have a connection. Agree it doesn't have 
anything to do with redundancy, except in cases where it is quicker to 
establish a connection to one path than the other.

	Thanks,
	Paul

> Dave
>
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: 13 February 2014 17:17
> To: Dave Higton
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
>
> Huh.  You said you were addressing points 1 and 3 (packet loss and SRS failure).  Clipping is point 2.
>
> Confusion.  I was addressing mostly 3, but usually if you have two independent copies of a stream, you could get 1 covered as long as you can somehow merge the streams (since the packets will have the same samples in them).
>
> Brian
>
>
> On Feb 13, 2014, at 11:00 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:
>
>> We're talking about two different issues here.  I'm talking about preventing clipping and loss of occasional packets.  You're talking about redundancy and high availability.  Simply adding redundant recording is going to do nothing to prevent clipping and loss of occasional packets, AFAICS.
>>
>> Recording systems for NG911, for example, are going to have to address both issues.
>>
>> Dave
>>
>> -----Original Message-----
>> From: Brian Rosen [mailto:br@brianrosen.net]
>> Sent: 13 February 2014 15:16
>> To: Dave Higton
>> Cc: siprec@ietf.org
>> Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
>>
>> That's pretty radical.
>>
>> Are you assuming that you record at least twice (two SRSs)?  That is a required part of HA, no matter what.
>>
>> Then we have to determine if we need to improve the reliability of a single instance of an SRS.
>>
>> That's a matter of the final required reliability, and is also related to how many copies you are making = the larger the number of SRSs, the lower the reliability of each one of them needed to get the overall reliability.
>>
>> What's the goal?  4 nines?  5?
>>
>> If you are trying to achieve 4 nines, you have 2 instances, then you need a fairly high reliability for each one of the instances, and we may need something like TCP to accomplish that.
>>
>> If you have 3 instances, you might not need it.  Having said that, the math to determine what any real implementation needs is non trivial.
>>
>> We might look at this as a tool box, support mechanisms to both increase reliability of a single instance and support more than one instance, and let the system designer determine how to achieve their reliability requirements with the tools.
>>
>> Brian
>>
>> On Feb 13, 2014, at 9:46 AM, Dave Higton <DAVE.HIGTON@nice.com> wrote:
>>
>>> Here are a few assumptions on topics 1 and 3 for everybody to check out:
>>>
>>> * The network is engineered to have all the required bandwidth.
>>>
>>> * We can only cure occasional dropped packets.
>>>
>>> * If there is a hard failure, e.g. a network switch dies, no simple retry-based mechanism is going to solve it.  For those cases you need redundancy, eliminating all single points of failure.
>>>
>>> * We want to use an existing, tried and trusted, protocol; we don't want to engineer a new one.
>>>
>>> * We don't have significant numbers of implementations of lossless recording in the field, so whatever we do is going to be a change from what we do now.
>>>
>>> * Any SRC that implements SIPREC is engineered with enough RAM to buffer the media for long enough to deal with some retries.
>>>
>>> * SIPREC should cover lossless recording in enough detail that people can implement to it, referring to other RFCs where necessary.
>>>
>>> Based on the above assumptions, I'm suggesting that TCP is a tried and trusted solution to the problem of occasional dropped packets to the SRS.  TCP is usually discounted for RTP because of the increase in latency.  Clearly that is not a consideration for recording, because recording is inherently a time delay mechanism.
>>>
>>> RFC 4571 would appear to pretty much cover what is necessary for RTP over TCP, including an update to SDP to specify TCP.
>>>
>>> Comments?  Better suggestions?
>>>
>>> Dave
>>>
>>> -----Original Message-----
>>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang (Michael)
>>> Sent: 13 February 2014 08:16
>>> To: siprec@ietf.org
>>> Subject: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
>>>
>>> Hi guys,
>>>
>>> 	Recently there are discussions about several similar issues in mailing list. The 'lossless recording', 'HA recording', 'media clipping' are key words. Gerben had mentioned ' Lossless Recording' at http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html (not 1st version for the issue but the explicit version in this WG). And Simon had mentioned 'media clipping' at http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html . Are those issues still open for us?
>>>
>>> 	I tried to collect all the issues and solutions to make them easy-to-discuss:
>>>
>>> 1. UDP Package loss in transmission
>>> 	The solution might be:
>>> 	a. FEC
>>> 	b. draft-ietf-avtext-rtp-duplication-05
>>> 	b. RTP over TCP to same SRS?
>>>
>>> 2. media clipping, esp for video clipping caused by I-frame lost
>>> 	The solution might be:
>>> 	a. FIR (RFC 5104). buffering in SRC (ready for full frame refresh), check and start from I-frame in RS
>>> 	b. a persistent RS...(already have in SIPREC)
>>>
>>> 3. SRS is not ready to receive or goes down in the mid of RS
>>> 	The solution might be:
>>> 	a. buffering in SRC(a small duration or all session), then detect and resend
>>> 	b. have two independent parallel SRS, with synchronization mechanism
>>> 	c. other ways? Switch to backup SRS (still loss during switching)?
>>>
>>> Then, let's back to current documents.
>>>
>>> 1. I think RFC6341 covers all issues in different way.
>>> 	a. Use Case 10: No loss of media recording can occur, including during failure of an SRS (issue #1&#3)
>>> 	b. REQ-005: The mechanism MUST support the ability to record a CS without loss of media of RS (for example, clipping media at the beginning of the CS) (issue #2)
>>> 	c. REQ-021: The mechanism MUST NOT prevent high-availability deployments (issue #1#2#3)
>>>
>>> 2. draft-siprec-architecture and draft-siprec-protocol documents seem not cover enough details about how to handle these issues.
>>> 	a. The architecture document might reconsider the description in Section Introduction to avoid ambiguity: The Replicated Media is required to be sent in real-time to the SRS and is *not buffered* by the SRC to allow for real-time analysis of the media by the SRS.
>>> 	b. The protocol document has section 8.1.7 for the use of FIR for generating a full I-frame...Any more details needed?
>>>
>>> Are those the quality of implementation issues, not a standardization issues? Any comments?
>>>
>>> Thanks,
>>> Michael
>>> _______________________________________________
>>> siprec mailing list
>>> siprec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>>
>>> NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.
>>>
>>> Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.
>>>
>>> Monitoring: NICE may monitor incoming and outgoing e-mails.
>>>
>>> Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
>>>
>>> _______________________________________________
>>> 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 Feb 13 11:52:01 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 2B4B31A0453 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 11:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level: 
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 seH-j56YGAg0 for <siprec@ietfa.amsl.com>; Thu, 13 Feb 2014 11:51:45 -0800 (PST)
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4D11B1A0436 for <siprec@ietf.org>; Thu, 13 Feb 2014 11:51:45 -0800 (PST)
Received: by mail-ig0-f171.google.com with SMTP id uy17so13556375igb.4 for <siprec@ietf.org>; Thu, 13 Feb 2014 11:51:44 -0800 (PST)
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=HIThxx/7pI65qPYqWb7tbACOZXrfehTqete7fXHkxwE=; b=kc2iDgIE1NGJ+E7vSbRqSuo1aQSDHIXz1nAVeHP0UbkyFoydztqezx1I/HOAjY6jrT CYwd7h0p/2dd5R7M2tsvUkT3D/0wTRVt50ydGUm5VuqhnVlkxDOSRQc1YTfLDV4TJJ+P 05OlikfKziNv+yUiflphlHQEdsJe5tZUazGLDw7mGlivwPNtjR83tr0Nr3SS5s8dKFmE tBIg8SnlH1ObH5h82Wnkku5tVM0QWThESPSC77Q2HoOyF9566PUy2J7iAUTCUHOS1QjU 54rldxtoZBocEw3LPlys8P7tGeMjul1M8uzIq+ixf8V6yUdBKRvmxXKfkmuY5GkOzhs8 qmXA==
X-Gm-Message-State: ALoCoQlufdNB89Jfh5S8p2ONuYdtGfjbxYVHCfbH7ku6Ee4ZgWTbdQmZaysr3O3nrlYlbavRxwQH
X-Received: by 10.43.170.4 with SMTP id no4mr2708596icc.15.1392321103772; Thu, 13 Feb 2014 11:51:43 -0800 (PST)
Received: from [10.33.193.26] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id rj10sm9529512igc.8.2014.02.13.11.51.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 11:51:42 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5315BEF2-D032-4935-B57E-63C9B86BBCE9"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <52FD13AD.6060209@alum.mit.edu>
Date: Thu, 13 Feb 2014 14:51:40 -0500
Message-Id: <7A16857B-74FF-412D-A74D-2284A82E902B@brianrosen.net>
References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com> <D217034D-0DD6-4548-AECF-F6A9132D7DA9@brianrosen.net> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC57@SOUEXC01.eu.nice.com> <872CCB08-4D96-4C42-AAC1-331AA8695D01@brianrosen.net> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC88@SOUEXC01.eu.nice.com> <52FD13AD.6060209@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/7JoNjMDDtc_Tgok8o6ps_IFbgCI
Cc: siprec@ietf.org
Subject: Re: [siprec] Lossless recording/HA recording/media clipping? Open issues to SIPRECers?
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, 13 Feb 2014 19:51:49 -0000

--Apple-Mail=_5315BEF2-D032-4935-B57E-63C9B86BBCE9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Agree

On Feb 13, 2014, at 1:49 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 2/13/14 12:34 PM, Dave Higton wrote:
>> Ah, my apologies.  I wasn't paying enough attention to the contents =
of the issues.  I saw video in 2 and dismissed it as "I don't know =
enough about this", whereas it's actually about clipping of any media =
stream.
>>=20
>> Perhaps I should start again...
>>=20
>> But I believe that redundancy does not address clipping at all, and =
cannot be relied upon to fix occasional loss of packets.
>=20
> Redundancy could fix the occasional loss of packets, with some effort, =
if the redundant paths are completely independent. (Synchronize the two =
recordings after the fact, with each filling holes in the other. This =
assumes that probability of dropping the same packet on both paths is =
low.)
Yes, that was what I was trying to say

>=20
> I guess addressing clipping requires local buffering, and sufficient =
bandwidth to catch up once you have a connection. Agree it doesn't have =
anything to do with redundancy, except in cases where it is quicker to =
establish a connection to one path than the other.
Yeah, but you need enough buffering for the worst path. =20

>=20
> 	Thanks,
> 	Paul
>=20
>> Dave
>>=20
>> -----Original Message-----
>> From: Brian Rosen [mailto:br@brianrosen.net]
>> Sent: 13 February 2014 17:17
>> To: Dave Higton
>> Cc: siprec@ietf.org
>> Subject: Re: [siprec] Lossless recording/HA recording/media clipping? =
Open issues to SIPRECers?
>>=20
>> Huh.  You said you were addressing points 1 and 3 (packet loss and =
SRS failure).  Clipping is point 2.
>>=20
>> Confusion.  I was addressing mostly 3, but usually if you have two =
independent copies of a stream, you could get 1 covered as long as you =
can somehow merge the streams (since the packets will have the same =
samples in them).
>>=20
>> Brian
>>=20
>>=20
>> On Feb 13, 2014, at 11:00 AM, Dave Higton <DAVE.HIGTON@nice.com> =
wrote:
>>=20
>>> We're talking about two different issues here.  I'm talking about =
preventing clipping and loss of occasional packets.  You're talking =
about redundancy and high availability.  Simply adding redundant =
recording is going to do nothing to prevent clipping and loss of =
occasional packets, AFAICS.
>>>=20
>>> Recording systems for NG911, for example, are going to have to =
address both issues.
>>>=20
>>> Dave
>>>=20
>>> -----Original Message-----
>>> From: Brian Rosen [mailto:br@brianrosen.net]
>>> Sent: 13 February 2014 15:16
>>> To: Dave Higton
>>> Cc: siprec@ietf.org
>>> Subject: Re: [siprec] Lossless recording/HA recording/media =
clipping? Open issues to SIPRECers?
>>>=20
>>> That's pretty radical.
>>>=20
>>> Are you assuming that you record at least twice (two SRSs)?  That is =
a required part of HA, no matter what.
>>>=20
>>> Then we have to determine if we need to improve the reliability of a =
single instance of an SRS.
>>>=20
>>> That's a matter of the final required reliability, and is also =
related to how many copies you are making =3D the larger the number of =
SRSs, the lower the reliability of each one of them needed to get the =
overall reliability.
>>>=20
>>> What's the goal?  4 nines?  5?
>>>=20
>>> If you are trying to achieve 4 nines, you have 2 instances, then you =
need a fairly high reliability for each one of the instances, and we may =
need something like TCP to accomplish that.
>>>=20
>>> If you have 3 instances, you might not need it.  Having said that, =
the math to determine what any real implementation needs is non trivial.
>>>=20
>>> We might look at this as a tool box, support mechanisms to both =
increase reliability of a single instance and support more than one =
instance, and let the system designer determine how to achieve their =
reliability requirements with the tools.
>>>=20
>>> Brian
>>>=20
>>> On Feb 13, 2014, at 9:46 AM, Dave Higton <DAVE.HIGTON@nice.com> =
wrote:
>>>=20
>>>> Here are a few assumptions on topics 1 and 3 for everybody to check =
out:
>>>>=20
>>>> * The network is engineered to have all the required bandwidth.
>>>>=20
>>>> * We can only cure occasional dropped packets.
>>>>=20
>>>> * If there is a hard failure, e.g. a network switch dies, no simple =
retry-based mechanism is going to solve it.  For those cases you need =
redundancy, eliminating all single points of failure.
>>>>=20
>>>> * We want to use an existing, tried and trusted, protocol; we don't =
want to engineer a new one.
>>>>=20
>>>> * We don't have significant numbers of implementations of lossless =
recording in the field, so whatever we do is going to be a change from =
what we do now.
>>>>=20
>>>> * Any SRC that implements SIPREC is engineered with enough RAM to =
buffer the media for long enough to deal with some retries.
>>>>=20
>>>> * SIPREC should cover lossless recording in enough detail that =
people can implement to it, referring to other RFCs where necessary.
>>>>=20
>>>> Based on the above assumptions, I'm suggesting that TCP is a tried =
and trusted solution to the problem of occasional dropped packets to the =
SRS.  TCP is usually discounted for RTP because of the increase in =
latency.  Clearly that is not a consideration for recording, because =
recording is inherently a time delay mechanism.
>>>>=20
>>>> RFC 4571 would appear to pretty much cover what is necessary for =
RTP over TCP, including an update to SDP to specify TCP.
>>>>=20
>>>> Comments?  Better suggestions?
>>>>=20
>>>> Dave
>>>>=20
>>>> -----Original Message-----
>>>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Yanqiang =
(Michael)
>>>> Sent: 13 February 2014 08:16
>>>> To: siprec@ietf.org
>>>> Subject: [siprec] Lossless recording/HA recording/media clipping? =
Open issues to SIPRECers?
>>>>=20
>>>> Hi guys,
>>>>=20
>>>> 	Recently there are discussions about several similar issues in =
mailing list. The 'lossless recording', 'HA recording', 'media clipping' =
are key words. Gerben had mentioned ' Lossless Recording' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html (not =
1st version for the issue but the explicit version in this WG). And =
Simon had mentioned 'media clipping' at =
http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html . Are =
those issues still open for us?
>>>>=20
>>>> 	I tried to collect all the issues and solutions to make them =
easy-to-discuss:
>>>>=20
>>>> 1. UDP Package loss in transmission
>>>> 	The solution might be:
>>>> 	a. FEC
>>>> 	b. draft-ietf-avtext-rtp-duplication-05
>>>> 	b. RTP over TCP to same SRS?
>>>>=20
>>>> 2. media clipping, esp for video clipping caused by I-frame lost
>>>> 	The solution might be:
>>>> 	a. FIR (RFC 5104). buffering in SRC (ready for full frame =
refresh), check and start from I-frame in RS
>>>> 	b. a persistent RS...(already have in SIPREC)
>>>>=20
>>>> 3. SRS is not ready to receive or goes down in the mid of RS
>>>> 	The solution might be:
>>>> 	a. buffering in SRC(a small duration or all session), then =
detect and resend
>>>> 	b. have two independent parallel SRS, with synchronization =
mechanism
>>>> 	c. other ways? Switch to backup SRS (still loss during =
switching)?
>>>>=20
>>>> Then, let's back to current documents.
>>>>=20
>>>> 1. I think RFC6341 covers all issues in different way.
>>>> 	a. Use Case 10: No loss of media recording can occur, including =
during failure of an SRS (issue #1&#3)
>>>> 	b. REQ-005: The mechanism MUST support the ability to record a =
CS without loss of media of RS (for example, clipping media at the =
beginning of the CS) (issue #2)
>>>> 	c. REQ-021: The mechanism MUST NOT prevent high-availability =
deployments (issue #1#2#3)
>>>>=20
>>>> 2. draft-siprec-architecture and draft-siprec-protocol documents =
seem not cover enough details about how to handle these issues.
>>>> 	a. The architecture document might reconsider the description in =
Section Introduction to avoid ambiguity: The Replicated Media is =
required to be sent in real-time to the SRS and is *not buffered* by the =
SRC to allow for real-time analysis of the media by the SRS.
>>>> 	b. The protocol document has section 8.1.7 for the use of FIR =
for generating a full I-frame...Any more details needed?
>>>>=20
>>>> Are those the quality of implementation issues, not a =
standardization issues? Any comments?
>>>>=20
>>>> Thanks,
>>>> Michael
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>=20
>>>>=20
>>>> NICE Systems UK Limited ("NICE") is registered in England under =
company number, 3403044. The registered office of NICE is at Tollbar =
Way, Hedge End, Southampton, Hampshire SO30 2ZP.
>>>>=20
>>>> Confidentiality: This communication and any attachments are =
intended for the above-named persons only and may be confidential and/or =
legally privileged. Any opinions expressed in this communication are not =
necessarily those of NICE. If this communication has come to you in =
error you must take no action based on it, nor must you copy or show it =
to anyone; please delete/destroy and inform the sender by e-mail =
immediately.
>>>>=20
>>>> Monitoring: NICE may monitor incoming and outgoing e-mails.
>>>>=20
>>>> Viruses: Although we have taken steps toward ensuring that this =
e-mail and attachments are free from any virus, we advise that in =
keeping with good computing practice the recipient should ensure they =
are actually virus free.
>>>>=20
>>>> _______________________________________________
>>>> 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
>>=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


--Apple-Mail=_5315BEF2-D032-4935-B57E-63C9B86BBCE9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<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-line-break: =
after-white-space;">Agree<div><br><div><div>On Feb 13, 2014, at 1:49 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"><div style=3D"font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;">On 2/13/14 12:34 PM, Dave Higton =
wrote:<br><blockquote type=3D"cite">Ah, my apologies. &nbsp;I wasn't =
paying enough attention to the contents of the issues. &nbsp;I saw video =
in 2 and dismissed it as "I don't know enough about this", whereas it's =
actually about clipping of any media stream.<br><br>Perhaps I should =
start again...<br><br>But I believe that redundancy does not address =
clipping at all, and cannot be relied upon to fix occasional loss of =
packets.<br></blockquote><br>Redundancy could fix the occasional loss of =
packets, with some effort, if the redundant paths are completely =
independent. (Synchronize the two recordings after the fact, with each =
filling holes in the other. This assumes that probability of dropping =
the same packet on both paths is low.)<br></div></blockquote>Yes, that =
was what I was trying to say</div><div><br><blockquote type=3D"cite"><div =
style=3D"font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><br>I guess addressing clipping =
requires local buffering, and sufficient bandwidth to catch up once you =
have a connection. Agree it doesn't have anything to do with redundancy, =
except in cases where it is quicker to establish a connection to one =
path than the other.<br></div></blockquote>Yeah, but you need enough =
buffering for the worst path. &nbsp;</div><div><br><blockquote =
type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><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">Dave<br><br>-----Original =
Message-----<br>From: Brian Rosen [<a =
href=3D"mailto:br@brianrosen.net">mailto:br@brianrosen.net</a>]<br>Sent: =
13 February 2014 17:17<br>To: Dave Higton<br>Cc: <a =
href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br>Subject: Re: =
[siprec] Lossless recording/HA recording/media clipping? Open issues to =
SIPRECers?<br><br>Huh. &nbsp;You said you were addressing points 1 and 3 =
(packet loss and SRS failure). &nbsp;Clipping is point =
2.<br><br>Confusion. &nbsp;I was addressing mostly 3, but usually if you =
have two independent copies of a stream, you could get 1 covered as long =
as you can somehow merge the streams (since the packets will have the =
same samples in them).<br><br>Brian<br><br><br>On Feb 13, 2014, at 11:00 =
AM, Dave Higton &lt;<a =
href=3D"mailto:DAVE.HIGTON@nice.com">DAVE.HIGTON@nice.com</a>&gt; =
wrote:<br><br><blockquote type=3D"cite">We're talking about two =
different issues here. &nbsp;I'm talking about preventing clipping and =
loss of occasional packets. &nbsp;You're talking about redundancy and =
high availability. &nbsp;Simply adding redundant recording is going to =
do nothing to prevent clipping and loss of occasional packets, =
AFAICS.<br><br>Recording systems for NG911, for example, are going to =
have to address both issues.<br><br>Dave<br><br>-----Original =
Message-----<br>From: Brian Rosen [<a =
href=3D"mailto:br@brianrosen.net">mailto:br@brianrosen.net</a>]<br>Sent: =
13 February 2014 15:16<br>To: Dave Higton<br>Cc: <a =
href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br>Subject: Re: =
[siprec] Lossless recording/HA recording/media clipping? Open issues to =
SIPRECers?<br><br>That's pretty radical.<br><br>Are you assuming that =
you record at least twice (two SRSs)? &nbsp;That is a required part of =
HA, no matter what.<br><br>Then we have to determine if we need to =
improve the reliability of a single instance of an SRS.<br><br>That's a =
matter of the final required reliability, and is also related to how =
many copies you are making =3D the larger the number of SRSs, the lower =
the reliability of each one of them needed to get the overall =
reliability.<br><br>What's the goal? &nbsp;4 nines? &nbsp;5?<br><br>If =
you are trying to achieve 4 nines, you have 2 instances, then you need a =
fairly high reliability for each one of the instances, and we may need =
something like TCP to accomplish that.<br><br>If you have 3 instances, =
you might not need it. &nbsp;Having said that, the math to determine =
what any real implementation needs is non trivial.<br><br>We might look =
at this as a tool box, support mechanisms to both increase reliability =
of a single instance and support more than one instance, and let the =
system designer determine how to achieve their reliability requirements =
with the tools.<br><br>Brian<br><br>On Feb 13, 2014, at 9:46 AM, Dave =
Higton &lt;<a =
href=3D"mailto:DAVE.HIGTON@nice.com">DAVE.HIGTON@nice.com</a>&gt; =
wrote:<br><br><blockquote type=3D"cite">Here are a few assumptions on =
topics 1 and 3 for everybody to check out:<br><br>* The network is =
engineered to have all the required bandwidth.<br><br>* We can only cure =
occasional dropped packets.<br><br>* If there is a hard failure, e.g. a =
network switch dies, no simple retry-based mechanism is going to solve =
it. &nbsp;For those cases you need redundancy, eliminating all single =
points of failure.<br><br>* We want to use an existing, tried and =
trusted, protocol; we don't want to engineer a new one.<br><br>* We =
don't have significant numbers of implementations of lossless recording =
in the field, so whatever we do is going to be a change from what we do =
now.<br><br>* Any SRC that implements SIPREC is engineered with enough =
RAM to buffer the media for long enough to deal with some =
retries.<br><br>* SIPREC should cover lossless recording in enough =
detail that people can implement to it, referring to other RFCs where =
necessary.<br><br>Based on the above assumptions, I'm suggesting that =
TCP is a tried and trusted solution to the problem of occasional dropped =
packets to the SRS. &nbsp;TCP is usually discounted for RTP because of =
the increase in latency. &nbsp;Clearly that is not a consideration for =
recording, because recording is inherently a time delay =
mechanism.<br><br>RFC 4571 would appear to pretty much cover what is =
necessary for RTP over TCP, including an update to SDP to specify =
TCP.<br><br>Comments? &nbsp;Better =
suggestions?<br><br>Dave<br><br>-----Original Message-----<br>From: =
siprec [<a =
href=3D"mailto:siprec-bounces@ietf.org">mailto:siprec-bounces@ietf.org</a>=
] On Behalf Of Yanqiang (Michael)<br>Sent: 13 February 2014 08:16<br>To: =
<a href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br>Subject: =
[siprec] Lossless recording/HA recording/media clipping? Open issues to =
SIPRECers?<br><br>Hi guys,<br><br><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>Recently there are discussions =
about several similar issues in mailing list. The 'lossless recording', =
'HA recording', 'media clipping' are key words. Gerben had mentioned ' =
Lossless Recording' at <a =
href=3D"http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html"=
>http://www.ietf.org/mail-archive/web/siprec/current/msg03893.html</a> =
(not 1st version for the issue but the explicit version in this WG). And =
Simon had mentioned 'media clipping' at <a =
href=3D"http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html"=
>http://www.ietf.org/mail-archive/web/siprec/current/msg03839.html</a> . =
Are those issues still open for us?<br><br><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>I tried to collect all the issues =
and solutions to make them easy-to-discuss:<br><br>1. UDP Package loss =
in transmission<br><span class=3D"Apple-tab-span" style=3D"white-space: =
pre;">	</span>The solution might be:<br><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>a. FEC<br><span =
class=3D"Apple-tab-span" style=3D"white-space: pre;">	</span>b. =
draft-ietf-avtext-rtp-duplication-05<br><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>b. RTP over TCP to same =
SRS?<br><br>2. media clipping, esp for video clipping caused by I-frame =
lost<br><span class=3D"Apple-tab-span" style=3D"white-space: pre;">	=
</span>The solution might be:<br><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>a. FIR (RFC 5104). buffering in =
SRC (ready for full frame refresh), check and start from I-frame in =
RS<br><span class=3D"Apple-tab-span" style=3D"white-space: pre;">	=
</span>b. a persistent RS...(already have in SIPREC)<br><br>3. SRS is =
not ready to receive or goes down in the mid of RS<br><span =
class=3D"Apple-tab-span" style=3D"white-space: pre;">	</span>The =
solution might be:<br><span class=3D"Apple-tab-span" style=3D"white-space:=
 pre;">	</span>a. buffering in SRC(a small duration or all session), =
then detect and resend<br><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>b. have two independent parallel =
SRS, with synchronization mechanism<br><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>c. other ways? Switch to backup =
SRS (still loss during switching)?<br><br>Then, let's back to current =
documents.<br><br>1. I think RFC6341 covers all issues in different =
way.<br><span class=3D"Apple-tab-span" style=3D"white-space: pre;">	=
</span>a. Use Case 10: No loss of media recording can occur, including =
during failure of an SRS (issue #1&amp;#3)<br><span =
class=3D"Apple-tab-span" style=3D"white-space: pre;">	</span>b. =
REQ-005: The mechanism MUST support the ability to record a CS without =
loss of media of RS (for example, clipping media at the beginning of the =
CS) (issue #2)<br><span class=3D"Apple-tab-span" style=3D"white-space: =
pre;">	</span>c. REQ-021: The mechanism MUST NOT prevent =
high-availability deployments (issue #1#2#3)<br><br>2. =
draft-siprec-architecture and draft-siprec-protocol documents seem not =
cover enough details about how to handle these issues.<br><span =
class=3D"Apple-tab-span" style=3D"white-space: pre;">	</span>a. The =
architecture document might reconsider the description in Section =
Introduction to avoid ambiguity: The Replicated Media is required to be =
sent in real-time to the SRS and is *not buffered* by the SRC to allow =
for real-time analysis of the media by the SRS.<br><span =
class=3D"Apple-tab-span" style=3D"white-space: pre;">	</span>b. The =
protocol document has section 8.1.7 for the use of FIR for generating a =
full I-frame...Any more details needed?<br><br>Are those the quality of =
implementation issues, not a standardization issues? Any =
comments?<br><br>Thanks,<br>Michael<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><br><br>NICE Systems UK Limited ("NICE") is =
registered in England under company number, 3403044. The registered =
office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 =
2ZP.<br><br>Confidentiality: This communication and any attachments are =
intended for the above-named persons only and may be confidential and/or =
legally privileged. Any opinions expressed in this communication are not =
necessarily those of NICE. If this communication has come to you in =
error you must take no action based on it, nor must you copy or show it =
to anyone; please delete/destroy and inform the sender by e-mail =
immediately.<br><br>Monitoring: NICE may monitor incoming and outgoing =
e-mails.<br><br>Viruses: Although we have taken steps toward ensuring =
that this e-mail and attachments are free from any virus, we advise that =
in keeping with good computing practice the recipient should ensure they =
are actually virus =
free.<br><br>_______________________________________________<br>siprec =
mailing =
list<br>siprec@ietf.org<br>https://www.ietf.org/mailman/listinfo/siprec<br=
></blockquote><br>_______________________________________________<br>sipre=
c 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>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><br></blockquote><br>________________________=
_______________________<br>siprec mailing list<br><a =
href=3D"mailto:siprec@ietf.org">siprec@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/siprec">https://www.ietf.org=
/mailman/listinfo/siprec</a></div></blockquote></div><br></div></body></ht=
ml>=

--Apple-Mail=_5315BEF2-D032-4935-B57E-63C9B86BBCE9--


From nobody Fri Feb 14 10:19:38 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 7A03F1A0369 for <siprec@ietfa.amsl.com>; Fri, 14 Feb 2014 10:19:35 -0800 (PST)
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 hglcLSA_Mp8f for <siprec@ietfa.amsl.com>; Fri, 14 Feb 2014 10:19:33 -0800 (PST)
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 541C01A02CF for <siprec@ietf.org>; Fri, 14 Feb 2014 10:19:33 -0800 (PST)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta02.westchester.pa.mail.comcast.net with comcast id SJ6C1n00116LCl051JKXy0; Fri, 14 Feb 2014 18:19:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id SJKX1n00Q3ZTu2S3SJKXkl; Fri, 14 Feb 2014 18:19:31 +0000
Message-ID: <52FE5E33.4010008@alum.mit.edu>
Date: Fri, 14 Feb 2014 13:19:31 -0500
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.3.0
MIME-Version: 1.0
To: "siprec@ietf.org" <siprec@ietf.org>
References: <20140214181350.11621.986.idtracker@ietfa.amsl.com>
In-Reply-To: <20140214181350.11621.986.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140214181350.11621.986.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392401971; bh=f5r0ZAChbdctHI4EkpaVeb+722o6tqAS0vSjVR1qxx0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UrTIgmrx0rPP/htspKYJKI46N541oJOJYN1E+07GUKSaDhb2xvc17CjdAN7ZHkti7 1sVu1sQPT8UO2ZS/2oDA/uBc4yib9XhjmM5R18BY5Nzm+0Fp+f0qfj+IG/9oW25k52 xfFY5LpP74lbPXNJd/tAUDu9rbK2VbfnDL8JC7HCp0zvmoyruD3TXrL7Jt99ECnt/A /YwXvsLHYtI+C7xJcVANSH4wsiDdVrOZKIVPh9M1JPcNAi2WmGZS11OvW4xgcqykq4 mLGyfxDimAFy+aUvn1+JeFFd5N0ojN3mfIN8kKwXmv3EWNwNyVHkXYvydRAs6xviBm d9luigaSVyg3g==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/D9BkH3c5fsmHZc2cc8XdZ6d2SgQ
Subject: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-00.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: Fri, 14 Feb 2014 18:19:35 -0000

My associate Michael Yan and I just posted a new draft regarding 
recording of MSRP. This is very rough - just enough to provide a 
starting point for discussions.

We will be working more on it, but welcome comments and opinions on 
direction and technical choices.

	Thanks,
	Paul


-------- Original Message --------
Subject: New Version Notification for draft-yan-siprec-msrp-recording-00.txt
Date: Fri, 14 Feb 2014 10:13:50 -0800
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-00.txt
has been successfully submitted by Paul H. Kyzivat and posted to the
IETF repository.

Name:		draft-yan-siprec-msrp-recording
Revision:	00
Title:		Overview for MSRP Recording based on SIPREC
Document date:	2014-02-14
Group:		Individual Submission
Pages:		7
URL: 
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
Htmlized: 
http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-00


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





From nobody Fri Feb 14 14:28:16 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 17D951A00BB; Fri, 14 Feb 2014 14:28:05 -0800 (PST)
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 xnI6is06MGEE; Fri, 14 Feb 2014 14:28:00 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D75EE1A0233; Fri, 14 Feb 2014 14:27:51 -0800 (PST)
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.0.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140214222751.19319.38020.idtracker@ietfa.amsl.com>
Date: Fri, 14 Feb 2014 14:27:51 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/yrBaHVHOg1GR4JK2WJQiYhShqmk
Cc: siprec@ietf.org
Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-12.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: Fri, 14 Feb 2014 22:28:05 -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-12.txt
	Pages           : 43
	Date            : 2014-02-14

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-12

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


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 Fri Feb 14 14:34:55 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 E734D1A01D4 for <siprec@ietfa.amsl.com>; Fri, 14 Feb 2014 14:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Level: 
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 ODMmF9nliG4s for <siprec@ietfa.amsl.com>; Fri, 14 Feb 2014 14:34:50 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 25B821A0168 for <siprec@ietf.org>; Fri, 14 Feb 2014 14:34:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2398; q=dns/txt; s=iport; t=1392417286; x=1393626886; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gwO3VsAQnDxr9vUBGErQVfwRJczLcMalvKG0OFiKRSU=; b=cP/xCp6R6wkYP9ulFGh9juBKTST+IgE04PmG0ulKm/HaZK4txaJBJwBf lbDAvqUjLtEZmzMSaA59w0HB1Noe/9DZkFNKbXE3Tq5XZNu/8uKxhEhPL OIf7BT4ouG01YDAyfsOctjjAZUxVp6cypo5rxUZ0ybTLO09IzU9WbTJnM s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFADGZ/lKtJV2b/2dsb2JhbABZgwY4UQa+Y0+BGBZ0giYBAQQBAQE3NBsCAQg2ECcLJQIEEwmHewEIBcheF44oAQFRBYQ4BJgsgTKQcYMtgXE5
X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208";a="20607260"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 14 Feb 2014 22:34:46 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1EMYkcP028965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <siprec@ietf.org>; Fri, 14 Feb 2014 22:34:46 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.47]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 16:34:45 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-12.txt
Thread-Index: AQHPKdQYgU/jKVfo0E+K4BQVWXtFX5q1NLsA
Date: Fri, 14 Feb 2014 22:34:45 +0000
Message-ID: <CF23D8D0.1F03A%eckelcu@cisco.com>
References: <20140214222751.19319.38020.idtracker@ietfa.amsl.com>
In-Reply-To: <20140214222751.19319.38020.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: [171.68.20.23]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7C0F3128A378094BB9F83B5150F1F49B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/zor0YlIDAQIEH_BSa1ewPZpHoEw
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-12.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: Fri, 14 Feb 2014 22:34:53 -0000

This update to the protocol draft incorporate the changes captured in the
following two threads:

IETF 88 comments:
http://www.ietf.org/mail-archive/web/siprec/current/msg03829.html

Metadata sending frequency:
http://www.ietf.org/mail-archive/web/siprec/current/msg03910.html

There are a couple other threads that have not yet reached a conclusion
that I felt comfortable capturing in the draft.

Please review and share your comments.

Cheers,
Charles

On 2/14/14 2:27 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-12.txt
>	Pages           : 43
>	Date            : 2014-02-14
>
>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-12
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-12
>
>
>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 Fri Feb 14 22:59:45 2014
Return-Path: <michael.yan@huawei.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 25F351A007F for <siprec@ietfa.amsl.com>; Fri, 14 Feb 2014 22:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level: 
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 nGDqUR4_yvyE for <siprec@ietfa.amsl.com>; Fri, 14 Feb 2014 22:59:41 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D7B371A0069 for <siprec@ietf.org>; Fri, 14 Feb 2014 22:59:40 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD72065; Sat, 15 Feb 2014 06:59:37 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 06:59:30 +0000
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 06:59:35 +0000
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.12]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 14:59:31 +0800
From: "Yanqiang (Michael)" <michael.yan@huawei.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: New Version Notification for draft-kyzivat-siprec-conference-use-cases-01.txt
Thread-Index: AQHPKBw6w7al0FbVGkG0NHPMyPI0P5q14QVQ
Date: Sat, 15 Feb 2014 06:59:30 +0000
Message-ID: <21794EB0EE82B0458A524942A141542B31DAA7CB@szxema508-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.173.14.125]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/-PHsVfL-xJRq1E8U7Q_wnY6RZIU
Subject: [siprec] FW: New Version Notification for draft-kyzivat-siprec-conference-use-cases-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: Sat, 15 Feb 2014 06:59:44 -0000

SGksDQoNClRoaXMgcmV2aXNpb24gaGFzIGZvbGxvd2luZyBjaGFuZ2VzOg0KDQoxLiBSZXZpc2Ug
c29tZSBzZWN0aW9ucyBhY2NvcmRpbmcgdG8gQW5keSdzIFNJUFJFQyBDaGFydGVyIFVwZGF0ZSBQ
cm9wb3NhbC4gDQoJTW9yZSBkZXRhaWxzIHBsZWFzZSBjaGVjayB0aGUgbWFpbCB0aHJlYWQ6IGh0
dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXByZWMvY3VycmVudC9tc2cwMzg3
MC5odG1sIA0KDQoyLiBUaGUgZ3JhbW1hciBhbmQgdXNhZ2UgcmVsYXRlZCBjaGFuZ2VzLg0KDQpQ
bGVhc2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLg0KDQpUaGFua3MsDQpNaWNoYWVs
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRz
QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUaHVy
c2RheSwgRmVicnVhcnkgMTMsIDIwMTQgMjowMCBBTQ0KPiBUbzogWWFucWlhbmcgKE1pY2hhZWwp
OyBTaW1vbiBQaWV0cm8gUm9tYW5vOyBQYXVsIEguIEt5eml2YXQ7IFBhdWwgS3l6aXZhdDsNCj4g
WWFucWlhbmcgKE1pY2hhZWwpOyBTaW1vbiBSb21hbm8NCj4gU3ViamVjdDogTmV3IFZlcnNpb24g
Tm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1reXppdmF0LXNpcHJlYy1jb25mZXJlbmNlLXVzZS1j
YXNlcy0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3l6aXZh
dC1zaXByZWMtY29uZmVyZW5jZS11c2UtY2FzZXMtMDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3Nm
dWxseSBzdWJtaXR0ZWQgYnkgTWljaGFlbCBZYW4gYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiBy
ZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWt5eml2YXQtc2lwcmVjLWNvbmZlcmVuY2Ut
dXNlLWNhc2VzDQo+IFJldmlzaW9uOgkwMQ0KPiBUaXRsZToJCU11bHRpbWVkaWEgQ29uZmVyZW5j
ZSBSZWNvcmRpbmcgVXNlIENhc2VzIGFuZCBSZXF1aXJlbWVudHMNCj4gRG9jdW1lbnQgZGF0ZToJ
MjAxNC0wMi0xMg0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczoJCTEw
DQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta3l6
aXZhdC1zaXByZWMtY29uZmVyZW5jZS11c2UtY2FzZXMtDQo+IDAxLnR4dA0KPiBTdGF0dXM6DQo+
IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt5eml2YXQtc2lwcmVjLWNv
bmZlcmVuY2UtdXNlLWNhc2VzLw0KPiBIdG1saXplZDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQta3l6aXZhdC1zaXByZWMtY29uZmVyZW5jZS11c2UtY2FzZXMtMDENCj4gRGlm
ZjoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQta3l6aXZhdC1zaXBy
ZWMtY29uZmVyZW5jZS11c2UtY2FzZXMtMDENCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGUgY3Vy
cmVudCB3b3JrIG9mIFNJUFJFQyB3aWxsIHNvb24gZmluaXNoLiAgQXMgY29uZmVyZW5jZXMgYXJl
IHRoZQ0KPiAgICBrZXkgcmVxdWlyZW1lbnQgZm9yIHNvbWUgZW52aXJvbm1lbnRzLCBpdCBpcyB3
b3J0aCB0byBleHBsb3JlIHNldmVyYWwNCj4gICAgZXh0ZW5zaW9ucyBhbmQgYWRkaXRpb25hbCBm
dW5jdGlvbmFsaXR5IHRvIHN1cHBvcnQgbXVsdGltZWRpYQ0KPiAgICBjb25mZXJlbmNlIHJlY29y
ZGluZy4gIFNJUFJFQyBpcyBub3Qgc3VmZmljaWVudCB0byByZWNvcmQgYWxsIHRoZQ0KPiAgICBj
b25mZXJlbmNlIHNlc3Npb25zIHZpYSBjZXJ0YWluIGludGVyYWN0aXZlIG1lZGlhIGNoYW5uZWxz
LCBsaWtlDQo+ICAgIG11bHRpLXVzZXIgY2hhdCBvciBzY3JlZW4gc2hhcmluZy4NCj4gDQo+ICAg
IFRoaXMgZHJhZnQgdHJpZXMgdG8gc2hvdyB0aGUgdXNlIGNhc2VzIGZvciBtdWx0aW1lZGlhIGNv
bmZlcmVuY2UNCj4gICAgcmVjb3JkaW5nIGFuZCB0aGUgcmVxdWlyZW1lbnRzIGZvciBob3cgdG8g
d29yayB3ZWxsIHVuZGVyIFNJUFJFQw0KPiAgICBtZWNoYW5pc20uICBUaGUgcmVxdWlyZW1lbnRz
IGFzayBmb3IgZXh0ZW5zaW9ucyB0byBTSVAgdGhhdCB3aWxsDQo+ICAgIG1hbmFnZSBkZWxpdmVy
eSBvZiBSVFAgbWVkaWEgc2Vzc2lvbnMsIGluY2x1ZGluZyBjb250ZW50IG1lZGlhDQo+ICAgIGRl
ZmluZWQgYnkgW1JGQzQ3OTZdICwgYW5kIE1TUlAgbWVkaWEgc2Vzc2lvbnMgdG8gYSByZWNvcmRp
bmcgZGV2aWNlLg0KPiAgICBUaGUgcmVjb3JkZWQgbWVkaWEgc2Vzc2lvbnMgYXJlIGFsbCBTSVAt
YmFzZWQuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr
ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRp
bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll
dGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K


From nobody Wed Feb 19 02:46:52 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 EFBB81A057D for <siprec@ietfa.amsl.com>; Wed, 19 Feb 2014 02:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 eN1wbJd5-Jpy for <siprec@ietfa.amsl.com>; Wed, 19 Feb 2014 02:46:49 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC091A046F for <siprec@ietf.org>; Wed, 19 Feb 2014 02:46:49 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 9079B1EB84DC; Wed, 19 Feb 2014 11:46:45 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.208]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Wed, 19 Feb 2014 11:46:45 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] SIPREC IETF89 Meeting in London.
Thread-Index: Ac8g7nFoAcJQS01VTjWB+CwWU8Xf3QGPYGkQAARwyAABiGkhQA==
Date: Wed, 19 Feb 2014 10:46:44 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D0F38E@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF17CE2D41@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF17CF0040@MCHP04MSX.global-ad.net> <52FA4F56.5060508@alum.mit.edu>
In-Reply-To: <52FA4F56.5060508@alum.mit.edu>
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/AK9EZffHXc21xacl5O14r2-fvTQ
Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
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, 19 Feb 2014 10:46:52 -0000

Hi Paul,

Sorry I have been mostly offline for the last few days so did not see this.

I think given the amount of work people have to do before the IETF meeting =
it is now too late to call WGLC on this.

So probably we have to use a small amount of meeting time to encourage comm=
ents and make WGLC after the meeting.

I hope that is ok.

Andy



> -----Original Message-----
> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 11 February 2014 16:27
> To: siprec@ietf.org
> Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
>=20
> Andy,
>=20
> Ram just posted a new version of the metadata, and an email that
> explains the changes.
>=20
> I don't know if you want to use meeting time on it or not.
> We think the doc is ready for WGLC. If you agree, that could start now
> and end before London, and we could discuss the results. Or it could
> begin now and end after London, and we could discuss comments received
> at the meeting, or we could wait until the meeting to start WGLC and
> use
> the meeting to encourage people to comment.
>=20
> At your pleasure!
>=20
> 	Thanks,
> 	Paul
>=20
> On 2/11/14 8:57 AM, Hutton, Andrew wrote:
> > Any more requests for agenda time during the SIPREC meeting.
> >
> > So far the only requests we have are from Paul Kyzivat and Gerben
> Stam
> > relating to future work.
> >
> > Regards
> >
> > Andy
> >
> > *From:*siprec [mailto:siprec-bounces@ietf.org] *On Behalf Of *Hutton,
> Andrew
> > *Sent:* 03 February 2014 14:45
> > *To:* siprec@ietf.org
> > *Subject:* [siprec] SIPREC IETF89 Meeting in London.
> >
> > Hi All,
> >
> > If you would like agenda time in the SIPREC meeting at IETF89 please
> > e-mail the chairs (siprec-chairs@tools.ietf.org
> > <mailto:siprec-chairs@tools.ietf.org>) .
> >
> > SIPREC has been allocated the dreaded final meeting slot in the
> *DRAFT*
> > agenda on Friday March the 7^th (See
> > https://datatracker.ietf.org/meeting/89/agenda.html).
> >
> > Of course the draft agenda can change so don't make plans based on
> this.
> >
> > *Regards*
> >
> > *Andy (SIPREC Co-Chair).*
> >
> >
> >
> > _______________________________________________
> > 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 Wed Feb 19 03:19:58 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 BDE531A0466 for <siprec@ietfa.amsl.com>; Wed, 19 Feb 2014 03:19:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 i_9iXqXXprel for <siprec@ietfa.amsl.com>; Wed, 19 Feb 2014 03:19:55 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id DF9D71A043A for <siprec@ietf.org>; Wed, 19 Feb 2014 03:19:54 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 00D7A1EB84F7; Wed, 19 Feb 2014 12:19:51 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.208]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Wed, 19 Feb 2014 12:19:50 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "'Charles Eckel (eckelcu)'" <eckelcu@cisco.com>, "Gerben.Stam@nice.com" <Gerben.Stam@nice.com>, "Brian Rosen" <br@brianrosen.net>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: SIPREC Draft Agenda for IETF89
Thread-Index: Ac8tZIC+6xRgbuqcTim20WUSGhS9Kg==
Date: Wed, 19 Feb 2014 11:19:49 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D0F407@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_9F33F40F6F2CD847824537F3C4E37DDF17D0F407MCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/Y1lBUUspgk5aecVVJlj9h-SZ19U
Subject: [siprec] SIPREC Draft Agenda for IETF89
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, 19 Feb 2014 11:19:57 -0000

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

Hi All,

A draft SIPREC agenda has been uploaded please check this and let me know i=
f want something changing.

The deadline for finalizing the agenda is Monday February 24th.

https://datatracker.ietf.org/meeting/89/agenda/siprec/

Regards
Andy


--_000_9F33F40F6F2CD847824537F3C4E37DDF17D0F407MCHP04MSXglobal_
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>A draft SIPREC agenda has been uploaded please check this and let me k=
now if want something changing.</div>
<div>&nbsp;</div>
<div>The deadline for finalizing the agenda is Monday February 24<font size=
=3D"1"><span style=3D"font-size:7.3pt;"><sup>th</sup></span></font>.</div>
<div>&nbsp;</div>
<div><a href=3D"https://datatracker.ietf.org/meeting/89/agenda/siprec/"><fo=
nt color=3D"blue"><u>https://datatracker.ietf.org/meeting/89/agenda/siprec/=
</u></font></a></div>
<div>&nbsp;</div>
<div>Regards</div>
<div>Andy</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_9F33F40F6F2CD847824537F3C4E37DDF17D0F407MCHP04MSXglobal_--


From nobody Wed Feb 19 03:37:45 2014
Return-Path: <rmohanr@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 38CB31A058E for <siprec@ietfa.amsl.com>; Wed, 19 Feb 2014 03:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, 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 LrT3GwAtsEz4 for <siprec@ietfa.amsl.com>; Wed, 19 Feb 2014 03:37:41 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id E72F11A047E for <siprec@ietf.org>; Wed, 19 Feb 2014 03:37:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4412; q=dns/txt; s=iport; t=1392809858; x=1394019458; h=from:to:subject:date:message-id:mime-version; bh=c24iTH7w2O25tuQf79lelXHtgp9A/z0FuVqgaoQt4O4=; b=YDwj96fpn5L0w2S6GLWrmOcQjRCOmAEbZWprDLjj71Zv1E2ycIF5Cxx/ KnMLbA12E64VRiEJpbvjf7aPuBOgpqmIZsuq06cwtaFZ6Gk1xcV8+La3V 0M194JmkH/Xsn4tckaV+8H+IDLnC7is+QNm0SSrrwxF9P7xZGWERIa+kk w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArEHAD6WBFOtJV2c/2dsb2JhbABZDoI0RDhXhCCyf4hWgRwWdIIlAQIELV4BCAQNAwECKDkUCQoEARKIBQ3NQxeOQBMNhEMEmDCBMpBygm4/gio
X-IronPort-AV: E=Sophos; i="4.97,505,1389744000"; d="scan'208,217"; a="21537077"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 19 Feb 2014 11:37:37 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1JBbbDk015076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 11:37:37 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.108]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 05:37:37 -0600
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, "Gerben.Stam@nice.com" <Gerben.Stam@nice.com>, Brian Rosen <br@brianrosen.net>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] SIPREC Draft Agenda for IETF89
Thread-Index: AQHPLWb800Pi3rM8nE++VFIW8OUenQ==
Date: Wed, 19 Feb 2014 11:37:37 +0000
Message-ID: <CF2A9507.7BF57%rmohanr@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: [72.163.212.145]
Content-Type: multipart/alternative; boundary="_000_CF2A95077BF57rmohanrciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/8vYrAzTSbgJ_1M2BKdDvUMe6orU
Subject: Re: [siprec] SIPREC Draft Agenda for IETF89
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, 19 Feb 2014 11:37:44 -0000

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

The agenda looks good to me.

A minor nits
The latest metadata draft is - http://tools.ietf.org/html/draft-ietf-siprec=
-metadata-15
I see the agenda mentions it as  ver 14. You may want to correct it.

Thanks,
Ram
From: <Hutton>, Andrew <andrew.hutton@unify.com<mailto:andrew.hutton@unify.=
com>>
Date: Wednesday, 19 February 2014 4:49 pm
To: Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>>, "Ch=
arles Eckel (eckelcu)" <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>, "Gerb=
en.Stam@nice.com<mailto:Gerben.Stam@nice.com>" <Gerben.Stam@nice.com<mailto=
:Gerben.Stam@nice.com>>, Brian Rosen <br@brianrosen.net<mailto:br@brianrose=
n.net>>, "siprec@ietf.org<mailto:siprec@ietf.org>" <siprec@ietf.org<mailto:=
siprec@ietf.org>>
Subject: [siprec] SIPREC Draft Agenda for IETF89

Hi All,

A draft SIPREC agenda has been uploaded please check this and let me know i=
f want something changing.

The deadline for finalizing the agenda is Monday February 24th.

https://datatracker.ietf.org/meeting/89/agenda/siprec/

Regards
Andy


--_000_CF2A95077BF57rmohanrciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <C284F4D7258B444BBC0F3117DB1D6CB8@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>The agenda looks good to me.&nbsp;</div>
<div><br>
</div>
<div>A minor nits</div>
<div>The latest metadata draft is -&nbsp;<a href=3D"http://tools.ietf.org/h=
tml/draft-ietf-siprec-metadata-15">http://tools.ietf.org/html/draft-ietf-si=
prec-metadata-15</a></div>
<div>I see the agenda mentions it as &nbsp;ver 14. You may want to correct =
it.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Ram</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, 19 February 2014 4=
:49 pm<br>
<span style=3D"font-weight:bold">To: </span>Paul Kyzivat &lt;<a href=3D"mai=
lto:pkyzivat@alum.mit.edu">pkyzivat@alum.mit.edu</a>&gt;, &quot;Charles Eck=
el (eckelcu)&quot; &lt;<a href=3D"mailto:eckelcu@cisco.com">eckelcu@cisco.c=
om</a>&gt;, &quot;<a href=3D"mailto:Gerben.Stam@nice.com">Gerben.Stam@nice.=
com</a>&quot;
 &lt;<a href=3D"mailto:Gerben.Stam@nice.com">Gerben.Stam@nice.com</a>&gt;, =
Brian Rosen &lt;<a href=3D"mailto:br@brianrosen.net">br@brianrosen.net</a>&=
gt;, &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 Draft Agen=
da for IETF89<br>
</div>
<div><br>
</div>
<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>A draft SIPREC agenda has been uploaded please check this and let me k=
now if want something changing.</div>
<div>&nbsp;</div>
<div>The deadline for finalizing the agenda is Monday February 24<font size=
=3D"1"><span style=3D"font-size:7.3pt;"><sup>th</sup></span></font>.</div>
<div>&nbsp;</div>
<div><a href=3D"https://datatracker.ietf.org/meeting/89/agenda/siprec/"><fo=
nt color=3D"blue"><u>https://datatracker.ietf.org/meeting/89/agenda/siprec/=
</u></font></a></div>
<div>&nbsp;</div>
<div>Regards</div>
<div>Andy</div>
<div>&nbsp;</div>
</span></font></div>
</div>
</span>
</body>
</html>

--_000_CF2A95077BF57rmohanrciscocom_--


From nobody Wed Feb 19 07:48:50 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 EA6871A01D5 for <siprec@ietfa.amsl.com>; Wed, 19 Feb 2014 07:48:45 -0800 (PST)
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 nvNux0PQW99M for <siprec@ietfa.amsl.com>; Wed, 19 Feb 2014 07:48:44 -0800 (PST)
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 C84B11A04B4 for <siprec@ietf.org>; Wed, 19 Feb 2014 07:48:22 -0800 (PST)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta07.westchester.pa.mail.comcast.net with comcast id UByV1n00217dt5G57FoKGY; Wed, 19 Feb 2014 15:48:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id UFoK1n0023ZTu2S3ZFoK92; Wed, 19 Feb 2014 15:48:19 +0000
Message-ID: <5304D243.5020605@alum.mit.edu>
Date: Wed, 19 Feb 2014 10:48:19 -0500
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.3.0
MIME-Version: 1.0
To: "Hutton, Andrew" <andrew.hutton@unify.com>,  "siprec@ietf.org" <siprec@ietf.org>
References: <9F33F40F6F2CD847824537F3C4E37DDF17CE2D41@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF17CF0040@MCHP04MSX.global-ad.net> <52FA4F56.5060508@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17D0F38E@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17D0F38E@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=q20121106; t=1392824899; bh=3rC4yg443SmQ4nVgyJNkKA+4oUyeP+HsOa5ySEaV8KQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TXqvy1UXxEFFGW2cW5F8G86js65GIqNRTpEvPHtfLAo8dFXH4jPBGIi4tyXIlGUfY ZZlELA3dCZ8k4/tG1TqoFBw4DG+zcE2xrooA9Fa19d+Voj19lL0xGajcEUNdpcGqu/ qNrjHvaaEFGdkqX6TCW6Ct5dPd71M+rZyIyM2YKdu/7Q3h2I1ihKtzqxgmi2IA48+7 YuoVEFMNBepglfwy3znqGS5eJ/DkZXJAdFeItuPfORHpI7Rn0CT4D4I+92477qV9z2 sIxmDmCQNfLOE594np03j8QSIeYzg9zOJHJieGmcKG0ls2p/9ohm0tB7DlIBxj/dvI NT0vY//QVxNdA==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/5XuX9bLfoz_AcTLok0ysLRCsKFA
Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
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, 19 Feb 2014 15:48:46 -0000

On 2/19/14 5:46 AM, Hutton, Andrew wrote:
> Hi Paul,
>
> Sorry I have been mostly offline for the last few days so did not see this.
>
> I think given the amount of work people have to do before the IETF meeting it is now too late to call WGLC on this.
>
> So probably we have to use a small amount of meeting time to encourage comments and make WGLC after the meeting.
>
> I hope that is ok.

Sure. Rather than make a separate presentation for that, maybe you can 
just handle it as part of the chair slides?

	Thanks,
	Paul

> Andy
>
>
>
>> -----Original Message-----
>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: 11 February 2014 16:27
>> To: siprec@ietf.org
>> Subject: Re: [siprec] SIPREC IETF89 Meeting in London.
>>
>> Andy,
>>
>> Ram just posted a new version of the metadata, and an email that
>> explains the changes.
>>
>> I don't know if you want to use meeting time on it or not.
>> We think the doc is ready for WGLC. If you agree, that could start now
>> and end before London, and we could discuss the results. Or it could
>> begin now and end after London, and we could discuss comments received
>> at the meeting, or we could wait until the meeting to start WGLC and
>> use
>> the meeting to encourage people to comment.
>>
>> At your pleasure!
>>
>> 	Thanks,
>> 	Paul
>>
>> On 2/11/14 8:57 AM, Hutton, Andrew wrote:
>>> Any more requests for agenda time during the SIPREC meeting.
>>>
>>> So far the only requests we have are from Paul Kyzivat and Gerben
>> Stam
>>> relating to future work.
>>>
>>> Regards
>>>
>>> Andy
>>>
>>> *From:*siprec [mailto:siprec-bounces@ietf.org] *On Behalf Of *Hutton,
>> Andrew
>>> *Sent:* 03 February 2014 14:45
>>> *To:* siprec@ietf.org
>>> *Subject:* [siprec] SIPREC IETF89 Meeting in London.
>>>
>>> Hi All,
>>>
>>> If you would like agenda time in the SIPREC meeting at IETF89 please
>>> e-mail the chairs (siprec-chairs@tools.ietf.org
>>> <mailto:siprec-chairs@tools.ietf.org>) .
>>>
>>> SIPREC has been allocated the dreaded final meeting slot in the
>> *DRAFT*
>>> agenda on Friday March the 7^th (See
>>> https://datatracker.ietf.org/meeting/89/agenda.html).
>>>
>>> Of course the draft agenda can change so don't make plans based on
>> this.
>>>
>>> *Regards*
>>>
>>> *Andy (SIPREC Co-Chair).*
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Feb 20 03:49:57 2014
Return-Path: <Gerben.Stam@nice.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 AA2B61A00B6 for <siprec@ietfa.amsl.com>; Thu, 20 Feb 2014 03:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 VyV1Y4S_Qq87 for <siprec@ietfa.amsl.com>; Thu, 20 Feb 2014 03:49:53 -0800 (PST)
Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0151A00B9 for <siprec@ietf.org>; Thu, 20 Feb 2014 03:49:52 -0800 (PST)
Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Feb 2014 11:49:03 +0000
Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Thu, 20 Feb 2014 11:49:00 +0000
From: Gerben Stam <Gerben.Stam@nice.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "'Charles Eckel (eckelcu)'" <eckelcu@cisco.com>, Brian Rosen <br@brianrosen.net>, "siprec@ietf.org" <siprec@ietf.org>
Date: Thu, 20 Feb 2014 11:48:58 +0000
Thread-Topic: [siprec] SIPREC Draft Agenda for IETF89
Thread-Index: Ac8trVtj74HvSBZvQuuaFQFTEaCgWQAguIJw
Message-ID: <4BEAD79F6904AC4FB1917EBA8006628905C087DED4@SOUEXC01.eu.nice.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17D0F407@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17D0F407@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_4BEAD79F6904AC4FB1917EBA8006628905C087DED4SOUEXC01eunic_"
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Feb 2014 11:49:03.0593 (UTC) FILETIME=[C08F5D90:01CF2E31]
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/aTKfA_BV-qCKb7n8yVikwyAdsuM
Subject: Re: [siprec] SIPREC Draft Agenda for IETF89
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, 20 Feb 2014 11:49:55 -0000

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

Hey Andrew,

I have registered to the event and am making my travel arrangements.
Will not be there all week but Wednesday till Friday.

Am good for a 15min on lossless session in SIPREC for Friday.
Do you expect a proposal document on Lossless approach/advice?

Regards,

Gerben


From: Hutton, Andrew [mailto:andrew.hutton@unify.com]
Sent: woensdag 19 februari 2014 12:20
To: Paul Kyzivat; 'Charles Eckel (eckelcu)'; Gerben Stam; Brian Rosen; sipr=
ec@ietf.org
Subject: [siprec] SIPREC Draft Agenda for IETF89

Hi All,

A draft SIPREC agenda has been uploaded please check this and let me know i=
f want something changing.

The deadline for finalizing the agenda is Monday February 24th.

https://datatracker.ietf.org/meeting/89/agenda/siprec/

Regards
Andy


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hey Andre=
w,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0p=
t;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span=
></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cali=
bri","sans-serif";color:#1F497D'>I have registered to the event and am maki=
ng my travel arrangements.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
>Will not be there all week but Wednesday till Friday.<o:p></o:p></span></p=
><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri"=
,"sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNorm=
al><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color=
:#1F497D'>Am good for a 15min on lossless session in SIPREC for Friday.<o:p=
></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font=
-family:"Calibri","sans-serif";color:#1F497D'>Do you expect a proposal docu=
ment on Lossless approach/advice?<o:p></o:p></span></p><p class=3DMsoNormal=
><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#=
1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'fon=
t-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:=
p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;fon=
t-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p>=
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";color:#1F497D'>Gerben<o:p></o:p></span></p><p class=3DMsoNorma=
l><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:=
#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'fo=
nt-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp=
;</o:p></span></p><div><div style=3D'border:none;border-top:solid #B5C4DF 1=
.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span style=3D'font=
-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=
=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Hutton, Andrew [ma=
ilto:andrew.hutton@unify.com] <br><b>Sent:</b> woensdag 19 februari 2014 12=
:20<br><b>To:</b> Paul Kyzivat; 'Charles Eckel (eckelcu)'; Gerben Stam; Bri=
an Rosen; siprec@ietf.org<br><b>Subject:</b> [siprec] SIPREC Draft Agenda f=
or IETF89<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nbsp;=
</o:p></p><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fa=
mily:"Calibri","sans-serif"'>Hi All,<o:p></o:p></span></p></div><div><p cla=
ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-=
serif"'>&nbsp;<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span s=
tyle=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>A draft SIPREC=
 agenda has been uploaded please check this and let me know if want somethi=
ng changing.<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span sty=
le=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p=
></span></p></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt=
;font-family:"Calibri","sans-serif"'>The deadline for finalizing the agenda=
 is Monday February 24</span><sup><span style=3D'font-size:7.5pt;font-famil=
y:"Calibri","sans-serif"'>th</span></sup><span style=3D'font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif"'>.<o:p></o:p></span></p></div><div><p clas=
s=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-s=
erif"'>&nbsp;<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span st=
yle=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><a href=3D"http=
s://datatracker.ietf.org/meeting/89/agenda/siprec/">https://datatracker.iet=
f.org/meeting/89/agenda/siprec/</a><o:p></o:p></span></p></div><div><p clas=
s=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-s=
erif"'>&nbsp;<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span st=
yle=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Regards<o:p></o=
:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0=
pt;font-family:"Calibri","sans-serif"'>Andy<o:p></o:p></span></p></div><div=
><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri"=
,"sans-serif"'>&nbsp;<o:p></o:p></span></p></div></div></body></html>=

--_000_4BEAD79F6904AC4FB1917EBA8006628905C087DED4SOUEXC01eunic_--


From nobody Thu Feb 20 07:12:48 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 8E7121A0183 for <siprec@ietfa.amsl.com>; Thu, 20 Feb 2014 07:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 XjnIhyuZsB0x for <siprec@ietfa.amsl.com>; Thu, 20 Feb 2014 07:12:44 -0800 (PST)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 894BC1A0170 for <siprec@ietf.org>; Thu, 20 Feb 2014 07:12:43 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 46C2123F0543; Thu, 20 Feb 2014 16:12:39 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.208]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Thu, 20 Feb 2014 16:12:39 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Gerben Stam <Gerben.Stam@nice.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>,  "'Charles Eckel (eckelcu)'" <eckelcu@cisco.com>, Brian Rosen <br@brianrosen.net>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] SIPREC Draft Agenda for IETF89
Thread-Index: Ac8tZIC+6xRgbuqcTim20WUSGhS9KgAxNq0AAAePYEA=
Date: Thu, 20 Feb 2014 15:12:38 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D11A62@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF17D0F407@MCHP04MSX.global-ad.net> <4BEAD79F6904AC4FB1917EBA8006628905C087DED4@SOUEXC01.eu.nice.com>
In-Reply-To: <4BEAD79F6904AC4FB1917EBA8006628905C087DED4@SOUEXC01.eu.nice.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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17D11A62MCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/Ka5UsvFzjbMODfkYs6t4Pxydt5E
Subject: Re: [siprec] SIPREC Draft Agenda for IETF89
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, 20 Feb 2014 15:12:46 -0000

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

He Gerben,

It is too late to submit a draft for discussion in the meeting but you coul=
d put one together and submit it as soon as you can.

So I suggest you present the issues as you see them stating what is missing=
 from current SIPREC specifications and whether it is in scope of the curre=
nt charter or not.

If it is not in scope of the current charter then what change would be need=
ed etc.

Regards
Andy



From: Gerben Stam [mailto:Gerben.Stam@nice.com]
Sent: 20 February 2014 11:49
To: Hutton, Andrew; Paul Kyzivat; 'Charles Eckel (eckelcu)'; Brian Rosen; s=
iprec@ietf.org
Subject: RE: [siprec] SIPREC Draft Agenda for IETF89

Hey Andrew,

I have registered to the event and am making my travel arrangements.
Will not be there all week but Wednesday till Friday.

Am good for a 15min on lossless session in SIPREC for Friday.
Do you expect a proposal document on Lossless approach/advice?

Regards,

Gerben


From: Hutton, Andrew [mailto:andrew.hutton@unify.com]
Sent: woensdag 19 februari 2014 12:20
To: Paul Kyzivat; 'Charles Eckel (eckelcu)'; Gerben Stam; Brian Rosen; sipr=
ec@ietf.org<mailto:siprec@ietf.org>
Subject: [siprec] SIPREC Draft Agenda for IETF89

Hi All,

A draft SIPREC agenda has been uploaded please check this and let me know i=
f want something changing.

The deadline for finalizing the agenda is Monday February 24th.

https://datatracker.ietf.org/meeting/89/agenda/siprec/

Regards
Andy


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">He Gerben,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">It is too late to submit =
a draft for discussion in the meeting but you could put one together and su=
bmit it as soon as you can.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So I suggest you present =
the issues as you see them stating what is missing from current SIPREC spec=
ifications and whether it is in scope of the current charter
 or not. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">If it is not in scope of =
the current charter then what change would be needed etc.<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Andy<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Gerben S=
tam [mailto:Gerben.Stam@nice.com]
<br>
<b>Sent:</b> 20 February 2014 11:49<br>
<b>To:</b> Hutton, Andrew; Paul Kyzivat; 'Charles Eckel (eckelcu)'; Brian R=
osen; siprec@ietf.org<br>
<b>Subject:</b> RE: [siprec] SIPREC Draft Agenda for IETF89<o:p></o:p></spa=
n></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hey Andrew,<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I have registered to the =
event and am making my travel arrangements.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Will not be there all wee=
k but Wednesday till Friday.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Am good for a 15min on lo=
ssless session in SIPREC for Friday.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Do you expect a proposal =
document on Lossless approach/advice?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Gerben<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Hutton, =
Andrew [<a href=3D"mailto:andrew.hutton@unify.com">mailto:andrew.hutton@uni=
fy.com</a>]
<br>
<b>Sent:</b> woensdag 19 februari 2014 12:20<br>
<b>To:</b> Paul Kyzivat; 'Charles Eckel (eckelcu)'; Gerben Stam; Brian Rose=
n; <a href=3D"mailto:siprec@ietf.org">
siprec@ietf.org</a><br>
<b>Subject:</b> [siprec] SIPREC Draft Agenda for IETF89<o:p></o:p></span></=
p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Hi All,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">A draft SIPREC agenda has been uploaded=
 please check this and let me know if want something changing.<o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">The deadline for finalizing the agenda =
is Monday February 24</span><sup><span style=3D"font-size:7.5pt;font-family=
:&quot;Calibri&quot;,&quot;sans-serif&quot;">th</span></sup><span style=3D"=
font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">.<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><a href=3D"https://datatracker.ietf.org=
/meeting/89/agenda/siprec/">https://datatracker.ietf.org/meeting/89/agenda/=
siprec/</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Regards<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Andy<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_9F33F40F6F2CD847824537F3C4E37DDF17D11A62MCHP04MSXglobal_--


From nobody Thu Feb 27 04:05:17 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 00A931A0244 for <siprec@ietfa.amsl.com>; Thu, 27 Feb 2014 04:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.254
X-Spam-Level: 
X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 LaI2UwqD7iQr for <siprec@ietfa.amsl.com>; Thu, 27 Feb 2014 04:05:14 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6D31A0241 for <siprec@ietf.org>; Thu, 27 Feb 2014 04:05:14 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 1011E1EB85F6 for <siprec@ietf.org>; Thu, 27 Feb 2014 13:05:12 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.208]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 13:05:11 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: IESG Discuss on draft-ietf-siprec-architecture
Thread-Index: Ac8ztCobsVNEhyZrQMCBoBrxojBQDg==
Importance: high
X-Priority: 1
Date: Thu, 27 Feb 2014 12:05:11 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D1C1BD@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_9F33F40F6F2CD847824537F3C4E37DDF17D1C1BDMCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/cFW0F2a3PXEZp2NifcZ8wP_L_sU
Subject: [siprec] IESG Discuss on draft-ietf-siprec-architecture
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, 27 Feb 2014 12:05:16 -0000

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

During IESG review of http://tools.ietf.org/html/draft-ietf-siprec-architec=
ture-11 a comment was raised regarding the lack of any text in the document=
 regarding reliable delivery of media.

The document editors discussed this with the AD (Gonzalo) and we propose ad=
ding to the following text to the draft which leaves it open as to whether =
there will be further SIPREC protocol work on this subject. We hope that th=
is is not controversial as we would like to get this draft approved before =
Gonzalo hands over the AD role otherwise we will have further delays.  If y=
ou have any issues with this text please raise them quickly.

3.2.6. Lossless Recording

Session recording may be a regulatory requirement in certain communication =
environments. Such environments may impose a requirement
generally known as Lossless Recording. An overall lossless recordingsolutio=
n may involve multiple layers of solutions. Individual aspects of the solut=
ions may range from administering networks for appropriate QoS, reliable tr=
ansmission of recorded media and perhaps certain SIPREC protocol level capa=
bilities in SRC and SRS.


Regards
Andy


--_000_9F33F40F6F2CD847824537F3C4E37DDF17D1C1BDMCHP04MSXglobal_
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>During IESG review of <a href=3D"http://tools.ietf.org/html/draft-ietf=
-siprec-architecture-11"><font color=3D"blue"><u>http://tools.ietf.org/html=
/draft-ietf-siprec-architecture-11</u></font></a> a comment was raised rega=
rding the lack of any text in the document
regarding reliable delivery of media.</div>
<div>&nbsp;</div>
<div>The document editors discussed this with the AD (Gonzalo) and we propo=
se adding to the following text to the draft which leaves it open as to whe=
ther there will be further SIPREC protocol work on this subject. We hope th=
at this is not controversial as
we would like to get this draft approved before Gonzalo hands over the AD r=
ole otherwise we will have further delays.&nbsp; If you have any issues wit=
h this text please raise them quickly.</div>
<div>&nbsp;</div>
<div>3.2.6. Lossless Recording</div>
<div>&nbsp;</div>
<div><font face=3D"Consolas" size=3D"2"><span style=3D"font-size:10.5pt;">S=
ession recording may be a regulatory requirement in certain communication e=
nvironments. Such environments may impose a requirement</span></font></div>
<div><font face=3D"Consolas" size=3D"2"><span style=3D"font-size:10.5pt;">g=
enerally known as Lossless Recording. An overall lossless recordingsolution=
 may involve multiple layers of solutions. Individual aspects of the soluti=
ons may range from administering networks
for appropriate QoS, reliable transmission of recorded media and perhaps ce=
rtain SIPREC protocol level capabilities in SRC and SRS.</span></font></div=
>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Regards</div>
<div>Andy</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_9F33F40F6F2CD847824537F3C4E37DDF17D1C1BDMCHP04MSXglobal_--


From nobody Thu Feb 27 08:31:01 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 569E21A0323; Thu, 27 Feb 2014 08:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] 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 8nDte_Z_eTWH; Thu, 27 Feb 2014 08:30:56 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F08A61A0234; Thu, 27 Feb 2014 08:30:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140227163055.25856.42857.idtracker@ietfa.amsl.com>
Date: Thu, 27 Feb 2014 08:30:55 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/JaMvOQZB0QSNclx6-Ym47URgss8
Cc: siprec@ietf.org
Subject: [siprec] I-D ACTION:draft-ietf-siprec-architecture-12.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, 27 Feb 2014 16:30:57 -0000

--NextPart

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         : An Architecture for Media Recording using the Session Initiation Protocol
    Author(s)     : A. Hutton, et al
    Filename      : draft-ietf-siprec-architecture
    Pages         : 16 
    Date          : 2014-02-27 
    
   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 describes architectures for
   deploying session recording solutions in an environment which is
   based on the Session Initiation Protocol (SIP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-12.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-siprec-architecture";
 site="ftp.ietf.org"; access-type="anon-ftp";
 directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2014-02-27083055.I-D@ietf.org>


--NextPart--


From nobody Thu Feb 27 08:41:29 2014
Return-Path: <iesg-secretary@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 77A5C1A0348; Thu, 27 Feb 2014 08:41:26 -0800 (PST)
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 xGOeQfJoBuCH; Thu, 27 Feb 2014 08:41:25 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E6B1A0406; Thu, 27 Feb 2014 08:41:22 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140227164122.17858.39668.idtracker@ietfa.amsl.com>
Date: Thu, 27 Feb 2014 08:41:22 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/vI5X7S-N4VY3xAcr2hdVczVGW5k
Cc: siprec mailing list <siprec@ietf.org>, siprec chair <siprec-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [siprec] Document Action: 'An Architecture for Media Recording using the Session Initiation Protocol' to Informational RFC (draft-ietf-siprec-architecture-12.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, 27 Feb 2014 16:41:26 -0000

The IESG has approved the following document:
- 'An Architecture for Media Recording using the Session Initiation
   Protocol'
  (draft-ietf-siprec-architecture-12.txt) as Informational RFC

This document is the product of the SIP Recording Working Group.

The IESG contact persons are Gonzalo Camarillo and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/




Technical Summary:

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 describes architectures for deploying session 
recording solutions in an environment which is based on the Session 
Initiation Protocol (SIP). 


Working Group Summary:

This document has served as the introduction to the work group’s effort 
since it was started, and we have been encouraged that new participants 
have been able to use earlier drafts to come up to speed quickly.   We 
maintained an issue tracker for the document and there are no open 
issues.  


Document Quality:

Most of the “regulars” in the group have done thorough reviews, and 
resolving their comments has been handled expeditiously with very little 
disagreement once we all understood each other’s point of view.  As 
stated above, the document is current with the protocol. 

We have had an early AD review, which did not have many substantive 
comments and all issues raised have been resolved.

WGLC resulted in minor edits although we did not get a lot of comments.  
We believe all of the active WG participants are very familiar with this 
document and are quite comfortable with publishing it.


Personnel:

Brian Rosen is the Document Shepherd. 
Gonzalo Camarillo is the Responsible Area Director.