From partha@parthasarathi.co.in Tue Jan 1 07:57:13 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221C421E8039 for ; Tue, 1 Jan 2013 07:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwKZIbz10IEq for ; Tue, 1 Jan 2013 07:57:12 -0800 (PST) Received: from outbound-us3.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.157]) by ietfa.amsl.com (Postfix) with ESMTP id EE10621E8030 for ; Tue, 1 Jan 2013 07:57:11 -0800 (PST) Received: from userPC (unknown [122.179.101.131]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 9730086893B; Tue, 1 Jan 2013 15:57:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1357055831; bh=owoyle4N97slQGDB58ip+7KBtZlDRS9V9wM8teJCD3Y=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dOAQm3SSrkBUO+nqR2xt+P8+y0p660rIsFCWgPwOK7NG/5G3CbYxfV8TKH3kYJJ6f hM5ojU0TzHneNzGVsNwwhlMvkqIN8aXob23nix1Uu+sCmDImzdmcwcw9A9cqDvw6+C sbNtf0NvdR9lahpddJTU2c1z8FJOETYQtv0Nlq68= From: "Parthasarathi R" To: "'Charles Eckel \(eckelcu\)'" , References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> <003201cdbd0e$2d5ca310$8815e930$@co.in> <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> Date: Tue, 1 Jan 2013 21:27:04 +0530 Message-ID: <000001cde838$a76c7d10$f6457730$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wex0ks8AbuINQQK24PeueYzN4BQAAie+QAlkjWwAAypQxQAABAqcwCsnuB2A= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0203.50E30757.003C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jan 2013 15:57:13 -0000 Hi Charles, After a long time, I'm looking to this mail thread and understand that there is a non-closed item on metadata mixing representation. As per the current model, SRC mixing will leads to the loss of data like "who is the current contributor of the mixed media". We have tried to use CSRC earlier and not accepted as a generic solution. In case any other alternative exists to solve this issue, Please let us know. Hope Turret case solution is clarified to you. Thanks Partha > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: Wednesday, November 07, 2012 11:23 PM > To: Parthasarathi R; siprec@ietf.org > Subject: RE: [siprec] FW: New Version Notification for draft-ram- > siprec-callflows-02.txt > > > -----Original Message----- > > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > > Sent: Wednesday, November 07, 2012 12:35 PM > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: RE: [siprec] FW: New Version Notification for draft-ram- > siprec- > > callflows-02.txt > > > > Hi Charles, > > > > Thanks a lot for your review. Please read inline. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: Saturday, November 03, 2012 10:32 PM > > To: Parthasarathi R; siprec@ietf.org > > Subject: RE: [siprec] FW: New Version Notification for > > draft-ram-siprec-callflows-02.txt > > > > Hi draft authors, > > > > I read the draft and have a few comments to share. > > > > 1) abstract > > s/model defined the metadata draft/model defined in the metadata > draft > > > > 2) overview > > s/not normative on any aspect of SIP/not normative on any aspect of > SIPREC > > > > I'll updated in the next revision > > > > 3) Section 3.1 reads, "The following example provides all the tuples > ..." > > IMO, this sounds as if it provides an exhaustive list; however, I do > not > > think that is the intent. Rather, I think it provides an example of > metadata > > that may be included in a typical metadata body. It would be good to > be > > clean on the intent so that the example is read in the proper from of > mind. > > > > Text will be updated to indicate the typical metadata body > in the > > next revision. > > > > 4) Section 3.1. It would be helpful to explain the call scenario to > which > > the metadata example applies. For example, it appears to be a two > party > > call with 4 streams per participant, 2 in each direction (e.g. one > for audio > > and one for video). Alternatively, you can remove this example as it > appears > > to be a duplicate of the next example (in section 4). > > Could you explain this comment as Section 4 is security > > consideration in -02 draft. My guess is that your comment is based on > -01 > > draft. > > Yes, you are correct. Sorry about that. And yes, the way the -02 drafts > addresses it works for me. > > > 5) Section 4.2 > > s/Media Streams sent by each participant is received all/Media > streams sent > > by each participant are received by the > > s/snippets of SDP is shown/snippets of SDP are shown > > > > 6) Section 4.3, example 2, it would be better if you remain > consistent with > > the participant names (i.e. A/B or Ram/Partha. > > > > 7) F4, it would be helpful to explain the inactive and sendonly SDP > > attributes by adding text explaining that during the hold, A stops > sending > > streams (inactive), while B continues sending (sendonly). > > > > 5, 6, 7 comments will be incorporated in the next revision > > > > > > 8) Section 4.4, metadata > > Is the idea that the streams remain the same and only the participant > > changes? If so, state that. It is hard to tell by visual inspection > whether > > the stream id is an exact match of perhaps has some small change. > Also, I > > was expecting to see metadata saying the Ram left and providing a > > disassociation time. Instead, this is provided only the end of the > call. Is > > that done just in case Ram returns before the end of the call. In any > case, > > it would be good to state the reasoning so that it is clear why the > metadata > > is as it is. > > > > 9) Section 4.6, F1 > > Why does stream == stream? > > > > Because it is mixed stream. There is no way to distinguish > the > > directionality of the individual participants. > > > > Also, how do you indicate when each person is talking? > > It is possible that the information may be lost at SRC > itself > > > > This is troubling to me, but perhaps I am the only one that cares. I > also tend to think I do not understand the turret case well enough at > this point. Maybe someone here at IETF 85 this week can set me > straight. > > Cheers, > Charles > > > Is it accomplished using CNAME and SSRC? > > I'm not sure whether CNAME & SSRC will help for mixed stream > > > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > > > Of Parthasarathi R > > > Sent: Monday, October 22, 2012 1:56 PM > > > To: siprec@ietf.org > > > Subject: [siprec] FW: New Version Notification for draft-ram- > siprec- > > > callflows-02.txt > > > > > > Hi all, > > > > > > draft-ram-siprec-callflows-02 is published with the following > update: > > > > > > 1) Updated the callflow as per draft-ietf-siprec-metadata-08 > > > 2) Removed Metadata Example section > > > 3) Incorporated Ofir Rath review comments > > > > > > The current open issue in the drafts > > > 1) Incorporating RS SIP messages with metadata XML messages for all > > > callflow > > > 2) Callflows provided by Ofir Rath has to be discussed and added. > > > > > > Could you please provide your valuable comments on > > > draft-ram-siprec-callflows-02. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Monday, October 22, 2012 11:02 PM > > > To: partha@parthasarathi.co.in > > > Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu > > > Subject: New Version Notification for draft-ram-siprec-callflows- > 02.txt > > > > > > > > > A new version of I-D, draft-ram-siprec-callflows-02.txt > > > has been successfully submitted by Parthasarathi Ravindran and > posted to > > > the > > > IETF repository. > > > > > > Filename: draft-ram-siprec-callflows > > > Revision: 02 > > > Title: Session Initiation Protocol (SIP) Recording Call > > Flows > > > Creation date: 2012-10-22 > > > WG ID: Individual Submission > > > Number of pages: 18 > > > URL: > > http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- > > > 02.txt > > > Status: > > http://datatracker.ietf.org/doc/draft-ram-siprec-callflows > > > Htmlized: http://tools.ietf.org/html/draft-ram-siprec- > callflows-02 > > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-ram-siprec-callflows-02 > > > > > > Abstract: > > > Session recording is a critical requirement in many > communications > > > environments such as call centers and financial trading. In > some of > > > these environments, all calls must be recorded for regulatory, > > > compliance, and consumer protection reasons. Recording of a > session > > > is typically performed by sending a copy of a media stream to a > > > recording device. This document lists call flows that has > snapshot > > > of metadata sent from SRC to SRS, the metadata format for which > is > > > described in [I-D.ietf-siprec-metadata] . This is purely an > > > informational document that is written to support the model > defined > > > the metadata draft. > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Jan 1 13:55:53 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874821F0C3E for ; Tue, 1 Jan 2013 13:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YR5mesugNJq for ; Tue, 1 Jan 2013 13:55:52 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1521F8E6F for ; Tue, 1 Jan 2013 13:55:52 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id ilhY1k0011ZXKqc51lvrde; Tue, 01 Jan 2013 21:55:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id ilvr1k00Y3ZTu2S3hlvrb1; Tue, 01 Jan 2013 21:55:51 +0000 Message-ID: <50E35B66.9080206@alum.mit.edu> Date: Tue, 01 Jan 2013 16:55:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: siprec@ietf.org References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> <003201cdbd0e$2d5ca310$8815e930$@co.in> <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> <000001cde838$a76c7d10$f6457730$@co.in> In-Reply-To: <000001cde838$a76c7d10$f6457730$@co.in> 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=1357077351; bh=T6CmQmTghOq2BZNXkbu8iasJqdjhcJ4V3Wi6y7C3rFY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kh6RStrMC514hNfTxM6CTx82qp6CJN5VvTBMsMLhEid8x3+xgHBapI72EMchtfbfn tDpS/J2Y42NpRPKogLoIluTvF+ejatrgYVVe2JX8O7NyiS5zBBtfDbi92fLwLgOuLM hanBRAzw5RaTSJ9cBZJZr/NnDclODeuI3WTpMKqhsdZWvujyNmYEJ6mqN8L+w7QaTW aXDGIK35iCYIrxF7MkLPrmWU/xl33SrHPvPBMTM79l9zy1poPXOx2KtbNxq6Ri88hW xD6p7KkV8+cH+Qwa0E3JtcUPVOZa8yStmKY1LQ1tRtUfyVv6CFVQkPX/uOUWKJ0arS e7TmbPVboV9eQ== Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jan 2013 21:55:53 -0000 On 1/1/13 10:57 AM, Parthasarathi R wrote: > Hi Charles, > > After a long time, I'm looking to this mail thread and understand that there > is a non-closed item on metadata mixing representation. As per the current > model, SRC mixing will leads to the loss of data like "who is the current > contributor of the mixed media". We have tried to use CSRC earlier and not > accepted as a generic solution. In case any other alternative exists to > solve this issue, Please let us know. On "solution" is just to acknowledge it as a limitation. Thanks, Paul > Hope Turret case solution is clarified to you. > > Thanks > Partha > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: Wednesday, November 07, 2012 11:23 PM >> To: Parthasarathi R; siprec@ietf.org >> Subject: RE: [siprec] FW: New Version Notification for draft-ram- >> siprec-callflows-02.txt >> >>> -----Original Message----- >>> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >>> Sent: Wednesday, November 07, 2012 12:35 PM >>> To: Charles Eckel (eckelcu); siprec@ietf.org >>> Subject: RE: [siprec] FW: New Version Notification for draft-ram- >> siprec- >>> callflows-02.txt >>> >>> Hi Charles, >>> >>> Thanks a lot for your review. Please read inline. >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>> Sent: Saturday, November 03, 2012 10:32 PM >>> To: Parthasarathi R; siprec@ietf.org >>> Subject: RE: [siprec] FW: New Version Notification for >>> draft-ram-siprec-callflows-02.txt >>> >>> Hi draft authors, >>> >>> I read the draft and have a few comments to share. >>> >>> 1) abstract >>> s/model defined the metadata draft/model defined in the metadata >> draft >>> >>> 2) overview >>> s/not normative on any aspect of SIP/not normative on any aspect of >> SIPREC >>> >>> I'll updated in the next revision >>> >>> 3) Section 3.1 reads, "The following example provides all the tuples >> ..." >>> IMO, this sounds as if it provides an exhaustive list; however, I do >> not >>> think that is the intent. Rather, I think it provides an example of >> metadata >>> that may be included in a typical metadata body. It would be good to >> be >>> clean on the intent so that the example is read in the proper from of >> mind. >>> >>> Text will be updated to indicate the typical metadata body >> in the >>> next revision. >>> >>> 4) Section 3.1. It would be helpful to explain the call scenario to >> which >>> the metadata example applies. For example, it appears to be a two >> party >>> call with 4 streams per participant, 2 in each direction (e.g. one >> for audio >>> and one for video). Alternatively, you can remove this example as it >> appears >>> to be a duplicate of the next example (in section 4). >>> Could you explain this comment as Section 4 is security >>> consideration in -02 draft. My guess is that your comment is based on >> -01 >>> draft. >> >> Yes, you are correct. Sorry about that. And yes, the way the -02 drafts >> addresses it works for me. >> >>> 5) Section 4.2 >>> s/Media Streams sent by each participant is received all/Media >> streams sent >>> by each participant are received by the >>> s/snippets of SDP is shown/snippets of SDP are shown >>> >>> 6) Section 4.3, example 2, it would be better if you remain >> consistent with >>> the participant names (i.e. A/B or Ram/Partha. >>> >>> 7) F4, it would be helpful to explain the inactive and sendonly SDP >>> attributes by adding text explaining that during the hold, A stops >> sending >>> streams (inactive), while B continues sending (sendonly). >>> >>> 5, 6, 7 comments will be incorporated in the next revision >>> >>> >>> 8) Section 4.4, metadata >>> Is the idea that the streams remain the same and only the participant >>> changes? If so, state that. It is hard to tell by visual inspection >> whether >>> the stream id is an exact match of perhaps has some small change. >> Also, I >>> was expecting to see metadata saying the Ram left and providing a >>> disassociation time. Instead, this is provided only the end of the >> call. Is >>> that done just in case Ram returns before the end of the call. In any >> case, >>> it would be good to state the reasoning so that it is clear why the >> metadata >>> is as it is. >>> >>> 9) Section 4.6, F1 >>> Why does stream == stream? >>> >>> Because it is mixed stream. There is no way to distinguish >> the >>> directionality of the individual participants. >>> >>> Also, how do you indicate when each person is talking? >>> It is possible that the information may be lost at SRC >> itself >>> >> >> This is troubling to me, but perhaps I am the only one that cares. I >> also tend to think I do not understand the turret case well enough at >> this point. Maybe someone here at IETF 85 this week can set me >> straight. >> >> Cheers, >> Charles >> >>> Is it accomplished using CNAME and SSRC? >>> I'm not sure whether CNAME & SSRC will help for mixed stream >>> >>> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf >>>> Of Parthasarathi R >>>> Sent: Monday, October 22, 2012 1:56 PM >>>> To: siprec@ietf.org >>>> Subject: [siprec] FW: New Version Notification for draft-ram- >> siprec- >>>> callflows-02.txt >>>> >>>> Hi all, >>>> >>>> draft-ram-siprec-callflows-02 is published with the following >> update: >>>> >>>> 1) Updated the callflow as per draft-ietf-siprec-metadata-08 >>>> 2) Removed Metadata Example section >>>> 3) Incorporated Ofir Rath review comments >>>> >>>> The current open issue in the drafts >>>> 1) Incorporating RS SIP messages with metadata XML messages for all >>>> callflow >>>> 2) Callflows provided by Ofir Rath has to be discussed and added. >>>> >>>> Could you please provide your valuable comments on >>>> draft-ram-siprec-callflows-02. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Monday, October 22, 2012 11:02 PM >>>> To: partha@parthasarathi.co.in >>>> Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu >>>> Subject: New Version Notification for draft-ram-siprec-callflows- >> 02.txt >>>> >>>> >>>> A new version of I-D, draft-ram-siprec-callflows-02.txt >>>> has been successfully submitted by Parthasarathi Ravindran and >> posted to >>>> the >>>> IETF repository. >>>> >>>> Filename: draft-ram-siprec-callflows >>>> Revision: 02 >>>> Title: Session Initiation Protocol (SIP) Recording Call >>> Flows >>>> Creation date: 2012-10-22 >>>> WG ID: Individual Submission >>>> Number of pages: 18 >>>> URL: >>> http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- >>>> 02.txt >>>> Status: >>> http://datatracker.ietf.org/doc/draft-ram-siprec-callflows >>>> Htmlized: http://tools.ietf.org/html/draft-ram-siprec- >> callflows-02 >>>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-ram-siprec-callflows-02 >>>> >>>> Abstract: >>>> Session recording is a critical requirement in many >> communications >>>> environments such as call centers and financial trading. In >> some of >>>> these environments, all calls must be recorded for regulatory, >>>> compliance, and consumer protection reasons. Recording of a >> session >>>> is typically performed by sending a copy of a media stream to a >>>> recording device. This document lists call flows that has >> snapshot >>>> of metadata sent from SRC to SRS, the metadata format for which >> is >>>> described in [I-D.ietf-siprec-metadata] . This is purely an >>>> informational document that is written to support the model >> defined >>>> the metadata draft. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From eckelcu@cisco.com Wed Jan 2 10:15:47 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E3B21F87C8 for ; Wed, 2 Jan 2013 10:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP5YHsv+K0D3 for ; Wed, 2 Jan 2013 10:15:46 -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 E048D21F8461 for ; Wed, 2 Jan 2013 10:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9790; q=dns/txt; s=iport; t=1357150546; x=1358360146; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XOBKhPX0HUoovrYEQ7xERrel4EJPoDm4xrRjqVbHs/w=; b=F6Iucr8NwOJbwqrQqnL3xRrrVthfiilV5WGMxR0+yezZbQsXA6VL/DpO 7c3aGXuLdOO02SDQ/AW4OOjXWFYY1HWwvOD5ZadZF4/GThS5+O7y+YvW+ sHR4hX3JrXEcRiKgiN5z8AMAgG7cAa+Pt34qAoURCiVJAp3TI8N98T+SN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj86ABp45FCtJXG//2dsb2JhbABFDoFxgW65VBZzgh4BAQEEAQEBNzQJDgQCAQgOAwQBAQEKFAkHJwsUCAEIAgQBEggBEod3AQcFuQSMVxuDR2EDlyiPLII2PoFxNQ X-IronPort-AV: E=Sophos;i="4.84,397,1355097600"; d="scan'208";a="155150416" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 02 Jan 2013 18:15:45 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r02IFjCO004002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 18:15:45 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 12:15:44 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt Thread-Index: AQHN6GrGoENX1oNMD0aCcyannMmXdZg2WFtA Date: Wed, 2 Jan 2013 18:15:44 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046F3449@xmb-aln-x08.cisco.com> References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> <003201cdbd0e$2d5ca310$8815e930$@co.in> <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> <000001cde838$a76c7d10$f6457730$@co.in> <50E35B66.9080206@alum.mit.edu> In-Reply-To: <50E35B66.9080206@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 18:15:47 -0000 I'm okay with listing this as a limitation as long as the limitation is sta= ted as being due to the way media streams are constructed in the turret cas= e and not due to SRC mixing of media streams in general. For the general ca= se, no information present in the CS should be lost as a result of SRC mixi= ng for the RS. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, January 01, 2013 1:56 PM > To: siprec@ietf.org > Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec- > callflows-02.txt >=20 > On 1/1/13 10:57 AM, Parthasarathi R wrote: > > Hi Charles, > > > > After a long time, I'm looking to this mail thread and understand that = there > > is a non-closed item on metadata mixing representation. As per the curr= ent > > model, SRC mixing will leads to the loss of data like "who is the curre= nt > > contributor of the mixed media". We have tried to use CSRC earlier and = not > > accepted as a generic solution. In case any other alternative exists to > > solve this issue, Please let us know. >=20 > On "solution" is just to acknowledge it as a limitation. >=20 > Thanks, > Paul >=20 > > Hope Turret case solution is clarified to you. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> Sent: Wednesday, November 07, 2012 11:23 PM > >> To: Parthasarathi R; siprec@ietf.org > >> Subject: RE: [siprec] FW: New Version Notification for draft-ram- > >> siprec-callflows-02.txt > >> > >>> -----Original Message----- > >>> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > >>> Sent: Wednesday, November 07, 2012 12:35 PM > >>> To: Charles Eckel (eckelcu); siprec@ietf.org > >>> Subject: RE: [siprec] FW: New Version Notification for draft-ram- > >> siprec- > >>> callflows-02.txt > >>> > >>> Hi Charles, > >>> > >>> Thanks a lot for your review. Please read inline. > >>> > >>> Thanks > >>> Partha > >>> > >>> -----Original Message----- > >>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>> Sent: Saturday, November 03, 2012 10:32 PM > >>> To: Parthasarathi R; siprec@ietf.org > >>> Subject: RE: [siprec] FW: New Version Notification for > >>> draft-ram-siprec-callflows-02.txt > >>> > >>> Hi draft authors, > >>> > >>> I read the draft and have a few comments to share. > >>> > >>> 1) abstract > >>> s/model defined the metadata draft/model defined in the metadata > >> draft > >>> > >>> 2) overview > >>> s/not normative on any aspect of SIP/not normative on any aspect of > >> SIPREC > >>> > >>> I'll updated in the next revision > >>> > >>> 3) Section 3.1 reads, "The following example provides all the tuples > >> ..." > >>> IMO, this sounds as if it provides an exhaustive list; however, I do > >> not > >>> think that is the intent. Rather, I think it provides an example of > >> metadata > >>> that may be included in a typical metadata body. It would be good to > >> be > >>> clean on the intent so that the example is read in the proper from of > >> mind. > >>> > >>> Text will be updated to indicate the typical metadata body > >> in the > >>> next revision. > >>> > >>> 4) Section 3.1. It would be helpful to explain the call scenario to > >> which > >>> the metadata example applies. For example, it appears to be a two > >> party > >>> call with 4 streams per participant, 2 in each direction (e.g. one > >> for audio > >>> and one for video). Alternatively, you can remove this example as it > >> appears > >>> to be a duplicate of the next example (in section 4). > >>> Could you explain this comment as Section 4 is security > >>> consideration in -02 draft. My guess is that your comment is based on > >> -01 > >>> draft. > >> > >> Yes, you are correct. Sorry about that. And yes, the way the -02 draft= s > >> addresses it works for me. > >> > >>> 5) Section 4.2 > >>> s/Media Streams sent by each participant is received all/Media > >> streams sent > >>> by each participant are received by the > >>> s/snippets of SDP is shown/snippets of SDP are shown > >>> > >>> 6) Section 4.3, example 2, it would be better if you remain > >> consistent with > >>> the participant names (i.e. A/B or Ram/Partha. > >>> > >>> 7) F4, it would be helpful to explain the inactive and sendonly SDP > >>> attributes by adding text explaining that during the hold, A stops > >> sending > >>> streams (inactive), while B continues sending (sendonly). > >>> > >>> 5, 6, 7 comments will be incorporated in the next revision > >>> > >>> > >>> 8) Section 4.4, metadata > >>> Is the idea that the streams remain the same and only the participant > >>> changes? If so, state that. It is hard to tell by visual inspection > >> whether > >>> the stream id is an exact match of perhaps has some small change. > >> Also, I > >>> was expecting to see metadata saying the Ram left and providing a > >>> disassociation time. Instead, this is provided only the end of the > >> call. Is > >>> that done just in case Ram returns before the end of the call. In any > >> case, > >>> it would be good to state the reasoning so that it is clear why the > >> metadata > >>> is as it is. > >>> > >>> 9) Section 4.6, F1 > >>> Why does stream =3D=3D stream? > >>> > >>> Because it is mixed stream. There is no way to distinguish > >> the > >>> directionality of the individual participants. > >>> > >>> Also, how do you indicate when each person is talking? > >>> It is possible that the information may be lost at SRC > >> itself > >>> > >> > >> This is troubling to me, but perhaps I am the only one that cares. I > >> also tend to think I do not understand the turret case well enough at > >> this point. Maybe someone here at IETF 85 this week can set me > >> straight. > >> > >> Cheers, > >> Charles > >> > >>> Is it accomplished using CNAME and SSRC? > >>> I'm not sure whether CNAME & SSRC will help for mixed stream > >>> > >>> > >>> Cheers, > >>> Charles > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf > >>>> Of Parthasarathi R > >>>> Sent: Monday, October 22, 2012 1:56 PM > >>>> To: siprec@ietf.org > >>>> Subject: [siprec] FW: New Version Notification for draft-ram- > >> siprec- > >>>> callflows-02.txt > >>>> > >>>> Hi all, > >>>> > >>>> draft-ram-siprec-callflows-02 is published with the following > >> update: > >>>> > >>>> 1) Updated the callflow as per draft-ietf-siprec-metadata-08 > >>>> 2) Removed Metadata Example section > >>>> 3) Incorporated Ofir Rath review comments > >>>> > >>>> The current open issue in the drafts > >>>> 1) Incorporating RS SIP messages with metadata XML messages for all > >>>> callflow > >>>> 2) Callflows provided by Ofir Rath has to be discussed and added. > >>>> > >>>> Could you please provide your valuable comments on > >>>> draft-ram-siprec-callflows-02. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> -----Original Message----- > >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>>> Sent: Monday, October 22, 2012 11:02 PM > >>>> To: partha@parthasarathi.co.in > >>>> Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu > >>>> Subject: New Version Notification for draft-ram-siprec-callflows- > >> 02.txt > >>>> > >>>> > >>>> A new version of I-D, draft-ram-siprec-callflows-02.txt > >>>> has been successfully submitted by Parthasarathi Ravindran and > >> posted to > >>>> the > >>>> IETF repository. > >>>> > >>>> Filename: draft-ram-siprec-callflows > >>>> Revision: 02 > >>>> Title: Session Initiation Protocol (SIP) Recording Call > >>> Flows > >>>> Creation date: 2012-10-22 > >>>> WG ID: Individual Submission > >>>> Number of pages: 18 > >>>> URL: > >>> http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- > >>>> 02.txt > >>>> Status: > >>> http://datatracker.ietf.org/doc/draft-ram-siprec-callflows > >>>> Htmlized: http://tools.ietf.org/html/draft-ram-siprec- > >> callflows-02 > >>>> Diff: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-callflows-02 > >>>> > >>>> Abstract: > >>>> Session recording is a critical requirement in many > >> communications > >>>> environments such as call centers and financial trading. In > >> some of > >>>> these environments, all calls must be recorded for regulatory, > >>>> compliance, and consumer protection reasons. Recording of a > >> session > >>>> is typically performed by sending a copy of a media stream to a > >>>> recording device. This document lists call flows that has > >> snapshot > >>>> of metadata sent from SRC to SRS, the metadata format for which > >> is > >>>> described in [I-D.ietf-siprec-metadata] . This is purely an > >>>> informational document that is written to support the model > >> defined > >>>> the metadata draft. > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat > >>>> > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Jan 2 11:23:50 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CBE21F8751 for ; Wed, 2 Jan 2013 11:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsiwGZtMgq+9 for ; Wed, 2 Jan 2013 11:23:47 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE0121F84E0 for ; Wed, 2 Jan 2013 11:23:45 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id j10u1k0031vXlb8517PlkL; Wed, 02 Jan 2013 19:23:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id j7Pk1k00m3ZTu2S3d7Pksg; Wed, 02 Jan 2013 19:23:44 +0000 Message-ID: <50E48940.4030101@alum.mit.edu> Date: Wed, 02 Jan 2013 14:23:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> <003201cdbd0e$2d5ca310$8815e930$@co.in> <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> <000001cde838$a76c7d10$f6457730$@co.in> <50E35B66.9080206@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046F3449@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046F3449@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357154625; bh=aEr9DDGSjB1oFLBLng7GT7Lws3ZeKDWEyXCVxHGgfU8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fVnm3rW0A7k/Nm1bs5eY4cMth/Q72keLCQgDuaDOjhDDSeWyWoybDN1yrsCit0gv7 osg6xat94RbKefmZMsu+R1RvXk9xiMS72SIa0IJ397dbgz+nffAG4Be/+0sJUOdtPy huo8syjuORHCYGPNaTJ1X1rt5bqzF//R8gOaxMUUOmdqecblmu5JqY2NRWx+fSnODh NPK4yHl572M6MnWVR8PXKvJhxmBAs7gnz6E2erKrFVNT84cmfh/Hu6gD1QOm4UEVut 9MY7lwS5P/cek6YLj7PToFoSFL9UbQMGyT2gh98S4g+GlFr5xeZ7CcPvuBJN4IMtbh wWjq/VGi/cNbA== Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 19:23:50 -0000 On 1/2/13 1:15 PM, Charles Eckel (eckelcu) wrote: > I'm okay with listing this as a limitation as long as the limitation is stated as being due to the way media streams are constructed in the turret case and not due to SRC mixing of media streams in general. For the general case, no information present in the CS should be lost as a result of SRC mixing for the RS. I was thinking that it is *permissible* (but not recommended) for an SRC to do a very simplistic form of mixing - with just one SSRC and no CSRCs - if it wishes. I think we should not exclude that, because doing so may exclude some servers from being SRCs. The turret might be one instance of that. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Tuesday, January 01, 2013 1:56 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec- >> callflows-02.txt >> >> On 1/1/13 10:57 AM, Parthasarathi R wrote: >>> Hi Charles, >>> >>> After a long time, I'm looking to this mail thread and understand that there >>> is a non-closed item on metadata mixing representation. As per the current >>> model, SRC mixing will leads to the loss of data like "who is the current >>> contributor of the mixed media". We have tried to use CSRC earlier and not >>> accepted as a generic solution. In case any other alternative exists to >>> solve this issue, Please let us know. >> >> On "solution" is just to acknowledge it as a limitation. >> >> Thanks, >> Paul >> >>> Hope Turret case solution is clarified to you. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: Wednesday, November 07, 2012 11:23 PM >>>> To: Parthasarathi R; siprec@ietf.org >>>> Subject: RE: [siprec] FW: New Version Notification for draft-ram- >>>> siprec-callflows-02.txt >>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >>>>> Sent: Wednesday, November 07, 2012 12:35 PM >>>>> To: Charles Eckel (eckelcu); siprec@ietf.org >>>>> Subject: RE: [siprec] FW: New Version Notification for draft-ram- >>>> siprec- >>>>> callflows-02.txt >>>>> >>>>> Hi Charles, >>>>> >>>>> Thanks a lot for your review. Please read inline. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>> Sent: Saturday, November 03, 2012 10:32 PM >>>>> To: Parthasarathi R; siprec@ietf.org >>>>> Subject: RE: [siprec] FW: New Version Notification for >>>>> draft-ram-siprec-callflows-02.txt >>>>> >>>>> Hi draft authors, >>>>> >>>>> I read the draft and have a few comments to share. >>>>> >>>>> 1) abstract >>>>> s/model defined the metadata draft/model defined in the metadata >>>> draft >>>>> >>>>> 2) overview >>>>> s/not normative on any aspect of SIP/not normative on any aspect of >>>> SIPREC >>>>> >>>>> I'll updated in the next revision >>>>> >>>>> 3) Section 3.1 reads, "The following example provides all the tuples >>>> ..." >>>>> IMO, this sounds as if it provides an exhaustive list; however, I do >>>> not >>>>> think that is the intent. Rather, I think it provides an example of >>>> metadata >>>>> that may be included in a typical metadata body. It would be good to >>>> be >>>>> clean on the intent so that the example is read in the proper from of >>>> mind. >>>>> >>>>> Text will be updated to indicate the typical metadata body >>>> in the >>>>> next revision. >>>>> >>>>> 4) Section 3.1. It would be helpful to explain the call scenario to >>>> which >>>>> the metadata example applies. For example, it appears to be a two >>>> party >>>>> call with 4 streams per participant, 2 in each direction (e.g. one >>>> for audio >>>>> and one for video). Alternatively, you can remove this example as it >>>> appears >>>>> to be a duplicate of the next example (in section 4). >>>>> Could you explain this comment as Section 4 is security >>>>> consideration in -02 draft. My guess is that your comment is based on >>>> -01 >>>>> draft. >>>> >>>> Yes, you are correct. Sorry about that. And yes, the way the -02 drafts >>>> addresses it works for me. >>>> >>>>> 5) Section 4.2 >>>>> s/Media Streams sent by each participant is received all/Media >>>> streams sent >>>>> by each participant are received by the >>>>> s/snippets of SDP is shown/snippets of SDP are shown >>>>> >>>>> 6) Section 4.3, example 2, it would be better if you remain >>>> consistent with >>>>> the participant names (i.e. A/B or Ram/Partha. >>>>> >>>>> 7) F4, it would be helpful to explain the inactive and sendonly SDP >>>>> attributes by adding text explaining that during the hold, A stops >>>> sending >>>>> streams (inactive), while B continues sending (sendonly). >>>>> >>>>> 5, 6, 7 comments will be incorporated in the next revision >>>>> >>>>> >>>>> 8) Section 4.4, metadata >>>>> Is the idea that the streams remain the same and only the participant >>>>> changes? If so, state that. It is hard to tell by visual inspection >>>> whether >>>>> the stream id is an exact match of perhaps has some small change. >>>> Also, I >>>>> was expecting to see metadata saying the Ram left and providing a >>>>> disassociation time. Instead, this is provided only the end of the >>>> call. Is >>>>> that done just in case Ram returns before the end of the call. In any >>>> case, >>>>> it would be good to state the reasoning so that it is clear why the >>>> metadata >>>>> is as it is. >>>>> >>>>> 9) Section 4.6, F1 >>>>> Why does stream == stream? >>>>> >>>>> Because it is mixed stream. There is no way to distinguish >>>> the >>>>> directionality of the individual participants. >>>>> >>>>> Also, how do you indicate when each person is talking? >>>>> It is possible that the information may be lost at SRC >>>> itself >>>>> >>>> >>>> This is troubling to me, but perhaps I am the only one that cares. I >>>> also tend to think I do not understand the turret case well enough at >>>> this point. Maybe someone here at IETF 85 this week can set me >>>> straight. >>>> >>>> Cheers, >>>> Charles >>>> >>>>> Is it accomplished using CNAME and SSRC? >>>>> I'm not sure whether CNAME & SSRC will help for mixed stream >>>>> >>>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Parthasarathi R >>>>>> Sent: Monday, October 22, 2012 1:56 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] FW: New Version Notification for draft-ram- >>>> siprec- >>>>>> callflows-02.txt >>>>>> >>>>>> Hi all, >>>>>> >>>>>> draft-ram-siprec-callflows-02 is published with the following >>>> update: >>>>>> >>>>>> 1) Updated the callflow as per draft-ietf-siprec-metadata-08 >>>>>> 2) Removed Metadata Example section >>>>>> 3) Incorporated Ofir Rath review comments >>>>>> >>>>>> The current open issue in the drafts >>>>>> 1) Incorporating RS SIP messages with metadata XML messages for all >>>>>> callflow >>>>>> 2) Callflows provided by Ofir Rath has to be discussed and added. >>>>>> >>>>>> Could you please provide your valuable comments on >>>>>> draft-ram-siprec-callflows-02. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Sent: Monday, October 22, 2012 11:02 PM >>>>>> To: partha@parthasarathi.co.in >>>>>> Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu >>>>>> Subject: New Version Notification for draft-ram-siprec-callflows- >>>> 02.txt >>>>>> >>>>>> >>>>>> A new version of I-D, draft-ram-siprec-callflows-02.txt >>>>>> has been successfully submitted by Parthasarathi Ravindran and >>>> posted to >>>>>> the >>>>>> IETF repository. >>>>>> >>>>>> Filename: draft-ram-siprec-callflows >>>>>> Revision: 02 >>>>>> Title: Session Initiation Protocol (SIP) Recording Call >>>>> Flows >>>>>> Creation date: 2012-10-22 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 18 >>>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- >>>>>> 02.txt >>>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-ram-siprec-callflows >>>>>> Htmlized: http://tools.ietf.org/html/draft-ram-siprec- >>>> callflows-02 >>>>>> Diff: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ram-siprec-callflows-02 >>>>>> >>>>>> Abstract: >>>>>> Session recording is a critical requirement in many >>>> communications >>>>>> environments such as call centers and financial trading. In >>>> some of >>>>>> these environments, all calls must be recorded for regulatory, >>>>>> compliance, and consumer protection reasons. Recording of a >>>> session >>>>>> is typically performed by sending a copy of a media stream to a >>>>>> recording device. This document lists call flows that has >>>> snapshot >>>>>> of metadata sent from SRC to SRS, the metadata format for which >>>> is >>>>>> described in [I-D.ietf-siprec-metadata] . This is purely an >>>>>> informational document that is written to support the model >>>> defined >>>>>> the metadata draft. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From eckelcu@cisco.com Wed Jan 2 14:15:55 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E9021F86AB for ; Wed, 2 Jan 2013 14:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.246 X-Spam-Level: X-Spam-Status: No, score=-10.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtEKnsmvKqPr for ; Wed, 2 Jan 2013 14:15:53 -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 A2EA221F8481 for ; Wed, 2 Jan 2013 14:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12741; q=dns/txt; s=iport; t=1357164948; x=1358374548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p/L/QL5RagM+j28ekb2FGSGXFJzq1xJxUR589PnClc8=; b=aWI1BpYu+hXcWON33Z0I/iHVJ87dQ9O3BGbeeFgAY7oUjWntZcvTtQ0V IEG+KFqa9a5L+jXsHzbJzTUWl6SfLL3w8v/S64Hhzr2ZNNKRIMedKb9y1 FuZJuisleKX/kKvEDjkW2iKbRhtZRiGH9WETTZfdO0ZVjTbvFyws/EyXc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAPWw5FCtJV2Z/2dsb2JhbAA7Cg6BcYFuuVYWc4IeAQEBBAEBATc0CQIMBAIBCA4DBAEBAQoUCQcnCxQIAQgCBA4FCAESh3cBBwW3MoxXEQqDR2EDlyiPLII2PoFxNQ X-IronPort-AV: E=Sophos;i="4.84,398,1355097600"; d="scan'208";a="158006860" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jan 2013 22:15:48 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r02MFlIO007637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 22:15:47 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 16:15:47 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat Thread-Topic: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt Thread-Index: AQHN6R62qX1P1erda0myXkHRwiZXB5g2lvNA Date: Wed, 2 Jan 2013 22:15:46 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046F3638@xmb-aln-x08.cisco.com> References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> <003201cdbd0e$2d5ca310$8815e930$@co.in> <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> <000001cde838$a76c7d10$f6457730$@co.in> <50E35B66.9080206@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046F3449@xmb-aln-x08.cisco.com> <50E48940.4030101@alum.mit.edu> In-Reply-To: <50E48940.4030101@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 22:15:55 -0000 I expect there to be cases in which an MCU, Turret, or something similar, a= ppears to a SRC as a single UA with media from multiple participants. In the worst case, all the media arrives at the SRC with the same, single S= SRC and there is no other signaling that informs the SRC of the individual = participants. In such cases, the SRC cannot do anything to help the SRS ide= ntify media from individual participants. In a slightly improved case, the SRC does receive some information from the= UA regarding the set of participants. In such cases, the SRC can make this= information available to the SRS via metadata. In an even better case, the media arrives at the SRC from the UA with a sep= arate SSRC for each participant. In such cases, the SRC can use CSRCs to di= sambiguate media streams received by the SRS. It seems to me that the case you are pointing out is one in which the SRC g= ets some information from a UA that it decides not to propagate to the SRS= . I agree that an SRS needs to support working with incomplete information = because it will be inevitable in some instances; however, the case in which= an SRC removes some information and one in which the UA did not provide an= y additional information to the SRC in the first place appear the same to t= he SRS. Therefore, I do not see a need to include the "permissible" clause = for the SRC. If anything, I think we need to point out that SRS should be p= repared to work with incomplete information when it comes to identification= of individual participants within a mixed media stream. Cheers, Charles =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, January 02, 2013 11:24 AM > To: Charles Eckel (eckelcu) > Cc: siprec@ietf.org > Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec- > callflows-02.txt >=20 > On 1/2/13 1:15 PM, Charles Eckel (eckelcu) wrote: > > I'm okay with listing this as a limitation as long as the limitation is= stated > as being due to the way media streams are constructed in the turret case = and > not due to SRC mixing of media streams in general. For the general case, = no > information present in the CS should be lost as a result of SRC mixing fo= r the > RS. >=20 > I was thinking that it is *permissible* (but not recommended) for an SRC > to do a very simplistic form of mixing - with just one SSRC and no CSRCs > - if it wishes. I think we should not exclude that, because doing so may > exclude some servers from being SRCs. >=20 > The turret might be one instance of that. >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >> Of Paul Kyzivat > >> Sent: Tuesday, January 01, 2013 1:56 PM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] FW: New Version Notification for draft-ram-sipre= c- > >> callflows-02.txt > >> > >> On 1/1/13 10:57 AM, Parthasarathi R wrote: > >>> Hi Charles, > >>> > >>> After a long time, I'm looking to this mail thread and understand tha= t > there > >>> is a non-closed item on metadata mixing representation. As per the > current > >>> model, SRC mixing will leads to the loss of data like "who is the cur= rent > >>> contributor of the mixed media". We have tried to use CSRC earlier an= d > not > >>> accepted as a generic solution. In case any other alternative exists = to > >>> solve this issue, Please let us know. > >> > >> On "solution" is just to acknowledge it as a limitation. > >> > >> Thanks, > >> Paul > >> > >>> Hope Turret case solution is clarified to you. > >>> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>> Sent: Wednesday, November 07, 2012 11:23 PM > >>>> To: Parthasarathi R; siprec@ietf.org > >>>> Subject: RE: [siprec] FW: New Version Notification for draft-ram- > >>>> siprec-callflows-02.txt > >>>> > >>>>> -----Original Message----- > >>>>> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > >>>>> Sent: Wednesday, November 07, 2012 12:35 PM > >>>>> To: Charles Eckel (eckelcu); siprec@ietf.org > >>>>> Subject: RE: [siprec] FW: New Version Notification for draft-ram- > >>>> siprec- > >>>>> callflows-02.txt > >>>>> > >>>>> Hi Charles, > >>>>> > >>>>> Thanks a lot for your review. Please read inline. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>> -----Original Message----- > >>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>>> Sent: Saturday, November 03, 2012 10:32 PM > >>>>> To: Parthasarathi R; siprec@ietf.org > >>>>> Subject: RE: [siprec] FW: New Version Notification for > >>>>> draft-ram-siprec-callflows-02.txt > >>>>> > >>>>> Hi draft authors, > >>>>> > >>>>> I read the draft and have a few comments to share. > >>>>> > >>>>> 1) abstract > >>>>> s/model defined the metadata draft/model defined in the metadata > >>>> draft > >>>>> > >>>>> 2) overview > >>>>> s/not normative on any aspect of SIP/not normative on any aspect of > >>>> SIPREC > >>>>> > >>>>> I'll updated in the next revision > >>>>> > >>>>> 3) Section 3.1 reads, "The following example provides all the tuple= s > >>>> ..." > >>>>> IMO, this sounds as if it provides an exhaustive list; however, I d= o > >>>> not > >>>>> think that is the intent. Rather, I think it provides an example of > >>>> metadata > >>>>> that may be included in a typical metadata body. It would be good t= o > >>>> be > >>>>> clean on the intent so that the example is read in the proper from = of > >>>> mind. > >>>>> > >>>>> Text will be updated to indicate the typical metadata body > >>>> in the > >>>>> next revision. > >>>>> > >>>>> 4) Section 3.1. It would be helpful to explain the call scenario to > >>>> which > >>>>> the metadata example applies. For example, it appears to be a two > >>>> party > >>>>> call with 4 streams per participant, 2 in each direction (e.g. one > >>>> for audio > >>>>> and one for video). Alternatively, you can remove this example as i= t > >>>> appears > >>>>> to be a duplicate of the next example (in section 4). > >>>>> Could you explain this comment as Section 4 is security > >>>>> consideration in -02 draft. My guess is that your comment is based = on > >>>> -01 > >>>>> draft. > >>>> > >>>> Yes, you are correct. Sorry about that. And yes, the way the -02 dra= fts > >>>> addresses it works for me. > >>>> > >>>>> 5) Section 4.2 > >>>>> s/Media Streams sent by each participant is received all/Media > >>>> streams sent > >>>>> by each participant are received by the > >>>>> s/snippets of SDP is shown/snippets of SDP are shown > >>>>> > >>>>> 6) Section 4.3, example 2, it would be better if you remain > >>>> consistent with > >>>>> the participant names (i.e. A/B or Ram/Partha. > >>>>> > >>>>> 7) F4, it would be helpful to explain the inactive and sendonly SDP > >>>>> attributes by adding text explaining that during the hold, A stops > >>>> sending > >>>>> streams (inactive), while B continues sending (sendonly). > >>>>> > >>>>> 5, 6, 7 comments will be incorporated in the next revision > >>>>> > >>>>> > >>>>> 8) Section 4.4, metadata > >>>>> Is the idea that the streams remain the same and only the participa= nt > >>>>> changes? If so, state that. It is hard to tell by visual inspection > >>>> whether > >>>>> the stream id is an exact match of perhaps has some small change. > >>>> Also, I > >>>>> was expecting to see metadata saying the Ram left and providing a > >>>>> disassociation time. Instead, this is provided only the end of the > >>>> call. Is > >>>>> that done just in case Ram returns before the end of the call. In a= ny > >>>> case, > >>>>> it would be good to state the reasoning so that it is clear why the > >>>> metadata > >>>>> is as it is. > >>>>> > >>>>> 9) Section 4.6, F1 > >>>>> Why does stream =3D=3D stream? > >>>>> > >>>>> Because it is mixed stream. There is no way to distinguish > >>>> the > >>>>> directionality of the individual participants. > >>>>> > >>>>> Also, how do you indicate when each person is talking? > >>>>> It is possible that the information may be lost at SRC > >>>> itself > >>>>> > >>>> > >>>> This is troubling to me, but perhaps I am the only one that cares. I > >>>> also tend to think I do not understand the turret case well enough a= t > >>>> this point. Maybe someone here at IETF 85 this week can set me > >>>> straight. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> Is it accomplished using CNAME and SSRC? > >>>>> I'm not sure whether CNAME & SSRC will help for mixed > stream > >>>>> > >>>>> > >>>>> Cheers, > >>>>> Charles > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf > >>>>>> Of Parthasarathi R > >>>>>> Sent: Monday, October 22, 2012 1:56 PM > >>>>>> To: siprec@ietf.org > >>>>>> Subject: [siprec] FW: New Version Notification for draft-ram- > >>>> siprec- > >>>>>> callflows-02.txt > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> draft-ram-siprec-callflows-02 is published with the following > >>>> update: > >>>>>> > >>>>>> 1) Updated the callflow as per draft-ietf-siprec-metadata-08 > >>>>>> 2) Removed Metadata Example section > >>>>>> 3) Incorporated Ofir Rath review comments > >>>>>> > >>>>>> The current open issue in the drafts > >>>>>> 1) Incorporating RS SIP messages with metadata XML messages for > all > >>>>>> callflow > >>>>>> 2) Callflows provided by Ofir Rath has to be discussed and added. > >>>>>> > >>>>>> Could you please provide your valuable comments on > >>>>>> draft-ram-siprec-callflows-02. > >>>>>> > >>>>>> Thanks > >>>>>> Partha > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>>>>> Sent: Monday, October 22, 2012 11:02 PM > >>>>>> To: partha@parthasarathi.co.in > >>>>>> Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu > >>>>>> Subject: New Version Notification for draft-ram-siprec-callflows- > >>>> 02.txt > >>>>>> > >>>>>> > >>>>>> A new version of I-D, draft-ram-siprec-callflows-02.txt > >>>>>> has been successfully submitted by Parthasarathi Ravindran and > >>>> posted to > >>>>>> the > >>>>>> IETF repository. > >>>>>> > >>>>>> Filename: draft-ram-siprec-callflows > >>>>>> Revision: 02 > >>>>>> Title: Session Initiation Protocol (SIP) Recording Call > >>>>> Flows > >>>>>> Creation date: 2012-10-22 > >>>>>> WG ID: Individual Submission > >>>>>> Number of pages: 18 > >>>>>> URL: > >>>>> http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- > >>>>>> 02.txt > >>>>>> Status: > >>>>> http://datatracker.ietf.org/doc/draft-ram-siprec-callflows > >>>>>> Htmlized: http://tools.ietf.org/html/draft-ram-siprec- > >>>> callflows-02 > >>>>>> Diff: > >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-callflows-02 > >>>>>> > >>>>>> Abstract: > >>>>>> Session recording is a critical requirement in many > >>>> communications > >>>>>> environments such as call centers and financial trading. In > >>>> some of > >>>>>> these environments, all calls must be recorded for regulatory= , > >>>>>> compliance, and consumer protection reasons. Recording of a > >>>> session > >>>>>> is typically performed by sending a copy of a media stream to= a > >>>>>> recording device. This document lists call flows that has > >>>> snapshot > >>>>>> of metadata sent from SRC to SRS, the metadata format for whi= ch > >>>> is > >>>>>> described in [I-D.ietf-siprec-metadata] . This is purely an > >>>>>> informational document that is written to support the model > >>>> defined > >>>>>> the metadata draft. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The IETF Secretariat > >>>>>> > >>>>>> _______________________________________________ > >>>>>> siprec mailing list > >>>>>> siprec@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > From partha@parthasarathi.co.in Thu Jan 3 09:12:32 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E20221F8BBB for ; Thu, 3 Jan 2013 09:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.451 X-Spam-Level: * X-Spam-Status: No, score=1.451 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=1.117] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8ZyNx6ubpCr for ; Thu, 3 Jan 2013 09:12:28 -0800 (PST) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.235]) by ietfa.amsl.com (Postfix) with ESMTP id 53B4221F8BB9 for ; Thu, 3 Jan 2013 09:12:24 -0800 (PST) Received: from userPC (unknown [122.179.46.236]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 63F423E2640; Thu, 3 Jan 2013 17:12:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1357233144; bh=cfWGZWsktglMXBC8sUqsFgNevCf98drfAQeneWw8Quk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=AQUpQRvNcq8fKKWdqsHA99KkBJJoOOQPkU8WAeHCYMmKTMLmykqNOaLiU4Zg3plbr LUk91HEzJR1Am/PFnMABfYkOT8hAQrscmHNuyWdaXmURK9yTRuH9moFzzwnVcvaYXk QgRiex/N9NtY27IrmyXVE9SJbVaV+hwhsc9OIWqc= From: "Parthasarathi R" To: "'Charles Eckel \(eckelcu\)'" , "'Paul Kyzivat'" References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> <003201cdbd0e$2d5ca310$8815e930$@co.in> <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> <000001cde838$a76c7d10$f6457730$@co.in> <50E35B66.9080206@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046F3449@xmb-aln-x08.cisco.com> <50E48940.4030101@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046F3638@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046F3638@xmb-aln-x08.cisco.com> Date: Thu, 3 Jan 2013 22:42:14 +0530 Message-ID: <004801cde9d5$7cd56c80$76804580$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHN6R62qX1P1erda0myXkHRwiZXB5g2lvNAgAE+yMA= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0204.50E5BBF8.00BD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: siprec@ietf.org Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jan 2013 17:12:32 -0000 Hi Charles, I have looked in RFC 3550 for CSRC requirements and it is as follows: "In order to preserve the identity of the original sources contributing to the mixed packet, the mixer SHOULD insert their SSRC identifiers into the CSRC identifier list following the fixed RTP header of the packet." My observation is that adding CSRC identifier is "SHOULD" and not "MUST". I really don't know in which scenario it is permissible not to add CSRC identifier but it is allowed. In case you foresee that CSRC identifier MUST be inserted by all SRC mixer, then the normative statement in CSRC section of SIPREC protocol draft has to be changed as "MUST" instead of "RECOMMENDED". Also still I could not see how to correlate the participant to CSRC in SRS as there is no linkage between CSRC in RTP & participant in SIPREC metadata from SRC. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Thursday, January 03, 2013 3:46 AM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] FW: New Version Notification for draft-ram- > siprec-callflows-02.txt > > I expect there to be cases in which an MCU, Turret, or something > similar, appears to a SRC as a single UA with media from multiple > participants. > In the worst case, all the media arrives at the SRC with the same, > single SSRC and there is no other signaling that informs the SRC of the > individual participants. In such cases, the SRC cannot do anything to > help the SRS identify media from individual participants. > In a slightly improved case, the SRC does receive some information from > the UA regarding the set of participants. In such cases, the SRC can > make this information available to the SRS via metadata. > In an even better case, the media arrives at the SRC from the UA with a > separate SSRC for each participant. In such cases, the SRC can use > CSRCs to disambiguate media streams received by the SRS. > > It seems to me that the case you are pointing out is one in which the > SRC gets some information from a UA that it decides not to propagate > to the SRS. I agree that an SRS needs to support working with > incomplete information because it will be inevitable in some instances; > however, the case in which an SRC removes some information and one in > which the UA did not provide any additional information to the SRC in > the first place appear the same to the SRS. Therefore, I do not see a > need to include the "permissible" clause for the SRC. If anything, I > think we need to point out that SRS should be prepared to work with > incomplete information when it comes to identification of individual > participants within a mixed media stream. > > Cheers, > Charles > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Wednesday, January 02, 2013 11:24 AM > > To: Charles Eckel (eckelcu) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] FW: New Version Notification for draft-ram- > siprec- > > callflows-02.txt > > > > On 1/2/13 1:15 PM, Charles Eckel (eckelcu) wrote: > > > I'm okay with listing this as a limitation as long as the > limitation is stated > > as being due to the way media streams are constructed in the turret > case and > > not due to SRC mixing of media streams in general. For the general > case, no > > information present in the CS should be lost as a result of SRC > mixing for the > > RS. > > > > I was thinking that it is *permissible* (but not recommended) for an > SRC > > to do a very simplistic form of mixing - with just one SSRC and no > CSRCs > > - if it wishes. I think we should not exclude that, because doing so > may > > exclude some servers from being SRCs. > > > > The turret might be one instance of that. > > > > Thanks, > > Paul > > > > > Cheers, > > > Charles > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > > >> Of Paul Kyzivat > > >> Sent: Tuesday, January 01, 2013 1:56 PM > > >> To: siprec@ietf.org > > >> Subject: Re: [siprec] FW: New Version Notification for draft-ram- > siprec- > > >> callflows-02.txt > > >> > > >> On 1/1/13 10:57 AM, Parthasarathi R wrote: > > >>> Hi Charles, > > >>> > > >>> After a long time, I'm looking to this mail thread and understand > that > > there > > >>> is a non-closed item on metadata mixing representation. As per > the > > current > > >>> model, SRC mixing will leads to the loss of data like "who is the > current > > >>> contributor of the mixed media". We have tried to use CSRC > earlier and > > not > > >>> accepted as a generic solution. In case any other alternative > exists to > > >>> solve this issue, Please let us know. > > >> > > >> On "solution" is just to acknowledge it as a limitation. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Hope Turret case solution is clarified to you. > > >>> > > >>> Thanks > > >>> Partha > > >>> > > >>>> -----Original Message----- > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >>>> Sent: Wednesday, November 07, 2012 11:23 PM > > >>>> To: Parthasarathi R; siprec@ietf.org > > >>>> Subject: RE: [siprec] FW: New Version Notification for draft- > ram- > > >>>> siprec-callflows-02.txt > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > > >>>>> Sent: Wednesday, November 07, 2012 12:35 PM > > >>>>> To: Charles Eckel (eckelcu); siprec@ietf.org > > >>>>> Subject: RE: [siprec] FW: New Version Notification for draft- > ram- > > >>>> siprec- > > >>>>> callflows-02.txt > > >>>>> > > >>>>> Hi Charles, > > >>>>> > > >>>>> Thanks a lot for your review. Please read inline. > > >>>>> > > >>>>> Thanks > > >>>>> Partha > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >>>>> Sent: Saturday, November 03, 2012 10:32 PM > > >>>>> To: Parthasarathi R; siprec@ietf.org > > >>>>> Subject: RE: [siprec] FW: New Version Notification for > > >>>>> draft-ram-siprec-callflows-02.txt > > >>>>> > > >>>>> Hi draft authors, > > >>>>> > > >>>>> I read the draft and have a few comments to share. > > >>>>> > > >>>>> 1) abstract > > >>>>> s/model defined the metadata draft/model defined in the > metadata > > >>>> draft > > >>>>> > > >>>>> 2) overview > > >>>>> s/not normative on any aspect of SIP/not normative on any > aspect of > > >>>> SIPREC > > >>>>> > > >>>>> I'll updated in the next revision > > >>>>> > > >>>>> 3) Section 3.1 reads, "The following example provides all the > tuples > > >>>> ..." > > >>>>> IMO, this sounds as if it provides an exhaustive list; however, > I do > > >>>> not > > >>>>> think that is the intent. Rather, I think it provides an > example of > > >>>> metadata > > >>>>> that may be included in a typical metadata body. It would be > good to > > >>>> be > > >>>>> clean on the intent so that the example is read in the proper > from of > > >>>> mind. > > >>>>> > > >>>>> Text will be updated to indicate the typical metadata > body > > >>>> in the > > >>>>> next revision. > > >>>>> > > >>>>> 4) Section 3.1. It would be helpful to explain the call > scenario to > > >>>> which > > >>>>> the metadata example applies. For example, it appears to be a > two > > >>>> party > > >>>>> call with 4 streams per participant, 2 in each direction (e.g. > one > > >>>> for audio > > >>>>> and one for video). Alternatively, you can remove this example > as it > > >>>> appears > > >>>>> to be a duplicate of the next example (in section 4). > > >>>>> Could you explain this comment as Section 4 is > security > > >>>>> consideration in -02 draft. My guess is that your comment is > based on > > >>>> -01 > > >>>>> draft. > > >>>> > > >>>> Yes, you are correct. Sorry about that. And yes, the way the -02 > drafts > > >>>> addresses it works for me. > > >>>> > > >>>>> 5) Section 4.2 > > >>>>> s/Media Streams sent by each participant is received all/Media > > >>>> streams sent > > >>>>> by each participant are received by the > > >>>>> s/snippets of SDP is shown/snippets of SDP are shown > > >>>>> > > >>>>> 6) Section 4.3, example 2, it would be better if you remain > > >>>> consistent with > > >>>>> the participant names (i.e. A/B or Ram/Partha. > > >>>>> > > >>>>> 7) F4, it would be helpful to explain the inactive and sendonly > SDP > > >>>>> attributes by adding text explaining that during the hold, A > stops > > >>>> sending > > >>>>> streams (inactive), while B continues sending (sendonly). > > >>>>> > > >>>>> 5, 6, 7 comments will be incorporated in the next > revision > > >>>>> > > >>>>> > > >>>>> 8) Section 4.4, metadata > > >>>>> Is the idea that the streams remain the same and only the > participant > > >>>>> changes? If so, state that. It is hard to tell by visual > inspection > > >>>> whether > > >>>>> the stream id is an exact match of perhaps has some small > change. > > >>>> Also, I > > >>>>> was expecting to see metadata saying the Ram left and providing > a > > >>>>> disassociation time. Instead, this is provided only the end of > the > > >>>> call. Is > > >>>>> that done just in case Ram returns before the end of the call. > In any > > >>>> case, > > >>>>> it would be good to state the reasoning so that it is clear why > the > > >>>> metadata > > >>>>> is as it is. > > >>>>> > > >>>>> 9) Section 4.6, F1 > > >>>>> Why does stream == stream? > > >>>>> > > >>>>> Because it is mixed stream. There is no way to > distinguish > > >>>> the > > >>>>> directionality of the individual participants. > > >>>>> > > >>>>> Also, how do you indicate when each person is talking? > > >>>>> It is possible that the information may be lost at SRC > > >>>> itself > > >>>>> > > >>>> > > >>>> This is troubling to me, but perhaps I am the only one that > cares. I > > >>>> also tend to think I do not understand the turret case well > enough at > > >>>> this point. Maybe someone here at IETF 85 this week can set me > > >>>> straight. > > >>>> > > >>>> Cheers, > > >>>> Charles > > >>>> > > >>>>> Is it accomplished using CNAME and SSRC? > > >>>>> I'm not sure whether CNAME & SSRC will help for mixed > > stream > > >>>>> > > >>>>> > > >>>>> Cheers, > > >>>>> Charles > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > >>>>> Behalf > > >>>>>> Of Parthasarathi R > > >>>>>> Sent: Monday, October 22, 2012 1:56 PM > > >>>>>> To: siprec@ietf.org > > >>>>>> Subject: [siprec] FW: New Version Notification for draft-ram- > > >>>> siprec- > > >>>>>> callflows-02.txt > > >>>>>> > > >>>>>> Hi all, > > >>>>>> > > >>>>>> draft-ram-siprec-callflows-02 is published with the following > > >>>> update: > > >>>>>> > > >>>>>> 1) Updated the callflow as per draft-ietf-siprec-metadata-08 > > >>>>>> 2) Removed Metadata Example section > > >>>>>> 3) Incorporated Ofir Rath review comments > > >>>>>> > > >>>>>> The current open issue in the drafts > > >>>>>> 1) Incorporating RS SIP messages with metadata XML messages > for > > all > > >>>>>> callflow > > >>>>>> 2) Callflows provided by Ofir Rath has to be discussed and > added. > > >>>>>> > > >>>>>> Could you please provide your valuable comments on > > >>>>>> draft-ram-siprec-callflows-02. > > >>>>>> > > >>>>>> Thanks > > >>>>>> Partha > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: internet-drafts@ietf.org [mailto:internet- > drafts@ietf.org] > > >>>>>> Sent: Monday, October 22, 2012 11:02 PM > > >>>>>> To: partha@parthasarathi.co.in > > >>>>>> Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu > > >>>>>> Subject: New Version Notification for draft-ram-siprec- > callflows- > > >>>> 02.txt > > >>>>>> > > >>>>>> > > >>>>>> A new version of I-D, draft-ram-siprec-callflows-02.txt > > >>>>>> has been successfully submitted by Parthasarathi Ravindran and > > >>>> posted to > > >>>>>> the > > >>>>>> IETF repository. > > >>>>>> > > >>>>>> Filename: draft-ram-siprec-callflows > > >>>>>> Revision: 02 > > >>>>>> Title: Session Initiation Protocol (SIP) Recording > Call > > >>>>> Flows > > >>>>>> Creation date: 2012-10-22 > > >>>>>> WG ID: Individual Submission > > >>>>>> Number of pages: 18 > > >>>>>> URL: > > >>>>> http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- > > >>>>>> 02.txt > > >>>>>> Status: > > >>>>> http://datatracker.ietf.org/doc/draft-ram-siprec-callflows > > >>>>>> Htmlized: http://tools.ietf.org/html/draft-ram-siprec- > > >>>> callflows-02 > > >>>>>> Diff: > > >>>>> http://www.ietf.org/rfcdiff?url2=draft-ram-siprec-callflows-02 > > >>>>>> > > >>>>>> Abstract: > > >>>>>> Session recording is a critical requirement in many > > >>>> communications > > >>>>>> environments such as call centers and financial trading. > In > > >>>> some of > > >>>>>> these environments, all calls must be recorded for > regulatory, > > >>>>>> compliance, and consumer protection reasons. Recording > of a > > >>>> session > > >>>>>> is typically performed by sending a copy of a media > stream to a > > >>>>>> recording device. This document lists call flows that > has > > >>>> snapshot > > >>>>>> of metadata sent from SRC to SRS, the metadata format for > which > > >>>> is > > >>>>>> described in [I-D.ietf-siprec-metadata] . This is purely > an > > >>>>>> informational document that is written to support the > model > > >>>> defined > > >>>>>> the metadata draft. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> The IETF Secretariat > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> siprec mailing list > > >>>>>> siprec@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>> > > >>> _______________________________________________ > > >>> siprec mailing list > > >>> siprec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/siprec > > >>> > > >> > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Thu Jan 3 09:46:11 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EB421F8AA6 for ; Thu, 3 Jan 2013 09:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6L6gTRhQc6F for ; Thu, 3 Jan 2013 09:46:07 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFB521F8A6C for ; Thu, 3 Jan 2013 09:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16389; q=dns/txt; s=iport; t=1357235166; x=1358444766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TdND6+vg0YnaRex7VpQd6y76raSr5LVqI1AhbZU9sD4=; b=eDuUwn5IWWszKHWmwLUT0zQTSca7F6WWv5GVCsRYDd6zcLPyQuJGSs19 dObDX8CZdgUND0gnjwZ2adir8i2NWuX2wzybfbhZ2x/hOuX1ARiaT5666 v9EFkQyeyCTaNRBXlbEb+39m4QPP6uOu7xUzd4SfoprPo8lOXEH7s3M+W o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGzD5VCtJV2c/2dsb2JhbAA7AQkOgXGBb7lkFnOCHgEBAQMBAQEBNzQJAgUHBAIBCBEEAQEBChQJBycLFAgBCAIEAQ0DAggBEodyBQEHBbVujFcRAQmDR2EDklmET48sgjY+QYEwNQ X-IronPort-AV: E=Sophos;i="4.84,404,1355097600"; d="scan'208";a="158529021" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jan 2013 17:45:57 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r03Hjvbf013553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jan 2013 17:45:57 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 11:45:56 -0600 From: "Charles Eckel (eckelcu)" To: Parthasarathi R , "'Paul Kyzivat'" Thread-Topic: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt Thread-Index: AQHN6R62qX1P1erda0myXkHRwiZXB5g2lvNAgAE+yMCAAAtCYA== Date: Thu, 3 Jan 2013 17:45:56 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046F3B12@xmb-aln-x08.cisco.com> References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> <003201cdbd0e$2d5ca310$8815e930$@co.in> <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> <000001cde838$a76c7d10$f6457730$@co.in> <50E35B66.9080206@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046F3449@xmb-aln-x08.cisco.com> <50E48940.4030101@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046F3638@xmb-aln-x08.cisco.com> <004801cde9d5$7cd56c80$76804580$@co.in> In-Reply-To: <004801cde9d5$7cd56c80$76804580$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jan 2013 17:46:11 -0000 Hi Partha, Please see inline. > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: Thursday, January 03, 2013 9:12 AM > To: Charles Eckel (eckelcu); 'Paul Kyzivat' > Cc: siprec@ietf.org > Subject: RE: [siprec] FW: New Version Notification for draft-ram-siprec- > callflows-02.txt >=20 > Hi Charles, >=20 > I have looked in RFC 3550 for CSRC requirements and it is as follows: >=20 > "In order to preserve the identity of the original sources > contributing to the mixed packet, the mixer SHOULD insert their > SSRC identifiers into the CSRC identifier list following the fixed > RTP header of the packet." >=20 > My observation is that adding CSRC identifier is "SHOULD" and not "MUST".= I > really don't know in which scenario it is permissible not to add CSRC > identifier but it is allowed. In case you foresee that CSRC identifier MU= ST > be inserted by all SRC mixer, then the normative statement in CSRC sectio= n > of SIPREC protocol draft has to be changed as "MUST" instead of > "RECOMMENDED". I am not proposing to change it to a MUST. I think RECOMMENDED is appropria= te, along with the explanation of why support for CSRC is important. =20 > Also still I could not see how to correlate the participant to CSRC in SR= S > as there is no linkage between CSRC in RTP & participant in SIPREC metada= ta > from SRC. Forwarding the SDES/CNAME information from the CS into the RS provides this= . I also have recommended previously that we include the CNAME of a partici= pant in the metadata.=20 Cheers, Charles > Thanks > Partha >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Thursday, January 03, 2013 3:46 AM > > To: Paul Kyzivat > > Cc: siprec@ietf.org > > Subject: Re: [siprec] FW: New Version Notification for draft-ram- > > siprec-callflows-02.txt > > > > I expect there to be cases in which an MCU, Turret, or something > > similar, appears to a SRC as a single UA with media from multiple > > participants. > > In the worst case, all the media arrives at the SRC with the same, > > single SSRC and there is no other signaling that informs the SRC of the > > individual participants. In such cases, the SRC cannot do anything to > > help the SRS identify media from individual participants. > > In a slightly improved case, the SRC does receive some information from > > the UA regarding the set of participants. In such cases, the SRC can > > make this information available to the SRS via metadata. > > In an even better case, the media arrives at the SRC from the UA with a > > separate SSRC for each participant. In such cases, the SRC can use > > CSRCs to disambiguate media streams received by the SRS. > > > > It seems to me that the case you are pointing out is one in which the > > SRC gets some information from a UA that it decides not to propagate > > to the SRS. I agree that an SRS needs to support working with > > incomplete information because it will be inevitable in some instances; > > however, the case in which an SRC removes some information and one in > > which the UA did not provide any additional information to the SRC in > > the first place appear the same to the SRS. Therefore, I do not see a > > need to include the "permissible" clause for the SRC. If anything, I > > think we need to point out that SRS should be prepared to work with > > incomplete information when it comes to identification of individual > > participants within a mixed media stream. > > > > Cheers, > > Charles > > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > > Sent: Wednesday, January 02, 2013 11:24 AM > > > To: Charles Eckel (eckelcu) > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] FW: New Version Notification for draft-ram- > > siprec- > > > callflows-02.txt > > > > > > On 1/2/13 1:15 PM, Charles Eckel (eckelcu) wrote: > > > > I'm okay with listing this as a limitation as long as the > > limitation is stated > > > as being due to the way media streams are constructed in the turret > > case and > > > not due to SRC mixing of media streams in general. For the general > > case, no > > > information present in the CS should be lost as a result of SRC > > mixing for the > > > RS. > > > > > > I was thinking that it is *permissible* (but not recommended) for an > > SRC > > > to do a very simplistic form of mixing - with just one SSRC and no > > CSRCs > > > - if it wishes. I think we should not exclude that, because doing so > > may > > > exclude some servers from being SRCs. > > > > > > The turret might be one instance of that. > > > > > > Thanks, > > > Paul > > > > > > > Cheers, > > > > Charles > > > > > > > >> -----Original Message----- > > > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf > > > >> Of Paul Kyzivat > > > >> Sent: Tuesday, January 01, 2013 1:56 PM > > > >> To: siprec@ietf.org > > > >> Subject: Re: [siprec] FW: New Version Notification for draft-ram- > > siprec- > > > >> callflows-02.txt > > > >> > > > >> On 1/1/13 10:57 AM, Parthasarathi R wrote: > > > >>> Hi Charles, > > > >>> > > > >>> After a long time, I'm looking to this mail thread and understand > > that > > > there > > > >>> is a non-closed item on metadata mixing representation. As per > > the > > > current > > > >>> model, SRC mixing will leads to the loss of data like "who is the > > current > > > >>> contributor of the mixed media". We have tried to use CSRC > > earlier and > > > not > > > >>> accepted as a generic solution. In case any other alternative > > exists to > > > >>> solve this issue, Please let us know. > > > >> > > > >> On "solution" is just to acknowledge it as a limitation. > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >>> Hope Turret case solution is clarified to you. > > > >>> > > > >>> Thanks > > > >>> Partha > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >>>> Sent: Wednesday, November 07, 2012 11:23 PM > > > >>>> To: Parthasarathi R; siprec@ietf.org > > > >>>> Subject: RE: [siprec] FW: New Version Notification for draft- > > ram- > > > >>>> siprec-callflows-02.txt > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > > > >>>>> Sent: Wednesday, November 07, 2012 12:35 PM > > > >>>>> To: Charles Eckel (eckelcu); siprec@ietf.org > > > >>>>> Subject: RE: [siprec] FW: New Version Notification for draft- > > ram- > > > >>>> siprec- > > > >>>>> callflows-02.txt > > > >>>>> > > > >>>>> Hi Charles, > > > >>>>> > > > >>>>> Thanks a lot for your review. Please read inline. > > > >>>>> > > > >>>>> Thanks > > > >>>>> Partha > > > >>>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >>>>> Sent: Saturday, November 03, 2012 10:32 PM > > > >>>>> To: Parthasarathi R; siprec@ietf.org > > > >>>>> Subject: RE: [siprec] FW: New Version Notification for > > > >>>>> draft-ram-siprec-callflows-02.txt > > > >>>>> > > > >>>>> Hi draft authors, > > > >>>>> > > > >>>>> I read the draft and have a few comments to share. > > > >>>>> > > > >>>>> 1) abstract > > > >>>>> s/model defined the metadata draft/model defined in the > > metadata > > > >>>> draft > > > >>>>> > > > >>>>> 2) overview > > > >>>>> s/not normative on any aspect of SIP/not normative on any > > aspect of > > > >>>> SIPREC > > > >>>>> > > > >>>>> I'll updated in the next revision > > > >>>>> > > > >>>>> 3) Section 3.1 reads, "The following example provides all the > > tuples > > > >>>> ..." > > > >>>>> IMO, this sounds as if it provides an exhaustive list; however, > > I do > > > >>>> not > > > >>>>> think that is the intent. Rather, I think it provides an > > example of > > > >>>> metadata > > > >>>>> that may be included in a typical metadata body. It would be > > good to > > > >>>> be > > > >>>>> clean on the intent so that the example is read in the proper > > from of > > > >>>> mind. > > > >>>>> > > > >>>>> Text will be updated to indicate the typical metadata > > body > > > >>>> in the > > > >>>>> next revision. > > > >>>>> > > > >>>>> 4) Section 3.1. It would be helpful to explain the call > > scenario to > > > >>>> which > > > >>>>> the metadata example applies. For example, it appears to be a > > two > > > >>>> party > > > >>>>> call with 4 streams per participant, 2 in each direction (e.g. > > one > > > >>>> for audio > > > >>>>> and one for video). Alternatively, you can remove this example > > as it > > > >>>> appears > > > >>>>> to be a duplicate of the next example (in section 4). > > > >>>>> Could you explain this comment as Section 4 is > > security > > > >>>>> consideration in -02 draft. My guess is that your comment is > > based on > > > >>>> -01 > > > >>>>> draft. > > > >>>> > > > >>>> Yes, you are correct. Sorry about that. And yes, the way the -02 > > drafts > > > >>>> addresses it works for me. > > > >>>> > > > >>>>> 5) Section 4.2 > > > >>>>> s/Media Streams sent by each participant is received all/Media > > > >>>> streams sent > > > >>>>> by each participant are received by the > > > >>>>> s/snippets of SDP is shown/snippets of SDP are shown > > > >>>>> > > > >>>>> 6) Section 4.3, example 2, it would be better if you remain > > > >>>> consistent with > > > >>>>> the participant names (i.e. A/B or Ram/Partha. > > > >>>>> > > > >>>>> 7) F4, it would be helpful to explain the inactive and sendonly > > SDP > > > >>>>> attributes by adding text explaining that during the hold, A > > stops > > > >>>> sending > > > >>>>> streams (inactive), while B continues sending (sendonly). > > > >>>>> > > > >>>>> 5, 6, 7 comments will be incorporated in the next > > revision > > > >>>>> > > > >>>>> > > > >>>>> 8) Section 4.4, metadata > > > >>>>> Is the idea that the streams remain the same and only the > > participant > > > >>>>> changes? If so, state that. It is hard to tell by visual > > inspection > > > >>>> whether > > > >>>>> the stream id is an exact match of perhaps has some small > > change. > > > >>>> Also, I > > > >>>>> was expecting to see metadata saying the Ram left and providing > > a > > > >>>>> disassociation time. Instead, this is provided only the end of > > the > > > >>>> call. Is > > > >>>>> that done just in case Ram returns before the end of the call. > > In any > > > >>>> case, > > > >>>>> it would be good to state the reasoning so that it is clear why > > the > > > >>>> metadata > > > >>>>> is as it is. > > > >>>>> > > > >>>>> 9) Section 4.6, F1 > > > >>>>> Why does stream =3D=3D stream? > > > >>>>> > > > >>>>> Because it is mixed stream. There is no way to > > distinguish > > > >>>> the > > > >>>>> directionality of the individual participants. > > > >>>>> > > > >>>>> Also, how do you indicate when each person is talking? > > > >>>>> It is possible that the information may be lost at SRC > > > >>>> itself > > > >>>>> > > > >>>> > > > >>>> This is troubling to me, but perhaps I am the only one that > > cares. I > > > >>>> also tend to think I do not understand the turret case well > > enough at > > > >>>> this point. Maybe someone here at IETF 85 this week can set me > > > >>>> straight. > > > >>>> > > > >>>> Cheers, > > > >>>> Charles > > > >>>> > > > >>>>> Is it accomplished using CNAME and SSRC? > > > >>>>> I'm not sure whether CNAME & SSRC will help for mixed > > > stream > > > >>>>> > > > >>>>> > > > >>>>> Cheers, > > > >>>>> Charles > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > > On > > > >>>>> Behalf > > > >>>>>> Of Parthasarathi R > > > >>>>>> Sent: Monday, October 22, 2012 1:56 PM > > > >>>>>> To: siprec@ietf.org > > > >>>>>> Subject: [siprec] FW: New Version Notification for draft-ram- > > > >>>> siprec- > > > >>>>>> callflows-02.txt > > > >>>>>> > > > >>>>>> Hi all, > > > >>>>>> > > > >>>>>> draft-ram-siprec-callflows-02 is published with the following > > > >>>> update: > > > >>>>>> > > > >>>>>> 1) Updated the callflow as per draft-ietf-siprec-metadata-08 > > > >>>>>> 2) Removed Metadata Example section > > > >>>>>> 3) Incorporated Ofir Rath review comments > > > >>>>>> > > > >>>>>> The current open issue in the drafts > > > >>>>>> 1) Incorporating RS SIP messages with metadata XML messages > > for > > > all > > > >>>>>> callflow > > > >>>>>> 2) Callflows provided by Ofir Rath has to be discussed and > > added. > > > >>>>>> > > > >>>>>> Could you please provide your valuable comments on > > > >>>>>> draft-ram-siprec-callflows-02. > > > >>>>>> > > > >>>>>> Thanks > > > >>>>>> Partha > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: internet-drafts@ietf.org [mailto:internet- > > drafts@ietf.org] > > > >>>>>> Sent: Monday, October 22, 2012 11:02 PM > > > >>>>>> To: partha@parthasarathi.co.in > > > >>>>>> Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu > > > >>>>>> Subject: New Version Notification for draft-ram-siprec- > > callflows- > > > >>>> 02.txt > > > >>>>>> > > > >>>>>> > > > >>>>>> A new version of I-D, draft-ram-siprec-callflows-02.txt > > > >>>>>> has been successfully submitted by Parthasarathi Ravindran and > > > >>>> posted to > > > >>>>>> the > > > >>>>>> IETF repository. > > > >>>>>> > > > >>>>>> Filename: draft-ram-siprec-callflows > > > >>>>>> Revision: 02 > > > >>>>>> Title: Session Initiation Protocol (SIP) Recording > > Call > > > >>>>> Flows > > > >>>>>> Creation date: 2012-10-22 > > > >>>>>> WG ID: Individual Submission > > > >>>>>> Number of pages: 18 > > > >>>>>> URL: > > > >>>>> http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- > > > >>>>>> 02.txt > > > >>>>>> Status: > > > >>>>> http://datatracker.ietf.org/doc/draft-ram-siprec-callflows > > > >>>>>> Htmlized: http://tools.ietf.org/html/draft-ram-siprec- > > > >>>> callflows-02 > > > >>>>>> Diff: > > > >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-callflows-0= 2 > > > >>>>>> > > > >>>>>> Abstract: > > > >>>>>> Session recording is a critical requirement in many > > > >>>> communications > > > >>>>>> environments such as call centers and financial trading. > > In > > > >>>> some of > > > >>>>>> these environments, all calls must be recorded for > > regulatory, > > > >>>>>> compliance, and consumer protection reasons. Recording > > of a > > > >>>> session > > > >>>>>> is typically performed by sending a copy of a media > > stream to a > > > >>>>>> recording device. This document lists call flows that > > has > > > >>>> snapshot > > > >>>>>> of metadata sent from SRC to SRS, the metadata format for > > which > > > >>>> is > > > >>>>>> described in [I-D.ietf-siprec-metadata] . This is purely > > an > > > >>>>>> informational document that is written to support the > > model > > > >>>> defined > > > >>>>>> the metadata draft. > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> The IETF Secretariat > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> siprec mailing list > > > >>>>>> siprec@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > >>> > > > >>> _______________________________________________ > > > >>> siprec mailing list > > > >>> siprec@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/siprec > > > >>> > > > >> > > > >> _______________________________________________ > > > >> siprec mailing list > > > >> siprec@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Jan 8 10:29:55 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B754611E80A5 for ; Tue, 8 Jan 2013 10:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS07WkgzECMg for ; Tue, 8 Jan 2013 10:29:55 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC8F1F0C6A for ; Tue, 8 Jan 2013 10:29:55 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 89CF223F048E for ; Tue, 8 Jan 2013 19:29:53 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 8 Jan 2013 19:29:53 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Metadata draft - Communication Session Participants. Thread-Index: Ac3tziX8BqWopky1Th28vJxwgai2lA== Date: Tue, 8 Jan 2013 18:29:52 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013A4E01@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Metadata draft - Communication Session Participants. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 18:29:55 -0000 Hi, Just reading through draft-ietf-siprec-metadata-10 and I noticed that secti= on 6.3.2 which related to CS linkages states "CS to have atleast zero or mo= re participants" and I am not sure I understand this. The architecture draft defines a CS as "A session created between two or mo= re SIP User Agents (UAs) that is the subject of recording"=20 I can imagine that a conference focus acting as a SRC could create a CS for= a meet-me conference before any participants join the conference and there= fore it would have zero participants is this the type of scenario the metad= ata draft refers to or is it something else and how does this relate to our= definition of a CS? More comments on the metadata draft will follow soon. Regards Andy From eckelcu@cisco.com Tue Jan 8 11:26:27 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8232221F8614 for ; Tue, 8 Jan 2013 11:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNrabMBoFWxQ for ; Tue, 8 Jan 2013 11:26:26 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 635AB21F8606 for ; Tue, 8 Jan 2013 11:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1450; q=dns/txt; s=iport; t=1357673186; x=1358882786; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LeSgvikJyR6N6qzoN7G2rVuLReb34OuJH7n34AiL12A=; b=Er6M9fYN9g0Iu8EdoJe8WazECfwCIld14+1+jgLHkh5wrhFLdqoJZ5EK laKWUwPBuYRxUD5/VL8+jEJYB4Z7eIypbby/S5Q4+bKzT1AbcNR5D6vNK 6uJI378wj0cJe8fmjhhUqMtM67rZ3lPh0fTZueFb95udLqG4R1ipAPVTi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGNy7FCtJV2a/2dsb2JhbABEvV4Wc4IeAQEBBAEBATcuBhcEAgEIEQEDAQELFAkHJwsUAwYIAQEEARIIiA4BDKlZjSAEkDRhA6ZVgnSCJg X-IronPort-AV: E=Sophos;i="4.84,433,1355097600"; d="scan'208";a="160185248" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jan 2013 19:26:25 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r08JQPwM009945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jan 2013 19:26:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 13:26:25 -0600 From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: Metadata draft - Communication Session Participants. Thread-Index: Ac3tziX8BqWopky1Th28vJxwgai2lAAB3/Ng Date: Tue, 8 Jan 2013 19:26:24 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280471C7C6@xmb-aln-x08.cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF013A4E01@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013A4E01@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata draft - Communication Session Participants. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 19:26:27 -0000 Hi Andy, Your example is a good one in my opinion. Another example would be the same= conference once all the participants dropped but before the conference end= s. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Hutton, Andrew > Sent: Tuesday, January 08, 2013 10:30 AM > To: siprec@ietf.org > Subject: [siprec] Metadata draft - Communication Session Participants. >=20 > Hi, >=20 > Just reading through draft-ietf-siprec-metadata-10 and I noticed that sec= tion > 6.3.2 which related to CS linkages states "CS to have atleast zero or mor= e > participants" and I am not sure I understand this. >=20 > The architecture draft defines a CS as "A session created between two or > more SIP User Agents (UAs) that is the subject of recording" >=20 > I can imagine that a conference focus acting as a SRC could create a CS f= or a > meet-me conference before any participants join the conference and > therefore it would have zero participants is this the type of scenario th= e > metadata draft refers to or is it something else and how does this relate= to > our definition of a CS? >=20 > More comments on the metadata draft will follow soon. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Jan 8 11:44:47 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B263E11E80F0 for ; Tue, 8 Jan 2013 11:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V4aRUXg3dPF for ; Tue, 8 Jan 2013 11:44:47 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C577D11E80EE for ; Tue, 8 Jan 2013 11:44:46 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A647B1EB8594; Tue, 8 Jan 2013 20:44:45 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Tue, 8 Jan 2013 20:44:45 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Thread-Topic: Metadata draft - Communication Session Participants. Thread-Index: Ac3tziX8BqWopky1Th28vJxwgai2lAAB3/NgAAB3PnA= Date: Tue, 8 Jan 2013 19:44:45 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013A4FC3@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013A4E01@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280471C7C6@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280471C7C6@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata draft - Communication Session Participants. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 19:44:48 -0000 Ok so I am thinking that our definition of communication session in the dra= ft-ietf-siprec-architecture does not match our usage in the metadata draft. In the architecture we define a CS as: "A session created between two or mo= re SIP User Agents (UAs) that is the subject of recording". =20 Maybe we could do with something a bit more arbitrary which allows the sess= ion to be independent of the SIP Session. What do people think do we need to change the definition of a CS in the arc= hitecture draft? Regards Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 08 January 2013 19:26 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: Metadata draft - Communication Session Participants. >=20 > Hi Andy, >=20 > Your example is a good one in my opinion. Another example would be the > same conference once all the participants dropped but before the > conference ends. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > > Of Hutton, Andrew > > Sent: Tuesday, January 08, 2013 10:30 AM > > To: siprec@ietf.org > > Subject: [siprec] Metadata draft - Communication Session > Participants. > > > > Hi, > > > > Just reading through draft-ietf-siprec-metadata-10 and I noticed that > section > > 6.3.2 which related to CS linkages states "CS to have atleast zero or > more > > participants" and I am not sure I understand this. > > > > The architecture draft defines a CS as "A session created between two > or > > more SIP User Agents (UAs) that is the subject of recording" > > > > I can imagine that a conference focus acting as a SRC could create a > CS for a > > meet-me conference before any participants join the conference and > > therefore it would have zero participants is this the type of > scenario the > > metadata draft refers to or is it something else and how does this > relate to > > our definition of a CS? > > > > More comments on the metadata draft will follow soon. > > > > Regards > > Andy > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Jan 8 12:42:47 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626701F0C3E for ; Tue, 8 Jan 2013 12:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQr4IZfF7lha for ; Tue, 8 Jan 2013 12:42:46 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F81F0C6A for ; Tue, 8 Jan 2013 12:42:46 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C5C3D1EB8540 for ; Tue, 8 Jan 2013 21:42:44 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 8 Jan 2013 21:42:44 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Comments on draft-ietf-siprec-metadata-10. Thread-Index: Ac3t4LUTOYBY1zhiQFChl+OUebPiLw== Date: Tue, 8 Jan 2013 20:42:44 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013A504B@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Comments on draft-ietf-siprec-metadata-10. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 20:42:47 -0000 Hi, I just read through the draft-ietf-draft-siprec-metadata-10 and have the fo= llowing comments. 1. Section 6.1.1 - The Start/End time is I assume the start/end time of the= RS not of the "Recording Session Object". 2. Section 6.1.2 - Whilst discussing the linkage between a RS and a CSG sta= tes:=20 "Also the allowance of zero instances is to accommodate persistent recordin= g, where there may be none". I think this could be made a bit clearer and = suggest=20 "Also the allowance of zero instances is to accommodate persistent recordin= g, where there may be no CS or CSG in existence when the RS is created". 3. Section 6.2.1 Which discusses CS session attributes includes the followi= ng statement: "SRC (or SRS) is responsible for ensuring the uniqueness of U= nique-ID in case multiple SRC interacts with the same SRS.". I don't see h= ow the SRS can be responsible for this and think the statement is unnecessa= ry and could simple be replaced with a reference to 6.10 which stated descr= ibes how unique-id's are created. 4. Section 6.2.2 States "Each Communication Session Group object has to be = associated with one or more RS [Here each RS can be setup by the potentiall= y different SRCs". Is it really the case that there can be more than one R= S per CS Group? If it is because each RS can be established by different SR= C's then I assume this should impact the object model which only describes = the metadata generated by a single SRC. 5. Section 6.2.2 States "There is one or more Communication Sessions per CS= Group [e.g. Consult Transfer]". I think we need more explanation of scenar= ios in which a CS Group is applicable than just "E.g. Consult Transfer". Ca= n somebody provide a description of a basic scenario in which a CSG would b= e used? 6. Section 6.3.1 Communication Session Attributes. I think we need more det= ail as to the format of the Termination Reason. It would probably be useful= to say that it is formatted according to the rules of RFC3326 if that is t= he intention and give an example in section 7.1. 7. Section 6.3.1. The last paragraph which starts "This document does not s= pecify attributes relating to what should happen to a recording of a CS aft= er it has been delivered..." does not appear to be useful to me and could b= e removed. 8. Section 6.3.2 "CS to have atleast zero or more participants" should read= "CS has zero or more participants". I started a separate thread on a CS ha= ving zero particants. 9. Section 6.5 states "A Participant class and its objects has information = about a device..." I don't think it is necessarily information about a "de= vice" which implies some kind of endpoint device and a participant does not= relate to a device in my mind. I think we should stick to the term "partic= ipant". 10. Section 6.5.1 replace "Participant has attributes like" with "Replace w= ith "A participant class has the following attributes:". 11. Section 6.7.1. "A Media Stream class has the the following attributes:"= - Remove duplicate "the". 12. Section 7.1 claims to contain example usage of all the metadata attribu= tes but I noted it does not contain a CS reason attribute. 13. Can we change the name of the CS "reason" attribute to "terminationReas= on" or do we think it is too late to do that. 14. Section 9 Security Considerations - Maybe we should make a reference to= the protocol draft which specifies the security considerations for transpo= rting the information certainly we should not duplicate information already= in the protocol draft. Regards Andy From partha@parthasarathi.co.in Wed Jan 9 08:34:16 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9C421F880E for ; Wed, 9 Jan 2013 08:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=2.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br0-+-3dRqho for ; Wed, 9 Jan 2013 08:34:16 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [70.87.28.138]) by ietfa.amsl.com (Postfix) with ESMTP id 1E87E21F87D4 for ; Wed, 9 Jan 2013 08:34:16 -0800 (PST) Received: from userPC (unknown [122.179.82.173]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id D44311EBFE8B; Wed, 9 Jan 2013 16:34:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1357749255; bh=LEc+9GgY/cjCCHTbPJtcg9HtyJdAM91Q7dg/uzZgeE8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jwVdp0ZS6fnLL5mxDwDhaP/yLjkLUmOfROZ53J0uyIq/qtX9SAIZ8D0Wwtk3PqNDY fhhLNrsCXLDo/wx8tWIE7d05M7+aq96sejtRAwAXexdshH+FMAMS2kDXhQgkel1v3K 5UIetzCo1mTvmN/BLBXkzDhaaaw+aPqv7C+raxqE= From: "Parthasarathi R" To: "'Hutton, Andrew'" , "'Charles Eckel \(eckelcu\)'" , References: <9F33F40F6F2CD847824537F3C4E37DDF013A4E01@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280471C7C6@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF013A4FC3@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013A4FC3@MCHP04MSX.global-ad.net> Date: Wed, 9 Jan 2013 22:04:06 +0530 Message-ID: <003001cdee87$27b60b90$772222b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3tziX8BqWopky1Th28vJxwgai2lAAB3/NgAAB3PnAAK22BgA== Content-Language: en-us X-CTCH-Spam: Suspect X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0201.50ED9C07.00BF, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 Subject: Re: [siprec] Metadata draft - Communication Session Participants. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jan 2013 16:34:17 -0000 Andy, Metadata draft CS definition is changed as per IETF 82 minutes (http://www.ietf.org/proceedings/82/minutes/siprec.txt) and the exact minutes is as follows: "Issue 3 Any objections to allow a CS to have zero or more participants ? Already discussed on list, --> Accepted." I agree with you that SIPREC architecture has to be updated to make it inline With IETF82 decision but CS has to be SIP session. The reason for CS as SIP Session is that non SIP-session like H.323/WebRTC session will create more Complexity in SIPREC solution. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Wednesday, January 09, 2013 1:15 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] Metadata draft - Communication Session > Participants. > > Ok so I am thinking that our definition of communication session in the > draft-ietf-siprec-architecture does not match our usage in the metadata > draft. > > In the architecture we define a CS as: "A session created between two > or more SIP User Agents (UAs) that is the subject of recording". > > Maybe we could do with something a bit more arbitrary which allows the > session to be independent of the SIP Session. > > What do people think do we need to change the definition of a CS in the > architecture draft? > > Regards > Andy > > > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 08 January 2013 19:26 > > To: Hutton, Andrew; siprec@ietf.org > > Subject: RE: Metadata draft - Communication Session Participants. > > > > Hi Andy, > > > > Your example is a good one in my opinion. Another example would be > the > > same conference once all the participants dropped but before the > > conference ends. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > > > Of Hutton, Andrew > > > Sent: Tuesday, January 08, 2013 10:30 AM > > > To: siprec@ietf.org > > > Subject: [siprec] Metadata draft - Communication Session > > Participants. > > > > > > Hi, > > > > > > Just reading through draft-ietf-siprec-metadata-10 and I noticed > that > > section > > > 6.3.2 which related to CS linkages states "CS to have atleast zero > or > > more > > > participants" and I am not sure I understand this. > > > > > > The architecture draft defines a CS as "A session created between > two > > or > > > more SIP User Agents (UAs) that is the subject of recording" > > > > > > I can imagine that a conference focus acting as a SRC could create > a > > CS for a > > > meet-me conference before any participants join the conference and > > > therefore it would have zero participants is this the type of > > scenario the > > > metadata draft refers to or is it something else and how does this > > relate to > > > our definition of a CS? > > > > > > More comments on the metadata draft will follow soon. > > > > > > Regards > > > Andy > > > > > > > > > > > > > > > _______________________________________________ > > > 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 andrew.hutton@siemens-enterprise.com Thu Jan 10 02:34:49 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C8821F890E for ; Thu, 10 Jan 2013 02:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkUlSnbKXHHx for ; Thu, 10 Jan 2013 02:34:48 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7D21F869C for ; Thu, 10 Jan 2013 02:34:48 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 39D0023F0521 for ; Thu, 10 Jan 2013 11:34:47 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Thu, 10 Jan 2013 11:34:46 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: IETF86 SIPREC F2F Meeting Thread-Index: Ac3vHhvpP1mhx5OwQci8qjsKLZXP2A== Date: Thu, 10 Jan 2013 10:34:47 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013A7554@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] IETF86 SIPREC F2F Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jan 2013 10:34:49 -0000 Hi All, I have asked for our usual 2 hour slot for SIPREC at IETF86 I assume we wil= l need this, any views on this? We really need to start moving draft-ietf-siprec-protocol towards a WGLC so= could we have some volunteers to perform a detailed review on the latest u= pdates. Also we still need more reviewers for draft-ietf-siprec-metadata and draft-= ram-siprec-callflows-02 drafts. Regards Andy From andrew.hutton@siemens-enterprise.com Thu Jan 10 03:01:17 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28B921F88CA for ; Thu, 10 Jan 2013 03:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvOLuucZUg2A for ; Thu, 10 Jan 2013 03:01:15 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 67E9021F88C7 for ; Thu, 10 Jan 2013 03:01:14 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 5EFBD1EB86ED; Thu, 10 Jan 2013 12:01:10 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Thu, 10 Jan 2013 12:01:09 +0100 From: "Hutton, Andrew" To: Parthasarathi R , "'Charles Eckel (eckelcu)'" , "siprec@ietf.org" Thread-Topic: [siprec] Metadata draft - Communication Session Participants. Thread-Index: Ac3tziX8BqWopky1Th28vJxwgai2lAAB3/NgAAB3PnAAK22BgAAmskIQ Date: Thu, 10 Jan 2013 11:01:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013A75B4@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013A4E01@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280471C7C6@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF013A4FC3@MCHP04MSX.global-ad.net> <003001cdee87$27b60b90$772222b0$@co.in> In-Reply-To: <003001cdee87$27b60b90$772222b0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata draft - Communication Session Participants. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jan 2013 11:01:17 -0000 Hi Partha, Thanks for pointing this out I have no problem with the metadata definition= . Regarding the definition of a CS in the architecture draft the current text= states: "Communication Session (CS): A session created between two or more SIP Use= r Agents (UAs) that is the subject of recording". I am not sure we really need to change this just because the metadata speci= fication allows the communication session object to be created before the r= eal SIP session is created. Could we not just add some explanation to the m= etadata draft. Regards Andy > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 09 January 2013 16:34 > To: Hutton, Andrew; 'Charles Eckel (eckelcu)'; siprec@ietf.org > Subject: RE: [siprec] Metadata draft - Communication Session > Participants. >=20 > Andy, >=20 > Metadata draft CS definition is changed as per IETF 82 minutes > (http://www.ietf.org/proceedings/82/minutes/siprec.txt) and the exact > minutes is as follows: >=20 > "Issue 3 > Any objections to allow a CS to have zero or more participants ? > Already discussed on list, --> Accepted." >=20 > I agree with you that SIPREC architecture has to be updated to make it > inline > With IETF82 decision but CS has to be SIP session. The reason for CS as > SIP > Session is that non SIP-session like H.323/WebRTC session will create > more > Complexity in SIPREC solution. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Wednesday, January 09, 2013 1:15 AM > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: Re: [siprec] Metadata draft - Communication Session > > Participants. > > > > Ok so I am thinking that our definition of communication session in > the > > draft-ietf-siprec-architecture does not match our usage in the > metadata > > draft. > > > > In the architecture we define a CS as: "A session created between two > > or more SIP User Agents (UAs) that is the subject of recording". > > > > Maybe we could do with something a bit more arbitrary which allows > the > > session to be independent of the SIP Session. > > > > What do people think do we need to change the definition of a CS in > the > > architecture draft? > > > > Regards > > Andy > > > > > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 08 January 2013 19:26 > > > To: Hutton, Andrew; siprec@ietf.org > > > Subject: RE: Metadata draft - Communication Session Participants. > > > > > > Hi Andy, > > > > > > Your example is a good one in my opinion. Another example would be > > the > > > same conference once all the participants dropped but before the > > > conference ends. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf > > > > Of Hutton, Andrew > > > > Sent: Tuesday, January 08, 2013 10:30 AM > > > > To: siprec@ietf.org > > > > Subject: [siprec] Metadata draft - Communication Session > > > Participants. > > > > > > > > Hi, > > > > > > > > Just reading through draft-ietf-siprec-metadata-10 and I noticed > > that > > > section > > > > 6.3.2 which related to CS linkages states "CS to have atleast > zero > > or > > > more > > > > participants" and I am not sure I understand this. > > > > > > > > The architecture draft defines a CS as "A session created between > > two > > > or > > > > more SIP User Agents (UAs) that is the subject of recording" > > > > > > > > I can imagine that a conference focus acting as a SRC could > create > > a > > > CS for a > > > > meet-me conference before any participants join the conference > and > > > > therefore it would have zero participants is this the type of > > > scenario the > > > > metadata draft refers to or is it something else and how does > this > > > relate to > > > > our definition of a CS? > > > > > > > > More comments on the metadata draft will follow soon. > > > > > > > > Regards > > > > Andy > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 partha@parthasarathi.co.in Thu Jan 10 09:56:35 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D89121F87B2 for ; Thu, 10 Jan 2013 09:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u2qzblTZEg1 for ; Thu, 10 Jan 2013 09:56:34 -0800 (PST) Received: from outbound-us3.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.155]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF2A21F893D for ; Thu, 10 Jan 2013 09:56:33 -0800 (PST) Received: from userPC (unknown [122.179.84.142]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 0F3B4868578; Thu, 10 Jan 2013 17:56:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1357840592; bh=qzkJkDNktErSMD4jA6HJkmGmGdWmeeYd9yunflxKxlU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hCyxhGeMuf7e4xeHrlov+JS+f2EelaVt9TIH/i/y/gY5oRMSLjmlqDdiKisCwIwBt a0yieCNiBwdK9tuLp0zB5Bj/i5bwh6WQEZmjFI3LItAevwQhx8qSXsAkXMlZ20VGNV z5SAw6JOT1C3cwIukAko4Jx541Qr7Cc4ptAoD3qo= From: "Parthasarathi R" To: "'Hutton, Andrew'" , "'Charles Eckel \(eckelcu\)'" , References: <9F33F40F6F2CD847824537F3C4E37DDF013A4E01@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280471C7C6@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF013A4FC3@MCHP04MSX.global-ad.net> <003001cdee87$27b60b90$772222b0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF013A75B4@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013A75B4@MCHP04MSX.global-ad.net> Date: Thu, 10 Jan 2013 23:26:22 +0530 Message-ID: <002301cdef5b$d03418f0$709c4ad0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3tziX8BqWopky1Th28vJxwgai2lAAB3/NgAAB3PnAAK22BgAAmskIQAA4mYSA= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0205.50EF00D0.0127, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] Metadata draft - Communication Session Participants. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jan 2013 17:56:35 -0000 Andy, I'm fine with your approach of adding more explanation about Communication session and its association with participants in the metadata draft itself. The current architecture and metadata draft definition of communication session is same for two or more participants. The information has to added about zero and one participant associated with communication session. The actual usecase is as follows: 1) Zero or One participant in CS is possible in case conference focus acts as SRC and has only Zero or one participant is in the conference focus at the given time. Here, conference focus is not considered as a participant of the CS and also conference shall start without any participant. 2) Also, One Participant in CS is possible in case studio recorder acts as SRC and forward RS to SRS. Here, studio recorder SRC is not considered as participant of the CS. Please let me know whether adding the above use case explanation as part of CS to participant association linkage section will serve the purpose or you wish to add some definition about CS to participant association. Thanks Partha > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Thursday, January 10, 2013 4:31 PM > To: Parthasarathi R; 'Charles Eckel (eckelcu)'; siprec@ietf.org > Subject: RE: [siprec] Metadata draft - Communication Session > Participants. > > Hi Partha, > > Thanks for pointing this out I have no problem with the metadata > definition. > > Regarding the definition of a CS in the architecture draft the current > text states: > > "Communication Session (CS): A session created between two or more SIP > User Agents (UAs) that is the subject of recording". > > I am not sure we really need to change this just because the metadata > specification allows the communication session object to be created > before the real SIP session is created. Could we not just add some > explanation to the metadata draft. > > Regards > Andy > > > > > -----Original Message----- > > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > > Sent: 09 January 2013 16:34 > > To: Hutton, Andrew; 'Charles Eckel (eckelcu)'; siprec@ietf.org > > Subject: RE: [siprec] Metadata draft - Communication Session > > Participants. > > > > Andy, > > > > Metadata draft CS definition is changed as per IETF 82 minutes > > (http://www.ietf.org/proceedings/82/minutes/siprec.txt) and the exact > > minutes is as follows: > > > > "Issue 3 > > Any objections to allow a CS to have zero or more participants ? > > Already discussed on list, --> Accepted." > > > > I agree with you that SIPREC architecture has to be updated to make > it > > inline > > With IETF82 decision but CS has to be SIP session. The reason for CS > as > > SIP > > Session is that non SIP-session like H.323/WebRTC session will create > > more > > Complexity in SIPREC solution. > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: Wednesday, January 09, 2013 1:15 AM > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > Subject: Re: [siprec] Metadata draft - Communication Session > > > Participants. > > > > > > Ok so I am thinking that our definition of communication session in > > the > > > draft-ietf-siprec-architecture does not match our usage in the > > metadata > > > draft. > > > > > > In the architecture we define a CS as: "A session created between > two > > > or more SIP User Agents (UAs) that is the subject of recording". > > > > > > Maybe we could do with something a bit more arbitrary which allows > > the > > > session to be independent of the SIP Session. > > > > > > What do people think do we need to change the definition of a CS in > > the > > > architecture draft? > > > > > > Regards > > > Andy > > > > > > > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 08 January 2013 19:26 > > > > To: Hutton, Andrew; siprec@ietf.org > > > > Subject: RE: Metadata draft - Communication Session Participants. > > > > > > > > Hi Andy, > > > > > > > > Your example is a good one in my opinion. Another example would > be > > > the > > > > same conference once all the participants dropped but before the > > > > conference ends. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > > > Behalf > > > > > Of Hutton, Andrew > > > > > Sent: Tuesday, January 08, 2013 10:30 AM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] Metadata draft - Communication Session > > > > Participants. > > > > > > > > > > Hi, > > > > > > > > > > Just reading through draft-ietf-siprec-metadata-10 and I > noticed > > > that > > > > section > > > > > 6.3.2 which related to CS linkages states "CS to have atleast > > zero > > > or > > > > more > > > > > participants" and I am not sure I understand this. > > > > > > > > > > The architecture draft defines a CS as "A session created > between > > > two > > > > or > > > > > more SIP User Agents (UAs) that is the subject of recording" > > > > > > > > > > I can imagine that a conference focus acting as a SRC could > > create > > > a > > > > CS for a > > > > > meet-me conference before any participants join the conference > > and > > > > > therefore it would have zero participants is this the type of > > > > scenario the > > > > > metadata draft refers to or is it something else and how does > > this > > > > relate to > > > > > our definition of a CS? > > > > > > > > > > More comments on the metadata draft will follow soon. > > > > > > > > > > Regards > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 eckelcu@cisco.com Fri Jan 11 10:36:57 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D675F21F8903 for ; Fri, 11 Jan 2013 10:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.647 X-Spam-Level: X-Spam-Status: No, score=-8.647 tagged_above=-999 required=5 tests=[AWL=1.952, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH2UYhAhLiSN for ; Fri, 11 Jan 2013 10:36:54 -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 4849921F8918 for ; Fri, 11 Jan 2013 10:36:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1276; q=dns/txt; s=iport; t=1357929413; x=1359139013; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Xwp7g5fW0qMRvWoNA4KPpstg42n7olOjGdqqYzrE+l8=; b=D92ePZZuOnLJRyisnqdGanxdSGwrLUA8ZIpfQQFcvh/+Ayyw8u7bQ/iA c2dwXg+zWpo6jrpRW52hdGtExYvl6L0jv2HzIe0+D3+fKFL9pv33NWh3U jjfaprWw5EmxEcbeuzqb5XeoKGfloQSevJLIQRm5sCaEyphMuJz2vfSyY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAG1a8FCtJV2b/2dsb2JhbABEvX4Wc4IeAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAQEEARIIiBABDLYeBJBFYQOmVIJ1giQ X-IronPort-AV: E=Sophos;i="4.84,453,1355097600"; d="scan'208";a="158488961" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jan 2013 18:36:52 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0BIaqn7026956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jan 2013 18:36:52 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 12:36:52 -0600 From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: IETF86 SIPREC F2F Meeting Thread-Index: Ac3vHhvpP1mhx5OwQci8qjsKLZXP2ABC6iRw Date: Fri, 11 Jan 2013 18:36:51 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882804729014@xmb-aln-x08.cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF013A7554@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013A7554@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] IETF86 SIPREC F2F Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jan 2013 18:36:57 -0000 Hi Andy, I expect we will have enough to discuss to warrant a two hour slot. As for the protocol draft, it would be great to get some close reviews of t= he complete document, or at least comments on the changes since IETF 85. Id= eally this will occur in time for the authors to post an additional update = addressing those comments prior to the document submission deadline (Feb 25= ). Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Hutton, Andrew > Sent: Thursday, January 10, 2013 2:35 AM > To: siprec@ietf.org > Subject: [siprec] IETF86 SIPREC F2F Meeting >=20 > Hi All, >=20 > I have asked for our usual 2 hour slot for SIPREC at IETF86 I assume we w= ill > need this, any views on this? >=20 > We really need to start moving draft-ietf-siprec-protocol towards a WGLC = so > could we have some volunteers to perform a detailed review on the latest > updates. >=20 > Also we still need more reviewers for draft-ietf-siprec-metadata and draf= t- > ram-siprec-callflows-02 drafts. >=20 > Regards > Andy >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partha@parthasarathi.co.in Sat Jan 12 08:52:25 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC9E21F8734 for ; Sat, 12 Jan 2013 08:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jktecG50fxXM for ; Sat, 12 Jan 2013 08:52:24 -0800 (PST) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id 24B5821F872E for ; Sat, 12 Jan 2013 08:52:23 -0800 (PST) Received: from userPC (unknown [122.179.38.8]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 9BF893E2CAE; Sat, 12 Jan 2013 16:52:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1358009543; bh=0igHI/YTr58EKCwB3U0mVRI3aQZ++0m9vSgmUxVSvW4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=APx1/RU3PR6Q1VIAFsS0njWJkwcBlpr3JTy4KdrGnfIo2s1v5mZG50swmZASsNMSc lpyh+Ily4EM2X6nzo5UcEEkFSb8AuM8YJMSOSGvKoyOmqi5vi2IYhgDmSU/HmSpX97 SqEkABsnwj1Izi6tFQvxPw4WrN6Ic8VJfcCaBZC0= From: "Parthasarathi R" To: "'Hutton, Andrew'" , References: <9F33F40F6F2CD847824537F3C4E37DDF013A504B@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013A504B@MCHP04MSX.global-ad.net> Date: Sat, 12 Jan 2013 22:22:10 +0530 Message-ID: <000001cdf0e5$2cebf290$86c3d7b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3t4LUTOYBY1zhiQFChl+OUebPiLwCoi4Nw Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0205.50F194C6.0135, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 16:52:25 -0000 Andy, Thanks a lot for the detailed review. Please read inline. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Wednesday, January 09, 2013 2:13 AM > To: siprec@ietf.org > Subject: [siprec] Comments on draft-ietf-siprec-metadata-10. > > Hi, > > I just read through the draft-ietf-draft-siprec-metadata-10 and have > the following comments. > > > 1. Section 6.1.1 - The Start/End time is I assume the start/end time of > the RS not of the "Recording Session Object". > Your assumption is right. Recording session object start/end time is same as start/end time of RS. It is clarified in the draft as "In cases where Date header is not present, Start/End time are derivable from the time at which SRS receives the notification of SIP message to setup RS / disconnect RS." > > 2. Section 6.1.2 - Whilst discussing the linkage between a RS and a CSG > states: > > "Also the allowance of zero instances is to accommodate persistent > recording, where there may be none". I think this could be made a bit > clearer and suggest > > "Also the allowance of zero instances is to accommodate persistent > recording, where there may be no CS or CSG in existence when the RS is > created". > Agreed > 3. Section 6.2.1 Which discusses CS session attributes includes the > following statement: "SRC (or SRS) is responsible for ensuring the > uniqueness of Unique-ID in case multiple SRC interacts with the same > SRS.". I don't see how the SRS can be responsible for this and think > the statement is unnecessary and could simple be replaced with a > reference to 6.10 which stated describes how unique-id's are created. > Agreed. SRS has to be remove. The updated text will look like "SRC is responsible for ensuring the uniqueness of Unique-ID in case multiple SRC interacts with the same SRS." > 4. Section 6.2.2 States "Each Communication Session Group object has to > be associated with one or more RS [Here each RS can be setup by the > potentially different SRCs". Is it really the case that there can be > more than one RS per CS Group? If it is because each RS can be > established by different SRC's then I assume this should impact the > object model which only describes the metadata generated by a single > SRC. > Multiple SRC to SRS is supported in metadata model wherein how SRC Communicate with each other for CSG/CS unique id is outside the scope of SIPREC. It is stated in both Sec 6.2.1 and Sec 6.2.2. Multiple RS shall be associated with single CSG. > 5. Section 6.2.2 States "There is one or more Communication Sessions > per CS Group [e.g. Consult Transfer]". I think we need more explanation > of scenarios in which a CS Group is applicable than just "E.g. Consult > Transfer". Can somebody provide a description of a basic scenario in > which a CSG would be used? > Please let me whether it is sufficient to provide the CS group usage in the example draft. In case you wish to see any specific text, Please propose > 6. Section 6.3.1 Communication Session Attributes. I think we need more > detail as to the format of the Termination Reason. It would probably be > useful to say that it is formatted according to the rules of RFC3326 if > that is the intention and give an example in section 7.1. > Reason XML element is a string which may be as per RFC 3326 and there is no Mandate to strictly follow RFC 3326Please let me whether it is sufficient to provide the reason XML element usage in the example draft. > 7. Section 6.3.1. The last paragraph which starts "This document does > not specify attributes relating to what should happen to a recording of > a CS after it has been delivered..." does not appear to be useful to me > and could be removed. > This statement was added after long discussion in mailing alias and earlier IETF meeting about "when CS actually terminates". The discussion happened very long back and in case it is required, I will Search for the archive to find the exact timeframe at which this Statement was added > 8. Section 6.3.2 "CS to have atleast zero or more participants" should > read "CS has zero or more participants". I started a separate thread on > a CS having zero particants. I have proposed the statement/usecase for this usage in the another mail thread. Let us close this open item in the another mail thread > > 9. Section 6.5 states "A Participant class and its objects has > information about a device..." I don't think it is necessarily > information about a "device" which implies some kind of endpoint device > and a participant does not relate to a device in my mind. I think we > should stick to the term "participant". Agreed > > 10. Section 6.5.1 replace "Participant has attributes like" with > "Replace with "A participant class has the following attributes:". Agreed > > 11. Section 6.7.1. "A Media Stream class has the the following > attributes:" - Remove duplicate "the". Agreed > > 12. Section 7.1 claims to contain example usage of all the metadata > attributes but I noted it does not contain a CS reason attribute. > reason is used during the termination of the session. The Example usage is based on the CS initiation. Stop time usage is not Shown for the same reason. I think that Sec 7.1 text has to be updated to indicate that "CS initiation with complete metadata XML usage". Also, please let me know whether you are interested in adding one more example usage for the termination metadata XML usage > 13. Can we change the name of the CS "reason" attribute to > "terminationReason" or do we think it is too late to do that. > Reason XML element name is based on Reason SIP header and I'm fine with your proposal of detailed name to avoid confusion. We will ask more opinion before Changing as some SIPREC implementation may have used this XML tag. > 14. Section 9 Security Considerations - Maybe we should make a > reference to the protocol draft which specifies the security > considerations for transporting the information certainly we should not > duplicate information already in the protocol draft. > I agree with you that security consideration has to be updated. I'm not very sure whether it is fine to have circular reference as SIPREC metadata draft is referenced in the protocol draft. Also, Protocol draft covers the complete RS with SDP, XML, RTP security whereas here, the interest is specific to XML schema. > > Regards > Andy > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From DAVE.HIGTON@nice.com Wed Jan 16 09:01:57 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5723A21F8B65 for ; Wed, 16 Jan 2013 09:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXI5ekpyDjVG for ; Wed, 16 Jan 2013 09:01:55 -0800 (PST) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id 569CE21F8B61 for ; Wed, 16 Jan 2013 09:01:54 -0800 (PST) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Wed, 16 Jan 2013 17:01:53 +0000 Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jan 2013 17:01:52 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::ec6d:6017:186e:e8f8]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Wed, 16 Jan 2013 17:01:52 +0000 From: "Dave Higton" Content-Transfer-Encoding: 7bit To: Date: Wed, 16 Jan 2013 17:01:51 +0000 Content-Class: urn:content-classes:message Importance: normal Priority: normal Thread-Topic: Sample synchronisation of multiple media streams X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Index: Ac30CejB4pYt7RebSEWSJyCBB+L5vw== Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B6940560B4C5F4@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: multipart/alternative; boundary="_000_9B0B6FB9606F4D4AB133C5E9A203B6940560B4C5F4SOUEXC01eunic_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2013 17:01:52.0684 (UTC) FILETIME=[2E935EC0:01CDF40B] Subject: [siprec] Sample synchronisation of multiple media streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2013 17:01:57 -0000 This is a multi-part message in MIME format. --_000_9B0B6FB9606F4D4AB133C5E9A203B6940560B4C5F4SOUEXC01eunic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does SIPREC provide any means to synchronise media streams from multiple = sources? In case there's anyone reading who isn't aware of the consequences: Sometimes media streams can arrived from separate physical sources but = have common content, e.g. a radio signal picked up by two receivers, and = be recorded as separate streams. Sometimes users wish to replay these = streams simultaneously, mixed. In the case of audio streams, unless = they are perfectly synchronised, this causes a comb filter. For short = delays, it can sound rather like talking down a drainpipe; for longer = delays, there is an echo. It is highly desirable to have some means to synchronise multiple = streams, preferably to one sample. The subject of whether users are misguided in wanting to replay audio = like this, is a separate debate. Dave 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. --_000_9B0B6FB9606F4D4AB133C5E9A203B6940560B4C5F4SOUEXC01eunic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does SIPREC provide any means to synchronise media = streams from multiple sources?

 

In case = there’s anyone reading who isn’t aware of the = consequences:

 

Sometimes media streams can arrived from separate = physical sources but have common content, e.g. a radio signal picked up = by two receivers, and be recorded as separate streams.  Sometimes = users wish to replay these streams simultaneously, mixed.  In the = case of audio streams, unless they are perfectly synchronised, this = causes a comb filter.  For short delays, it can sound rather like = talking down a drainpipe; for longer delays, there is an = echo.

 

It is highly desirable to have some means to = synchronise multiple streams, preferably to one sample.

 

The subject = of whether users are misguided in wanting to replay audio like this, is = a separate debate.

 

Dave

 



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. 

 --_000_9B0B6FB9606F4D4AB133C5E9A203B6940560B4C5F4SOUEXC01eunic_-- From eckelcu@cisco.com Wed Jan 16 13:16:27 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4741F21F8A2F for ; Wed, 16 Jan 2013 13:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.777 X-Spam-Level: X-Spam-Status: No, score=-8.777 tagged_above=-999 required=5 tests=[AWL=1.822, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quBMC+HUHs9V for ; Wed, 16 Jan 2013 13:16:26 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6E11521F8A25 for ; Wed, 16 Jan 2013 13:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3004; q=dns/txt; s=iport; t=1358370986; x=1359580586; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Kck7a6BuxFUFe2rydmSNDamKkauo7nI7ez6gc52jz9I=; b=aIdlpLpZu4WzctTI+iijALw5WlG7XLyoVgOgiui6kuLoxD85srP51BTx UzA2U9LiN3vr8i6QSs/lj598o08Ec1mZy4PYzHw8QRiIx6qEQPoZvSyNC /HBio2mBWCD0q9thcpISowz0XL+QiDnKAtbsQ1ovzBTdoGNl/ApNAtlaX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMMX91CtJXG8/2dsb2JhbABEvX8Wc4IeAQEBBDoaMQQCAQgRBAEBCxQJBzIUCQgBAQQBEgiIEAG5MI0KBoNHYQOmVYJ1gWYJFx4 X-IronPort-AV: E=Sophos;i="4.84,480,1355097600"; d="scan'208";a="163428476" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jan 2013 21:16:26 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0GLGPOA001739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2013 21:16:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 15:16:25 -0600 From: "Charles Eckel (eckelcu)" To: Dave Higton , "siprec@ietf.org" Thread-Topic: Sample synchronisation of multiple media streams Thread-Index: Ac30CejB4pYt7RebSEWSJyCBB+L5vwAI+ugQ Date: Wed, 16 Jan 2013 21:16:24 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280472EDB6@xmb-aln-x08.cisco.com> References: <9B0B6FB9606F4D4AB133C5E9A203B6940560B4C5F4@SOUEXC01.eu.nice.com> In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940560B4C5F4@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Sample synchronisation of multiple media streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2013 21:16:27 -0000 Hi David, If the media streams are synchronized within the CS, then they should be sy= nchronized in the RS as well. However, it sounds as if you are referring to= media streams that are not synchronized in the CS. In that case, I see a f= ew alternatives: 1) SRC detects duplicate streams and includes only one in RS 2) SRC detects duplication streams and includes metadata for each such that= the duplication is evident 3) SRC does not detect duplication and synchronization is based on wall clo= ck, which is included per stream in metadata I believe SIPREC today supports all of these options. SIPREC does not manda= te that a SRC be able to detect duplicate streams but it provides mechanism= s for the SRC to enhance the RS in the case it does. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Dave Higton > Sent: Wednesday, January 16, 2013 9:02 AM > To: siprec@ietf.org > Subject: [siprec] Sample synchronisation of multiple media streams >=20 > Does SIPREC provide any means to synchronise media streams from > multiple sources? >=20 >=20 >=20 > In case there's anyone reading who isn't aware of the consequences: >=20 >=20 >=20 > Sometimes media streams can arrived from separate physical sources but > have common content, e.g. a radio signal picked up by two receivers, and = be > recorded as separate streams. Sometimes users wish to replay these > streams simultaneously, mixed. In the case of audio streams, unless they > are perfectly synchronised, this causes a comb filter. For short delays,= it can > sound rather like talking down a drainpipe; for longer delays, there is a= n > echo. >=20 >=20 >=20 > It is highly desirable to have some means to synchronise multiple streams= , > preferably to one sample. >=20 >=20 >=20 > The subject of whether users are misguided in wanting to replay audio lik= e > this, is a separate debate. >=20 >=20 >=20 > Dave >=20 >=20 >=20 >=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 E= nd, > 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. > Viruses: Although we have taken steps toward ensuring that this e-mail an= d > attachments are free from any virus, we advise that in keeping with good > computing practice the recipient should ensure they are actually virus fr= ee. From internet-drafts@ietf.org Tue Jan 29 05:02:43 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9558D21F8734; Tue, 29 Jan 2013 05:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVoK+QdQ6RWX; Tue, 29 Jan 2013 05:02:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2440D21F875A; Tue, 29 Jan 2013 05:02:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130129130243.16208.31751.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2013 05:02:43 -0800 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-11.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jan 2013 13:02:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-11.txt Pages : 28 Date : 2013-01-29 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rmohanr@cisco.com Tue Jan 29 05:05:00 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200CC21F87D6 for ; Tue, 29 Jan 2013 05:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zwuGeF13wQ7 for ; Tue, 29 Jan 2013 05:04:58 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E2EE321F87D2 for ; Tue, 29 Jan 2013 05:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2146; q=dns/txt; s=iport; t=1359464698; x=1360674298; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=sNCGvmlRTQyAZ/yP89CNhjoE4FnF8EiRGN+OKvlsezQ=; b=Qs6ET/vQxGmiLzFfCbAaicirNi/SUidKOzeVr4dC6XvFjMrHU7+ououb DbO6o9tBebq3PADGUewL3DqMHzb/ZUcVGMEtdJ1xa8xHySGjEsqDmWU0l NUE0ltPVKxtP75FnvmCF+2CHPuRG6L4u+8Ma5G3ogiuKv2a63FO9Ca9G8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPLHB1GrRDoG/2dsb2JhbABEg3W6ZxZzgh4BAQEDAQEBATc0EA0BCCIUNwslAgQTCAGIAgUBBwWfPZEUkCiQKGEDlymPL4J3gWgkGA X-IronPort-AV: E=Sophos;i="4.84,559,1355097600"; d="scan'208";a="66860221" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 29 Jan 2013 13:04:56 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0TD4uJn006061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jan 2013 13:04:56 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.135]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 07:04:56 -0600 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-11.txt Thread-Index: AQHN/iE827xLkMP9dEWHfx8wviu7eA== Date: Tue, 29 Jan 2013 13:04:55 +0000 Message-ID: In-Reply-To: <20130129130243.16208.31751.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.13.0.110805 x-originating-ip: [10.65.77.166] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-11.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jan 2013 13:05:00 -0000 Hello All, Have published a new revision of the draft. The changes include: 1) Incorporating Schema validation errors and corrections given by Simon in the metadata XML schema 2) Added a section for metadata version indicator(section 6.11) and updated the XML schema and metadata example to show the same. Please note the comments given by Andy are not yet incorporated. Will be done in the next revision Regards, Ram > On 29/01/13 6:32 PM, "internet-drafts@ietf.org" > wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the SIP Recording Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) Recording Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-11.txt > Pages : 28 > Date : 2013-01-29 > >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-11 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-11 > > >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 andrew.hutton@siemens-enterprise.com Tue Jan 29 08:32:58 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B623821F8881 for ; Tue, 29 Jan 2013 08:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUItJ51Mkn1N for ; Tue, 29 Jan 2013 08:32:57 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB0221F886E for ; Tue, 29 Jan 2013 08:32:57 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id C311B23F058B; Tue, 29 Jan 2013 17:32:55 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.175]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Tue, 29 Jan 2013 17:32:55 +0100 From: "Hutton, Andrew" To: Parthasarathi R , "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-metadata-10. Thread-Index: Ac3t4LUTOYBY1zhiQFChl+OUebPiLwCoi4NwA2pgwSA= Date: Tue, 29 Jan 2013 16:32:55 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013C7313@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013A504B@MCHP04MSX.global-ad.net> <000001cdf0e5$2cebf290$86c3d7b0$@co.in> In-Reply-To: <000001cdf0e5$2cebf290$86c3d7b0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jan 2013 16:32:58 -0000 Hi Partha, See inline below. Sorry for the slow response had my head down in other stuff. Could you put the open issues in to the tracker? Regards Andy > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 12 January 2013 16:52 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: [siprec] Comments on draft-ietf-siprec-metadata-10. >=20 > Andy, >=20 > Thanks a lot for the detailed review. Please read inline. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Wednesday, January 09, 2013 2:13 AM > > To: siprec@ietf.org > > Subject: [siprec] Comments on draft-ietf-siprec-metadata-10. > > > > Hi, > > > > I just read through the draft-ietf-draft-siprec-metadata-10 and have > > the following comments. > > > > > > 1. Section 6.1.1 - The Start/End time is I assume the start/end time > of > > the RS not of the "Recording Session Object". > > > Your assumption is right. Recording session object start/end > time > is same as start/end time of RS. It is clarified in the draft as "In > cases > where Date header is not present, Start/End time are derivable from the > time at which SRS receives the notification of SIP message to setup RS > / > disconnect RS." > > > > 2. Section 6.1.2 - Whilst discussing the linkage between a RS and a > CSG > > states: > > > > "Also the allowance of zero instances is to accommodate persistent > > recording, where there may be none". I think this could be made a > bit > > clearer and suggest > > > > "Also the allowance of zero instances is to accommodate persistent > > recording, where there may be no CS or CSG in existence when the RS > is > > created". > > > Agreed >=20 > > 3. Section 6.2.1 Which discusses CS session attributes includes the > > following statement: "SRC (or SRS) is responsible for ensuring the > > uniqueness of Unique-ID in case multiple SRC interacts with the same > > SRS.". I don't see how the SRS can be responsible for this and think > > the statement is unnecessary and could simple be replaced with a > > reference to 6.10 which stated describes how unique-id's are created. > > > Agreed. SRS has to be remove. The updated text will look like > "SRC is responsible for ensuring the uniqueness of Unique-ID in case > multiple SRC interacts with the same SRS." >=20 Ok but still it really does not have anything to do with the case o= f multiple SRC's as the SRC is of course unaware that there is another SRC = so I still think we could just refer to section 6.10. . > > 4. Section 6.2.2 States "Each Communication Session Group object has > to > > be associated with one or more RS [Here each RS can be setup by the > > potentially different SRCs". Is it really the case that there can be > > more than one RS per CS Group? If it is because each RS can be > > established by different SRC's then I assume this should impact the > > object model which only describes the metadata generated by a single > > SRC. > > > Multiple SRC to SRS is supported in metadata model wherein how > SRC Communicate with each other for CSG/CS unique id is outside the > scope > of SIPREC. It is stated in both Sec 6.2.1 and Sec 6.2.2. Multiple RS > shall be associated with single CSG. I am not convinced that we can say anything about the multiple SRC c= ase other than making sure we keep the id's unique I don't think we said an= ything about this in the architecture draft. Can you describe the use case = and requirement that this covers. >=20 > > 5. Section 6.2.2 States "There is one or more Communication Sessions > > per CS Group [e.g. Consult Transfer]". I think we need more > explanation > > of scenarios in which a CS Group is applicable than just "E.g. > Consult > > Transfer". Can somebody provide a description of a basic scenario in > > which a CSG would be used? > > > Please let me whether it is sufficient to provide the CS group > usage in the example draft. In case you wish to see any specific text, > Please propose I need to understand further the use case(s) we are trying to cover= here can you start a separate thread on that and describe the use case. I = really don't think we can put "[e.g. Consult Transfer]" in the draft as thi= s is a service which is quite complex and can have many interpretations. We= need to be clearer about why we need the CSG and the potential use cases I= don't understand them myself. >=20 > > 6. Section 6.3.1 Communication Session Attributes. I think we need > more > > detail as to the format of the Termination Reason. It would probably > be > > useful to say that it is formatted according to the rules of RFC3326 > if > > that is the intention and give an example in section 7.1. > > > Reason XML element is a string which may be as per RFC 3326 > and > there is no Mandate to strictly follow RFC 3326Please let me whether it > is sufficient to provide the reason XML element usage in the example > draft. > Lets have a thread on that as well what is the purpose of the reaso= n attribute if it is just free form text it is I think more useful if we fo= llow a defined structure such as RFC3326 for this. >=20 > > 7. Section 6.3.1. The last paragraph which starts "This document does > > not specify attributes relating to what should happen to a recording > of > > a CS after it has been delivered..." does not appear to be useful to > me > > and could be removed. > > > This statement was added after long discussion in mailing > alias > and earlier IETF meeting about "when CS actually terminates". > The discussion happened very long back and in case it is required, I > will > Search for the archive to find the exact timeframe at which this > Statement was added But this statement seems to be about how long the SRS might retain = the recording which has nothing to do with metadata and I don't think it is= useful to put possible usages of extension data in the draft when any such= usage will be proprietary and not interoperable. I think this paragraph sh= ould be removed. >=20 > > 8. Section 6.3.2 "CS to have atleast zero or more participants" > should > > read "CS has zero or more participants". I started a separate thread > on > > a CS having zero particants. > I have proposed the statement/usecase for this usage in the > another mail thread. Let us close this open item in the another mail > thread >=20 > > > > 9. Section 6.5 states "A Participant class and its objects has > > information about a device..." I don't think it is necessarily > > information about a "device" which implies some kind of endpoint > device > > and a participant does not relate to a device in my mind. I think we > > should stick to the term "participant". > Agreed >=20 > > > > 10. Section 6.5.1 replace "Participant has attributes like" with > > "Replace with "A participant class has the following attributes:". > Agreed > > > > 11. Section 6.7.1. "A Media Stream class has the the following > > attributes:" - Remove duplicate "the". > Agreed >=20 > > > > 12. Section 7.1 claims to contain example usage of all the metadata > > attributes but I noted it does not contain a CS reason attribute. > > > reason is used during the termination of the session. The > Example usage is based on the CS initiation. Stop time usage is not > Shown for the same reason. I think that Sec 7.1 text has to be updated > to indicate that "CS initiation with complete metadata XML usage". > Also, please let me know whether you are interested in adding > one more example usage for the termination metadata XML usage Yes I would like to see example of the termination case and as my p= revious comment I think we should be more prescriptive about the format of = the termination reason >=20 > > 13. Can we change the name of the CS "reason" attribute to > > "terminationReason" or do we think it is too late to do that. > > > Reason XML element name is based on Reason SIP header and > I'm fine with your proposal of detailed name to avoid confusion. We > will ask more opinion before Changing as some SIPREC implementation may > have used this XML tag. I propose changing it we can start a thread on it if you like. . >=20 > > 14. Section 9 Security Considerations - Maybe we should make a > > reference to the protocol draft which specifies the security > > considerations for transporting the information certainly we should > not > > duplicate information already in the protocol draft. > > > I agree with you that security consideration has to be > updated. > I'm not very sure whether it is fine to have circular reference as > SIPREC metadata draft is referenced in the protocol draft. Also, > Protocol draft covers the complete RS with SDP, XML, RTP security > whereas > here, the interest is specific to XML schema. For me the security considerations don't relate to the schema but ho= w it is transported which is the responsibility of the protocol draft. . >=20 > > > > Regards > > Andy > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec