From andrew.hutton@unify.com Mon Feb 3 06:44:33 2014 Return-Path: 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 ; 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 ; 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 ; 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 ; 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" To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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 DRA= FT 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).

--_000_9F33F40F6F2CD847824537F3C4E37DDF17CE2D41MCHP04MSXglobal_-- From partha@parthasarathi.co.in Thu Feb 6 08:51:23 2014 Return-Path: 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" To: "'Ram Mohan R $rmohanr$'" , "'Gerben Stam'" References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > Date: Thursday, 6 February 2014 8:40 pm > To: Cisco Employee > Cc: "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 > >Date: Thursday, 6 February 2014 3:58 pm > >To: Gerben Stam > >Cc: "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: 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 ; 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: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <00dd01cf235b$a5401470$efc03d50$@co.in> Date: Thu, 6 Feb 2014 11:12:02 -0600 Message-ID: From: Mary Barnes To: Parthasarathi R Content-Type: multipart/alternative; boundary=047d7b2e0983da759104f1bff830 Cc: Gerben Stam , "siprec@ietf.org" , DISPATCH 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > > Date: Thursday, 6 February 2014 8:40 pm > > To: Cisco Employee > > Cc: "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 > > >Date: Thursday, 6 February 2014 3:58 pm > > >To: Gerben Stam > > >Cc: "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

Please don't cross post as that makes it a nightmare f= or 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 maili= ng 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.in> wrote:

Hi Gerben,

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.

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

Including SIPREC mailing alias in this mail thread.

Thanks
Partha

Note:

Use Case 10: High availability and continuous recording.

Specific deployment scenarios present different requir= ements for
system availability, error handling, etc., including t= he
following:

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

o No loss of media recording can occur, includin= g during failure
of an SRS.

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

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

> -----Original Message-----
> From: dispatch [mailto:di= spatch-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.S= tam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@ci= sco.com>
> Cc: "dispatch@ietf.org&q= uot; <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 go= od
> >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 Dispa= tch?
> >
> >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 Compli= ance
> >and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these d= ays
> >Confirmation is needed to acknowledge the entire Communication Ses= sion
> >was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of R= TP
> >content.
> >
> >
> >
> >New requirement is Œlossless=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 t= he
> >receiver AND in case of receiving issues, the sender will resend.<= br> > >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=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<= br> > 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 deployme= nt.
>
>
> 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 a= s
> >sender will send only once, this may lead to loss during failover.=
> >
> >I am not aware of any rfc covering lossless content handover, but<= br> > 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-- From Gerben.Stam@nice.com Fri Feb 7 01:05:50 2014 Return-Path: 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 ; 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 ; 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 ; 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 To: Parthasarathi R , "'Ram Mohan R (rmohanr)'" 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: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 To: Parthasarathi R , "'Ram Mohan R (rmohanr)'" 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: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.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 , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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" To: 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: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > Date: Thursday, 6 February 2014 8:40 pm > To: Cisco Employee > Cc: "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 > >Date: Thursday, 6 February 2014 3:58 pm > >To: Gerben Stam > >Cc: "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: 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 ; 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 ; 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 ; 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 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: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> Date: Thursday, 6 February 2014 8:40 pm >> To: Cisco Employee >> Cc: "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 >>> Date: Thursday, 6 February 2014 3:58 pm >>> To: Gerben Stam >>> Cc: "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: 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 ; 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 ; 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 ; 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)" To: Gerben Stam , Parthasarathi R Thread-Topic: [dispatch] Lossless Recording in SIPREC Thread-Index: AQHPJxqwt8Jn2hui1E6LoRwUDkitrg== Date: Tue, 11 Feb 2014 11:16:19 +0000 Message-ID: References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; 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" To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) . 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

Any more requests for age= nda time during the SIPREC meeting.

<= /p>

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

<= /p>

Regards=

Andy

<= /p>

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 SI= PREC meeting at IETF89 please e-mail the chairs (siprec-chairs@tools.ietf.org) .=

SIPREC has been allocated the dreaded f= inal meeting slot in the DRAFT agenda on Friday March the 7^{th<=
/sup> (See
https://dat=
atracker.ietf.org/meeting/89/agenda.html).}

Of course the draft agenda can change s= o don’t make plans based on this.

Regards

Andy (SIPREC Co-Chair).

--_000_9F33F40F6F2CD847824537F3C4E37DDF17CF0040MCHP04MSXglobal_-- From internet-drafts@ietf.org Tue Feb 11 06:44:32 2014 Return-Path: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; 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)" To: "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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" Date: Tuesday, 11 February 2014 8:14 pm To: "i-d-announce@ietf.org" Cc: "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: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > ) . > > 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: 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 ; 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 ; 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 ; 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)" To: "Hutton, Andrew" , "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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: , Andrew > Date: Tuesday, February 11, 2014 5:57 AM To: "siprec@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 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) . 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

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.

Cheers,

Charles

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.

Any more requests for agenda time = during the SIPREC meeting.

So far the only requests we have a= re 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 IETF= 89 please e-mail the chairs (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://dat= atracker.ietf.org/meeting/89/agenda.html).

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

Regards

Andy (SIPREC Co-Chair).<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">

--_000_CF1F925F1D800eckelcuciscocom_-- From br@brianrosen.net Tue Feb 11 09:02:25 2014 Return-Path: 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 ; 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 ; 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 ; Tue, 11 Feb 2014 09:02:21 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id lx4so669859iec.15 for ; 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 (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 In-Reply-To: Date: Tue, 11 Feb 2014 12:02:18 -0500 Message-Id: <15A1E9D5-9F34-43E5-ABF8-9387FDD3F167@brianrosen.net> References: To: "Charles Eckel (eckelcu)" X-Mailer: Apple Mail (2.1827) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) = 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: , Andrew > Date: Tuesday, February 11, 2014 5:57 AM > To: "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 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.

Cheers,
Charles

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.

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) = .

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=92t = make plans based on this.

Regards
Andy (SIPREC = Co-Chair).

<= /blockquote>_______________________________________________
sipr= ec mailing list
siprec@ietf.org
https://www.ietf.or= g/mailman/listinfo/siprec

= --Apple-Mail=_EF8B73DA-5950-4EE2-9CBF-9ABC2E9477EB-- From internet-drafts@ietf.org Tue Feb 11 18:45:55 2014 Return-Path: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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)" To: Dave Higton , "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: References: <9B0B6FB9606F4D4AB133C5E9A203B69405E7CEAA2F@SOUEXC01.eu.nice.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; 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)" To: "Ram Mohan R (rmohanr)" , "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: References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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)" 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 > 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: 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 ; 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 ; 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 ; 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)" To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) 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: 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 ; 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 ; 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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) 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: 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 ; 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 ; 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 ; Thu, 13 Feb 2014 07:15:36 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id k19so13171658igc.5 for ; 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 (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 In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com> Date: Thu, 13 Feb 2014 10:15:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21794EB0EE82B0458A524942A141542B31DA9F3C@szxema508-mbs.china.huawei.com> <9B0B6FB9606F4D4AB133C5E9A203B69405E811FC0A@SOUEXC01.eu.nice.com> To: Dave Higton 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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) > 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: 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 ; 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 ; 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 ; 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 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: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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)" 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 >> 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: 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 ; 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 ; 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 ; 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" To: 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> In-Reply-To: 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 List-Unsubscribe: ,