From partha@parthasarathi.co.in Tue Mar 5 09:45: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 1FF3911E80F9 for ; Tue, 5 Mar 2013 09:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHd6q-h5RqBC for ; Tue, 5 Mar 2013 09:45:50 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.156]) by ietfa.amsl.com (Postfix) with ESMTP id 95D6C11E80F8 for ; Tue, 5 Mar 2013 09:45:48 -0800 (PST) Received: from userPC (unknown [122.179.93.162]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 88316868566 for ; Tue, 5 Mar 2013 17:45:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1362505547; bh=a12FNu5odOXzTDYvmkgO8mpSsivU2B2yXtnn+JgbKLU=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=WCgM7WNJ3162IN0HdrlwgPSGQ+sdcywBiXt+Ay++k8QloMDqRwPVPxvFBgNnisAAx qPerw5DrTufKBJWcQsLpPAIhifk9LCMAUmYetT9UTMJfARoCpBkOh9UhKqUU5IgQmg B0DCMb2lVzyn85Bns5JEG0rtH8xEIV5vPQ666rk4= From: "Parthasarathi R" To: Date: Tue, 5 Mar 2013 23:15:44 +0530 Message-ID: <00d901ce19c9$4496af90$cdc40eb0$@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: Ac4Bbn8O/lGsxcy9QnSCjuKe+jbn4QYV7Bsw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.51362F4B.0116, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.152 Subject: [siprec] Reason element usage 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, 05 Mar 2013 17:45:55 -0000 Hi all, As per draft-ietf-siprec-metadata-11, Reason element is a string and not required to be as per RFC3326(SIP reason header). Could you please let us know your opinion whether SIPREC has to follow "reason" element as string or "reason" element has to be updated as per RFC 3326. Thanks Partha PS: See Sec 6.3.1 comment in the below mail for more details -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Saturday, February 02, 2013 11:25 PM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. Some comments inline. On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>> 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." >> > > Ok but still it really does not have anything to do with the case of 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. . IMO the point to get across is that multiple SRCs are *permitted* to refer to the same entities by using a common UUID. (The SRS must not consider this an error.) *How* the SRCs determine they are referring to the same entity and obtain the same UUID for it is out of scope for this document. Perhaps it would be better to discuss this in 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 case other than making sure we keep the id's unique I don't think we said anything about this in the architecture draft. Can you describe the use case and requirement that this covers. Same comment as above. >>> 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 reason attribute if it is just free form text it is I think more useful if we follow a defined structure such as RFC3326 for this. I agree this is worthy of some discussion as to whether 3326 is sufficient, or if we need a wider range of causes than that provides. I agree with Andy that just having a string, that might or might not be a standard string from 3326 is dubious. With that you can never be certain if the reason has the exact semantics of a 3326 reason. So I'm inclined to think we should be able to carry everything from a Reason header. >>> 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 should be removed. Certainly we can't enumerate all the things we *don't* cover. IIRC this was added because some people expected that we *would* include info about desired retention policy, and we wanted to make it clear that we were not. I see no harm in that. _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From mary.ietf.barnes@gmail.com Tue Mar 5 11:52:05 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 65B2711E80D3 for ; Tue, 5 Mar 2013 11:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.638 X-Spam-Level: X-Spam-Status: No, score=-103.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ulbbfiv0Imbh for ; Tue, 5 Mar 2013 11:52:04 -0800 (PST) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8186B21F862D for ; Tue, 5 Mar 2013 11:52:04 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id f6so4983445qej.29 for ; Tue, 05 Mar 2013 11:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Bbp3N76DGJGoILNGxlIkgTKGyaHPqiMaHGoQoOlGtp4=; b=XkF7qbsWgnPt15QncQDO/N7l5sWrsYLhg+9I/6WB9ifSvmSGQJO8CNioIpSQJjSD3Z Ozksv4cvcG3A76mTWTRTxw1HzuO/Rx2TOK1e3Sjfc0YhweQJgJ6J66OaMVSCsF9le3aA XXSdCR7jALtH3y40yCiqklECZ4U596/OP2rKgJ4RlMrU8aBNTpex0UZmwfYX+rQ93BKt hBA2PFF8vySK4nLczG0UNVec+RmMO0tMBC3ftYaDLnpqfKMeKCodk81V8Dh/IwGNNzHB VRoa5Hq2Vp2S495EUJRPj/HD5wKMXjAXld09knnGC7KDe+5Q4lipckgBVaxbzchGWI5P pZYQ== MIME-Version: 1.0 X-Received: by 10.224.216.65 with SMTP id hh1mr40280630qab.43.1362513121332; Tue, 05 Mar 2013 11:52:01 -0800 (PST) Received: by 10.49.24.130 with HTTP; Tue, 5 Mar 2013 11:52:01 -0800 (PST) In-Reply-To: <00d901ce19c9$4496af90$cdc40eb0$@co.in> References: <00d901ce19c9$4496af90$cdc40eb0$@co.in> Date: Tue, 5 Mar 2013 13:52:01 -0600 Message-ID: From: Mary Barnes To: Parthasarathi R Content-Type: text/plain; charset=ISO-8859-1 Cc: "siprec@ietf.org" Subject: Re: [siprec] Reason element usage 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, 05 Mar 2013 19:52:05 -0000 I think it would be better to follow the format of the Reason header field as defined in RFC 3326. Mary. On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R wrote: > Hi all, > > As per draft-ietf-siprec-metadata-11, Reason element is a string and not > required to be as per RFC3326(SIP reason header). Could you please let us > know your opinion whether SIPREC has to follow "reason" element as string or > "reason" element has to be updated as per RFC 3326. > > Thanks > Partha > > PS: See Sec 6.3.1 comment in the below mail for more details > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Saturday, February 02, 2013 11:25 PM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. > > Some comments inline. > > On 1/29/13 11:32 AM, Hutton, Andrew wrote: > >>>> 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." >>> >> >> Ok but still it really does not have anything to do with the case > of 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. . > > IMO the point to get across is that multiple SRCs are *permitted* to > refer to the same entities by using a common UUID. (The SRS must not > consider this an error.) *How* the SRCs determine they are referring to > the same entity and obtain the same UUID for it is out of scope for this > document. > > Perhaps it would be better to discuss this in 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 > case other than making sure we keep the id's unique I don't think we said > anything about this in the architecture draft. Can you describe the use case > and requirement that this covers. > > Same comment as above. > >>>> 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 > reason attribute if it is just free form text it is I think more useful if > we follow a defined structure such as RFC3326 for this. > > I agree this is worthy of some discussion as to whether 3326 is > sufficient, or if we need a wider range of causes than that provides. > > I agree with Andy that just having a string, that might or might not be > a standard string from 3326 is dubious. With that you can never be > certain if the reason has the exact semantics of a 3326 reason. > > So I'm inclined to think we should be able to carry everything from a > Reason header. > >>>> 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 > should be removed. > > Certainly we can't enumerate all the things we *don't* cover. > IIRC this was added because some people expected that we *would* include > info about desired retention policy, and we wanted to make it clear that > we were not. I see no harm in that. > > > _______________________________________________ > 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 Wed Mar 6 07:43:22 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 97EEF21F8C55 for ; Wed, 6 Mar 2013 07:43:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTQjC40fUm2E for ; Wed, 6 Mar 2013 07:43:21 -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 6B63021F8C46 for ; Wed, 6 Mar 2013 07:43:21 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id AD7E31EB8502; Wed, 6 Mar 2013 16:43:20 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 16:43:20 +0100 From: "Hutton, Andrew" To: Mary Barnes , Parthasarathi R Thread-Topic: [siprec] Reason element usage Thread-Index: AQHOGdrrhW77oAEmYUOEPqeSP98qlJiYzsnw Date: Wed, 6 Mar 2013 15:43:19 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0688BCBC@MCHP04MSX.global-ad.net> References: <00d901ce19c9$4496af90$cdc40eb0$@co.in> In-Reply-To: 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 Cc: "siprec@ietf.org" Subject: Re: [siprec] Reason element usage 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, 06 Mar 2013 15:43:22 -0000 +1 Andy (As an individual). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: 05 March 2013 19:52 > To: Parthasarathi R > Cc: siprec@ietf.org > Subject: Re: [siprec] Reason element usage >=20 > I think it would be better to follow the format of the Reason header > field as defined in RFC 3326. >=20 > Mary. >=20 > On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R > wrote: > > Hi all, > > > > As per draft-ietf-siprec-metadata-11, Reason element is a string and > not > > required to be as per RFC3326(SIP reason header). Could you please > let us > > know your opinion whether SIPREC has to follow "reason" element as > string or > > "reason" element has to be updated as per RFC 3326. > > > > Thanks > > Partha > > > > PS: See Sec 6.3.1 comment in the below mail for more details > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of > > Paul Kyzivat > > Sent: Saturday, February 02, 2013 11:25 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. > > > > Some comments inline. > > > > On 1/29/13 11:32 AM, Hutton, Andrew wrote: > > > >>>> 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." > >>> > >> > >> Ok but still it really does not have anything to do with the > case > > of 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. . > > > > IMO the point to get across is that multiple SRCs are *permitted* to > > refer to the same entities by using a common UUID. (The SRS must not > > consider this an error.) *How* the SRCs determine they are referring > to > > the same entity and obtain the same UUID for it is out of scope for > this > > document. > > > > Perhaps it would be better to discuss this in 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 > > case other than making sure we keep the id's unique I don't think we > said > > anything about this in the architecture draft. Can you describe the > use case > > and requirement that this covers. > > > > Same comment as above. > > > >>>> 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 > > reason attribute if it is just free form text it is I think more > useful if > > we follow a defined structure such as RFC3326 for this. > > > > I agree this is worthy of some discussion as to whether 3326 is > > sufficient, or if we need a wider range of causes than that provides. > > > > I agree with Andy that just having a string, that might or might not > be > > a standard string from 3326 is dubious. With that you can never be > > certain if the reason has the exact semantics of a 3326 reason. > > > > So I'm inclined to think we should be able to carry everything from a > > Reason header. > > > >>>> 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 > > should be removed. > > > > Certainly we can't enumerate all the things we *don't* cover. > > IIRC this was added because some people expected that we *would* > include > > info about desired retention policy, and we wanted to make it clear > that > > we were not. I see no harm in that. > > > > > > _______________________________________________ > > 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 Wed Mar 6 07:45:10 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 4196621F8A4A for ; Wed, 6 Mar 2013 07:45:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvWQ4blA1GfN for ; Wed, 6 Mar 2013 07:45:07 -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 AE91521F8995 for ; Wed, 6 Mar 2013 07:45:07 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 26FEC1EB85E9 for ; Wed, 6 Mar 2013 16:45:07 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 16:45:06 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC Draft IETF86 Agenda. Thread-Index: Ac4UXWFQJWz4BmZ1RiiH4gyte7tguQGJBJ8w Date: Wed, 6 Mar 2013 15:45:06 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0688BCE7@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF014048E7@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF014048E7@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: Re: [siprec] SIPREC Draft IETF86 Agenda. 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, 06 Mar 2013 15:45:10 -0000 Agenda for next week's meeting has been updated with the remote participati= on details. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: 26 February 2013 20:11 > To: Alan Johnston; Paul Kyzivat; Charles Eckel (eckelcu) > Cc: siprec@ietf.org > Subject: [siprec] SIPREC Draft IETF86 Agenda. >=20 > A draft IETF86 SIPREC agenda has been posted at > http://www.ietf.org/proceedings/86/agenda/agenda-86-siprec. >=20 > Alan, Paul and Charles please check you are ok with this and remember > we need slides before the meeting if at all possible especially since > we are in the first half of the week this time. >=20 > Regards > Andy (SIPREC Co-Chair). > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Wed Mar 6 10:00:03 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 B58EE21F8758 for ; Wed, 6 Mar 2013 10:00:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TYdI9qQLnQt for ; Wed, 6 Mar 2013 09:59:59 -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 3963A21F8606 for ; Wed, 6 Mar 2013 09:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7453; q=dns/txt; s=iport; t=1362592799; x=1363802399; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=a90wSUEgZ8v03CRMgeSEGfA+RztQObJOfNg2id/9jDI=; b=h0SQ7cbFe7qDPJv+zvDxoFz5BjLdPDEmHT2IyJW4ckBoORH+S2tceeRu ahJKLJJ1daFoxAT01Am4+jV16+tVXtnn4mKCd+h3xikMkvsGsSakh9nb+ iT8Xl1ffCqhoNPxejamv6qbGb9AWOfuSi0moskxeMJx6RLxLyMADaEl40 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALqDN1GtJXHA/2dsb2JhbABExEaBWhZzgioBAQEDAQEBATc0CwUHBgEIEQEDAQEBChQJLgsUAwYIAgQBDQUIiAUGDLxrBI1bgQAGIAsHBoJZYQOnO4MIgXI1 X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208";a="184492027" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 06 Mar 2013 17:59:58 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r26Hxwr8026182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Mar 2013 17:59:58 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 11:59:58 -0600 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , Mary Barnes , Parthasarathi R Thread-Topic: [siprec] Reason element usage Thread-Index: AQHOGpRqRY/lxeg0AEulbk1nJCQdvA== Date: Wed, 6 Mar 2013 17:59:58 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0688BCBC@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.78.194] Content-Type: text/plain; charset="us-ascii" Content-ID: <92DA54B1B2711E4CB3F886C50A0A4EB3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Reason element usage 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, 06 Mar 2013 18:00:03 -0000 +1 I also prefer to have the format of the Reason header field as defined in RFC 3326 rather than just having as "string". Regards, Ram > On 06/03/13 9:13 PM, "Hutton, Andrew" > wrote: >+1 > >Andy (As an individual). > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Mary Barnes >> Sent: 05 March 2013 19:52 >> To: Parthasarathi R >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Reason element usage >>=20 >> I think it would be better to follow the format of the Reason header >> field as defined in RFC 3326. >>=20 >> Mary. >>=20 >> On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R >> wrote: >> > Hi all, >> > >> > As per draft-ietf-siprec-metadata-11, Reason element is a string and >> not >> > required to be as per RFC3326(SIP reason header). Could you please >> let us >> > know your opinion whether SIPREC has to follow "reason" element as >> string or >> > "reason" element has to be updated as per RFC 3326. >> > >> > Thanks >> > Partha >> > >> > PS: See Sec 6.3.1 comment in the below mail for more details >> > >> > -----Original Message----- >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of >> > Paul Kyzivat >> > Sent: Saturday, February 02, 2013 11:25 PM >> > To: siprec@ietf.org >> > Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >> > >> > Some comments inline. >> > >> > On 1/29/13 11:32 AM, Hutton, Andrew wrote: >> > >> >>>> 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." >> >>> >> >> >> >> Ok but still it really does not have anything to do with the >> case >> > of 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. . >> > >> > IMO the point to get across is that multiple SRCs are *permitted* to >> > refer to the same entities by using a common UUID. (The SRS must not >> > consider this an error.) *How* the SRCs determine they are referring >> to >> > the same entity and obtain the same UUID for it is out of scope for >> this >> > document. >> > >> > Perhaps it would be better to discuss this in 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 >> > case other than making sure we keep the id's unique I don't think we >> said >> > anything about this in the architecture draft. Can you describe the >> use case >> > and requirement that this covers. >> > >> > Same comment as above. >> > >> >>>> 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 >> > reason attribute if it is just free form text it is I think more >> useful if >> > we follow a defined structure such as RFC3326 for this. >> > >> > I agree this is worthy of some discussion as to whether 3326 is >> > sufficient, or if we need a wider range of causes than that provides. >> > >> > I agree with Andy that just having a string, that might or might not >> be >> > a standard string from 3326 is dubious. With that you can never be >> > certain if the reason has the exact semantics of a 3326 reason. >> > >> > So I'm inclined to think we should be able to carry everything from a >> > Reason header. >> > >> >>>> 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 >> > should be removed. >> > >> > Certainly we can't enumerate all the things we *don't* cover. >> > IIRC this was added because some people expected that we *would* >> include >> > info about desired retention policy, and we wanted to make it clear >> that >> > we were not. I see no harm in that. >> > >> > >> > _______________________________________________ >> > 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 partha@parthasarathi.co.in Thu Mar 7 09:08: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 9ACB721F8AD8 for ; Thu, 7 Mar 2013 09:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EebkIBLRG9Pb for ; Thu, 7 Mar 2013 09:08:15 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 80E0D21F8AD1 for ; Thu, 7 Mar 2013 09:08:11 -0800 (PST) Received: from userPC (unknown [122.179.37.91]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 573DD19080AD; Thu, 7 Mar 2013 17:08:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1362676091; bh=CouVe8FymMUMmjHPeDk918HddKnjBedBGwCv8IYSHNc=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CLrh1ebuy1OHVwGkHbKldYGMs04hucz+Y7/8gDaLQzO1K4wBVFXZR6cuEM8NFhNn2 jPvQJqU5pZW1XyvEr2sXAPcz1FUPl2GlnTthQrMjVTxlnI0wpbzZwzQB/vphleSZ4G gE24lsfuecxR0Vfv6VvRhJUTnxPC2JsTTg2FI4vM= From: "Parthasarathi R" To: "'Paul Kyzivat'" , , "'Hutton, Andrew'" References: <9F33F40F6F2CD847824537F3C4E37DDF013A504B@MCHP04MSX.global-ad.net> <000001cdf0e5$2cebf290$86c3d7b0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF013C7313@MCHP04MSX.global-ad.net> <510D530F.8060108@alum.mit.edu> In-Reply-To: <510D530F.8060108@alum.mit.edu> Date: Thu, 7 Mar 2013 22:38:00 +0530 Message-ID: <005301ce1b56$56a75f70$03f61e50$@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: Ac4Bbn8O/lGsxcy9QnSCjuKe+jbn4QZ5xytg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0208.5138C97B.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Subject: [siprec] Common unique-id from multiple SRC to SRS [was RE: 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: Thu, 07 Mar 2013 17:08:16 -0000 Andy, Sorry for the delay reply. As Paul mentioned, common unique-id from multiple SRC to SRS shall be discussed in Sec 6.10. The point to be noted is that SRS should be in the position to receive the common unique-id from multiple SRC and how unique-id is exchanged between SRCs is outside the scope of SIPREC. Please let us know in case you have any concern in this approach. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Saturday, February 02, 2013 11:25 PM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. > > Some comments inline. > > On 1/29/13 11:32 AM, Hutton, Andrew wrote: > > >>> 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." > >> > > > > Ok but still it really does not have anything to do with the > case of 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. > . > > IMO the point to get across is that multiple SRCs are *permitted* to > refer to the same entities by using a common UUID. (The SRS must not > consider this an error.) *How* the SRCs determine they are referring to > the same entity and obtain the same UUID for it is out of scope for > this > document. > > Perhaps it would be better to discuss this in 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 case other than making sure we keep the id's unique I don't think > we said anything about this in the architecture draft. Can you describe > the use case and requirement that this covers. > > Same comment as above. > > >>> 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 > reason attribute if it is just free form text it is I think more useful > if we follow a defined structure such as RFC3326 for this. > > I agree this is worthy of some discussion as to whether 3326 is > sufficient, or if we need a wider range of causes than that provides. > > I agree with Andy that just having a string, that might or might not be > a standard string from 3326 is dubious. With that you can never be > certain if the reason has the exact semantics of a 3326 reason. > > So I'm inclined to think we should be able to carry everything from a > Reason header. > > >>> 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 should be removed. > > Certainly we can't enumerate all the things we *don't* cover. > IIRC this was added because some people expected that we *would* > include > info about desired retention policy, and we wanted to make it clear > that > we were not. I see no harm in that. > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partha@parthasarathi.co.in Thu Mar 7 09:19:28 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 C5B6521F89DC for ; Thu, 7 Mar 2013 09:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoZ8Dz-4eofH for ; Thu, 7 Mar 2013 09:19:27 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8021F89C7 for ; Thu, 7 Mar 2013 09:19:24 -0800 (PST) Received: from userPC (unknown [122.179.37.91]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 91A0B1EBFCE4; Thu, 7 Mar 2013 17:19:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1362676764; bh=GZwmqx3zQLwnU44xFHBWgqMRB/okJUKA1uV0Qec1t8w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=PwP30dShIHLTxYS2yPN6PmKG9458P/q6sdSRLlwE2lTi2njn3boa7+0syTBnOmeQG RIJpH86cnwDL/ssnsLBlrGEdgf3iz25yaZ9wPWIMQjsjhLEtyLYJG8vszhm0Ko+EAm lLM6VGE1XOvPhmxwGqYPnKAsVr1baMWwtOYZaSXg= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , "'Hutton, Andrew'" , "'Mary Barnes'" References: <9F33F40F6F2CD847824537F3C4E37DDF0688BCBC@MCHP04MSX.global-ad.net> In-Reply-To: Date: Thu, 7 Mar 2013 22:49:13 +0530 Message-ID: <005401ce1b57$e7887eb0$b6997c10$@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: AQHOGpRqRY/lxeg0AEulbk1nJCQdvJiaebBg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.5138CC1C.0099, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: siprec@ietf.org Subject: Re: [siprec] Reason element usage 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, 07 Mar 2013 17:19:28 -0000 Hi all, Please let us know in case anybody has objection for mandating reason element format as defined in SIP reason header (RFC 3326) only. Thanks Partha > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Wednesday, March 06, 2013 11:30 PM > To: Hutton, Andrew; Mary Barnes; Parthasarathi R > Cc: siprec@ietf.org > Subject: Re: [siprec] Reason element usage > > +1 > > I also prefer to have the format of the Reason header field as defined > in > RFC 3326 rather than just having as "string". > > Regards, > Ram > > > > > On 06/03/13 9:13 PM, "Hutton, Andrew" > > wrote: > > >+1 > > > >Andy (As an individual). > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Mary Barnes > >> Sent: 05 March 2013 19:52 > >> To: Parthasarathi R > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] Reason element usage > >> > >> I think it would be better to follow the format of the Reason header > >> field as defined in RFC 3326. > >> > >> Mary. > >> > >> On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R > >> wrote: > >> > Hi all, > >> > > >> > As per draft-ietf-siprec-metadata-11, Reason element is a string > and > >> not > >> > required to be as per RFC3326(SIP reason header). Could you please > >> let us > >> > know your opinion whether SIPREC has to follow "reason" element as > >> string or > >> > "reason" element has to be updated as per RFC 3326. > >> > > >> > Thanks > >> > Partha > >> > > >> > PS: See Sec 6.3.1 comment in the below mail for more details > >> > > >> > -----Original Message----- > >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of > >> > Paul Kyzivat > >> > Sent: Saturday, February 02, 2013 11:25 PM > >> > To: siprec@ietf.org > >> > Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. > >> > > >> > Some comments inline. > >> > > >> > On 1/29/13 11:32 AM, Hutton, Andrew wrote: > >> > > >> >>>> 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." > >> >>> > >> >> > >> >> Ok but still it really does not have anything to do with > the > >> case > >> > of 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. . > >> > > >> > IMO the point to get across is that multiple SRCs are *permitted* > to > >> > refer to the same entities by using a common UUID. (The SRS must > not > >> > consider this an error.) *How* the SRCs determine they are > referring > >> to > >> > the same entity and obtain the same UUID for it is out of scope > for > >> this > >> > document. > >> > > >> > Perhaps it would be better to discuss this in 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 > >> > case other than making sure we keep the id's unique I don't think > we > >> said > >> > anything about this in the architecture draft. Can you describe > the > >> use case > >> > and requirement that this covers. > >> > > >> > Same comment as above. > >> > > >> >>>> 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 > >> > reason attribute if it is just free form text it is I think more > >> useful if > >> > we follow a defined structure such as RFC3326 for this. > >> > > >> > I agree this is worthy of some discussion as to whether 3326 is > >> > sufficient, or if we need a wider range of causes than that > provides. > >> > > >> > I agree with Andy that just having a string, that might or might > not > >> be > >> > a standard string from 3326 is dubious. With that you can never be > >> > certain if the reason has the exact semantics of a 3326 reason. > >> > > >> > So I'm inclined to think we should be able to carry everything > from a > >> > Reason header. > >> > > >> >>>> 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 > >> > should be removed. > >> > > >> > Certainly we can't enumerate all the things we *don't* cover. > >> > IIRC this was added because some people expected that we *would* > >> include > >> > info about desired retention policy, and we wanted to make it > clear > >> that > >> > we were not. I see no harm in that. > >> > > >> > > >> > _______________________________________________ > >> > 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 Mar 7 09:42:52 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 1B69421F8A5A for ; Thu, 7 Mar 2013 09:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkwkyPlt7w5C for ; Thu, 7 Mar 2013 09:42:51 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDF921F8A51 for ; Thu, 7 Mar 2013 09:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1807; q=dns/txt; s=iport; t=1362678171; x=1363887771; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=abL/dBiHiiwhjcvXDSQ/fxi/VcR8Q3Q/ap7tTla0Of4=; b=PAFiFTYRHKd/jSKqfGdofIcBqD36cNPiDi3pRwovjjCqc47fxk5djS0i IVCFiVDNB8uyUjJySaozeoN+r4RCq7b16UzU7SbEGQr1d8vvy2qDcC4qa YKtZVjx7fbhvMvi5m1/KwTY5jEQpjpK8ZYfg9fBO1vnXMXepPkZvbNhrC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHLQOFGtJV2Y/2dsb2JhbABDxEmBYRZ0giwBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAQEEAQ0FCAGICQEMuxOOWyYLBwaCWWEDkweUNYMJgic X-IronPort-AV: E=Sophos;i="4.84,803,1355097600"; d="scan'208";a="184936748" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 07 Mar 2013 17:42:51 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r27Hgonc030321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Mar 2013 17:42:50 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 11:42:51 -0600 From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: SIPREC Draft IETF86 Agenda. Thread-Index: Ac4UXWFQJWz4BmZ1RiiH4gyte7tguQGJBJ8wADZFVwA= Date: Thu, 7 Mar 2013 17:42:49 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047C8B38@xmb-aln-x08.cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF014048E7@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0688BCE7@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0688BCE7@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.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] SIPREC Draft IETF86 Agenda. 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, 07 Mar 2013 17:42:52 -0000 Hi Andy, I have not seen Alan's presentation yet, nor have I seen my own presentatio= n (better get working on that). However, my expectation is that mine will = cover changes to the document addressing comments and consensus reached dur= ing and after IETF 85 , whereas Alan's will cover the remaining known issue= that we still need to address. That being the case, I think we should swap= the order of our presentations. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Hutton, Andrew > Sent: Wednesday, March 06, 2013 7:45 AM > To: siprec@ietf.org > Subject: Re: [siprec] SIPREC Draft IETF86 Agenda. >=20 > Agenda for next week's meeting has been updated with the remote > participation details. >=20 > Regards > Andy >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: 26 February 2013 20:11 > > To: Alan Johnston; Paul Kyzivat; Charles Eckel (eckelcu) > > Cc: siprec@ietf.org > > Subject: [siprec] SIPREC Draft IETF86 Agenda. > > > > A draft IETF86 SIPREC agenda has been posted at > > http://www.ietf.org/proceedings/86/agenda/agenda-86-siprec. > > > > Alan, Paul and Charles please check you are ok with this and remember > > we need slides before the meeting if at all possible especially since > > we are in the first half of the week this time. > > > > Regards > > Andy (SIPREC Co-Chair). > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Mar 7 11:57:19 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 8776121F89AE for ; Thu, 7 Mar 2013 11:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4bctgL-yFrT for ; Thu, 7 Mar 2013 11:57:18 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 7B55921F8996 for ; Thu, 7 Mar 2013 11:57:18 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id 8fL51l00D1vXlb851jxHaB; Thu, 07 Mar 2013 19:57:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 8jxH1l00V3ZTu2S3djxHZB; Thu, 07 Mar 2013 19:57:17 +0000 Message-ID: <5138F11D.9000104@alum.mit.edu> Date: Fri, 08 Mar 2013 03:57:17 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: siprec@ietf.org References: <00d901ce19c9$4496af90$cdc40eb0$@co.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362686237; bh=VDV8xIdqTfCaWrfRDY9xnyHiLk5NDd1DKOYlFqwRRnM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JIg+3ioHddzW/Z6a2NKy2meD+8S8M+BRUqM3TD3h76FTHDTmm2T1ZR4aWGb1jyczg cLD/fahFy8QlND2Dwr+bhoyh9nPXElCCQYL/Q445gTYrjcAIW0lkm02ZM2j7lEvkHT oqDTQSHeVo9PWI3+eRhUzPg4mLeHAdVHfJGdlaQdtf96nNK7RhwPFBKhLVVO5Uv1d8 GxXS/t2J4CjGnCZDrEuAZ33sawtaBEAEnsvPRFMfbidcWq7/MS/2ZCK50O7T039lQ+ 1ZR7TzIE2tKI9HfrMDql+3hlGl63rQoVfFRMtCqdAbVxPecaTg+y+99zsK4XoA88AR ZbEWqscfg8aew== Subject: Re: [siprec] Reason element usage 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, 07 Mar 2013 19:57:19 -0000 I have some questions about this idea. What is the goal? How closely do you want to follow the Reason header (RFC3326)? - 3326 doesn't use xml, so at best it provides a conceptual model. - each reason-value consists of a protocol name, cause number for that protocol, and some text. The currently defined protocols are SIP and Q.850. But I don't think either the SIP or Q.850 causes will make any sense for siprec. - 3326 allows multiple reason-values. I doubt that makes any sense for siprec. So I *think* what people mean when they say to copy the reason header is that we should provide both a machine-understandable numeric value plus a human-friendly text value. But then we will need to define our own numeric values. Unfortunately, doing that means that we need to open up discussion about what numeric values we should define. Maybe that will be a useful discussion, maybe not. But it will take some time. Is it worth it? Or can we live with a string? I don't think we expect any programatic recovery action, so a machine readable value isn't so important. Thanks, Paul On 3/6/13 3:52 AM, Mary Barnes wrote: > I think it would be better to follow the format of the Reason header > field as defined in RFC 3326. > > Mary. > > On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R > wrote: >> Hi all, >> >> As per draft-ietf-siprec-metadata-11, Reason element is a string and not >> required to be as per RFC3326(SIP reason header). Could you please let us >> know your opinion whether SIPREC has to follow "reason" element as string or >> "reason" element has to be updated as per RFC 3326. >> >> Thanks >> Partha >> >> PS: See Sec 6.3.1 comment in the below mail for more details >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Saturday, February 02, 2013 11:25 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >> >> Some comments inline. >> >> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >> >>>>> 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." >>>> >>> >>> Ok but still it really does not have anything to do with the case >> of 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. . >> >> IMO the point to get across is that multiple SRCs are *permitted* to >> refer to the same entities by using a common UUID. (The SRS must not >> consider this an error.) *How* the SRCs determine they are referring to >> the same entity and obtain the same UUID for it is out of scope for this >> document. >> >> Perhaps it would be better to discuss this in 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 >> case other than making sure we keep the id's unique I don't think we said >> anything about this in the architecture draft. Can you describe the use case >> and requirement that this covers. >> >> Same comment as above. >> >>>>> 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 >> reason attribute if it is just free form text it is I think more useful if >> we follow a defined structure such as RFC3326 for this. >> >> I agree this is worthy of some discussion as to whether 3326 is >> sufficient, or if we need a wider range of causes than that provides. >> >> I agree with Andy that just having a string, that might or might not be >> a standard string from 3326 is dubious. With that you can never be >> certain if the reason has the exact semantics of a 3326 reason. >> >> So I'm inclined to think we should be able to carry everything from a >> Reason header. >> >>>>> 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 >> should be removed. >> >> Certainly we can't enumerate all the things we *don't* cover. >> IIRC this was added because some people expected that we *would* include >> info about desired retention policy, and we wanted to make it clear that >> we were not. I see no harm in that. >> >> >> _______________________________________________ >> 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 Fri Mar 8 03:20:24 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 86DD021F85B8 for ; Fri, 8 Mar 2013 03:20:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLtNH1qAYesf for ; Fri, 8 Mar 2013 03:20:24 -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 BDD1721F850F for ; Fri, 8 Mar 2013 03:20:23 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8384B23F05D1; Fri, 8 Mar 2013 12:20:22 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Fri, 8 Mar 2013 12:20:22 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" Thread-Topic: SIPREC Draft IETF86 Agenda. Thread-Index: Ac4UXWFQJWz4BmZ1RiiH4gyte7tguQGJBJ8wADZFVwAAJRijkw== Date: Fri, 8 Mar 2013 11:20:21 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF014048E7@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0688BCE7@MCHP04MSX.global-ad.net>, <92B7E61ADAC1BB4F941F943788C08828047C8B38@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047C8B38@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC Draft IETF86 Agenda. 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, 08 Mar 2013 11:20:24 -0000 Hi Charles, I will swap the slots in the agenda. Andy On 7 Mar 2013, at 17:42, "Charles Eckel (eckelcu)" wrot= e: > Hi Andy, >=20 > I have not seen Alan's presentation yet, nor have I seen my own presentat= ion (better get working on that). However, my expectation is that mine wil= l cover changes to the document addressing comments and consensus reached d= uring and after IETF 85 , whereas Alan's will cover the remaining known iss= ue that we still need to address. That being the case, I think we should sw= ap the order of our presentations. >=20 > Cheers, > Charles >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >> Of Hutton, Andrew >> Sent: Wednesday, March 06, 2013 7:45 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] SIPREC Draft IETF86 Agenda. >>=20 >> Agenda for next week's meeting has been updated with the remote >> participation details. >>=20 >> Regards >> Andy >>=20 >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: 26 February 2013 20:11 >>> To: Alan Johnston; Paul Kyzivat; Charles Eckel (eckelcu) >>> Cc: siprec@ietf.org >>> Subject: [siprec] SIPREC Draft IETF86 Agenda. >>>=20 >>> A draft IETF86 SIPREC agenda has been posted at >>> http://www.ietf.org/proceedings/86/agenda/agenda-86-siprec. >>>=20 >>> Alan, Paul and Charles please check you are ok with this and remember >>> we need slides before the meeting if at all possible especially since >>> we are in the first half of the week this time. >>>=20 >>> Regards >>> Andy (SIPREC Co-Chair). >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Sat Mar 9 04:26:19 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 F3EC721F8606 for ; Sat, 9 Mar 2013 04:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9UtM2qsMJv7 for ; Sat, 9 Mar 2013 04:26:18 -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 738C521F8460 for ; Sat, 9 Mar 2013 04:26:18 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 1DA0F1EB85F9 for ; Sat, 9 Mar 2013 13:26:17 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Sat, 9 Mar 2013 13:26:16 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Call Hold / Mute etc, Thread-Index: Ac4cMeYcP5V7UHt5QoqIt6bze2tKQQ== Date: Sat, 9 Mar 2013 12:26:15 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06891325@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] Call Hold / Mute etc, 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, 09 Mar 2013 12:26:19 -0000 Hi, Section 3.3 of draft-ram-siprec-call-flows gives an example of a hold/resum= e on the CS and how it is reflected on the RS and it shows the SDP in the R= S being set to a=3Dinactive for a participant. This does not seem to be consistent with draft-ietf-siprec-protocol which i= n section 7.1.1.1 states: " Note that when a CS stream is muted/unmuted, this information is conveyed in the metadata by the SRC. The SRC SHOULD NOT modify the media stream with a=3Dinactive for mute since this operation is reserved for pausing the RS media." Is this an inconsistency and how exactly is the muted/unmuted indication co= nveyed in metadata I could not find this in the metadata draft. Regards Andy From rmohanr@cisco.com Sat Mar 9 08:00: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 7553321F8681 for ; Sat, 9 Mar 2013 08:00:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QnNRiXA37Ag for ; Sat, 9 Mar 2013 08:00:42 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE0421F866F for ; Sat, 9 Mar 2013 08:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7152; q=dns/txt; s=iport; t=1362844842; x=1364054442; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PIYNPhlklI+H9AdjtgmYXxGV6cc1dnhxp6ENSdZ7qDQ=; b=g/CQRQYXo61i7AVBMVSzDGTWn1kjBPhcasSBtuZ9efFoEF5M+oKg1x8A ayC578L0NldWHW0dwieGkduk3jZf5x5k84zvML2rKqN/RfOnAmiberpBI QYCk3cXF+EAL7b4hCQPH4mDoH+Ew3twMrMiHNkQ/sVam/d9uNDGnFyWY9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOhbO1GtJXG//2dsb2JhbABDxGCBXxZtB4ItAQEBAwEBAQE3NBAHBgEIEQEDAQEBChQFBC4LFAMGCAIEEwgTh3IGDJpnoFsEjlsGIBIGgllhA6dHgVSBNoIn X-IronPort-AV: E=Sophos;i="4.84,814,1355097600"; d="scan'208";a="185694138" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 09 Mar 2013 16:00:41 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r29G0fcS005088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 9 Mar 2013 16:00:41 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Sat, 9 Mar 2013 10:00:40 -0600 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] Common unique-id from multiple SRC to SRS [was RE: Comments on draft-ietf-siprec-metadata-10.] Thread-Index: AQHOHN8+Pzm+iYfF6UCYgBtOnVo8+g== Date: Sat, 9 Mar 2013 16:00:39 +0000 Message-ID: In-Reply-To: <005301ce1b56$56a75f70$03f61e50$@co.in> 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.72.221] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A17DD5FD4769941BDFD6AA8B5EF9185@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was RE: 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, 09 Mar 2013 16:00:43 -0000 Getting back late on this. I see Andy's question here is I am not convinced that we can say anything about the multiple SRC case other than making sure we keep the id's unique I don't think we said anything about this in the architecture draft. Can you describe the use case and requirement that this covers. I think there would definitely be use-cases in real deployments where there would be multiple SRCs for a single CS. A simplest use-case that I have heard many times is recording solution for Financial trading centers where they prefer to have redundant recordings (recorded to different geographical sites). In such flows we *may* have multiple SRC's each having its own RS and recording the same CS. A simple scenario being both endpoints of a CS acting as SRC. You can visualize this to the section 3.1.2 of architecture draft with both endpoints having RS. Ram > On 07/03/13 10:38 PM, "Parthasarathi R" >wrote: >Andy, > >Sorry for the delay reply. As Paul mentioned, common unique-id from >multiple >SRC to SRS shall be discussed in Sec 6.10. The point to be noted is that >SRS >should be in the position to receive the common unique-id from multiple >SRC >and how unique-id is exchanged between SRCs is outside the scope of >SIPREC. >Please let us know in case you have any concern in this approach. > >Thanks >Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Saturday, February 02, 2013 11:25 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >>=20 >> Some comments inline. >>=20 >> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>=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." >> >> >> > >> > Ok but still it really does not have anything to do with the >> case of 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. >> . >>=20 >> IMO the point to get across is that multiple SRCs are *permitted* to >> refer to the same entities by using a common UUID. (The SRS must not >> consider this an error.) *How* the SRCs determine they are referring to >> the same entity and obtain the same UUID for it is out of scope for >> this >> document. >>=20 >> Perhaps it would be better to discuss this in 6.10. >>=20 >> >>> 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 case other than making sure we keep the id's unique I don't think >> we said anything about this in the architecture draft. Can you describe >> the use case and requirement that this covers. >>=20 >> Same comment as above. >>=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 >> reason attribute if it is just free form text it is I think more useful >> if we follow a defined structure such as RFC3326 for this. >>=20 >> I agree this is worthy of some discussion as to whether 3326 is >> sufficient, or if we need a wider range of causes than that provides. >>=20 >> I agree with Andy that just having a string, that might or might not be >> a standard string from 3326 is dubious. With that you can never be >> certain if the reason has the exact semantics of a 3326 reason. >>=20 >> So I'm inclined to think we should be able to carry everything from a >> Reason header. >>=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 should be removed. >>=20 >> Certainly we can't enumerate all the things we *don't* cover. >> IIRC this was added because some people expected that we *would* >> include >> info about desired retention policy, and we wanted to make it clear >> that >> we were not. I see no harm in that. >>=20 >>=20 >> _______________________________________________ >> 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 rmohanr@cisco.com Sat Mar 9 08:09:14 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 00F7D21F848A for ; Sat, 9 Mar 2013 08:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfoJzz-3c8HO for ; Sat, 9 Mar 2013 08:09:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 49DA921F84A2 for ; Sat, 9 Mar 2013 08:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1368; q=dns/txt; s=iport; t=1362845353; x=1364054953; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=iCWMH2+6S74/YRM7lO2Vsv6UAZ6s+T3H5S5dJe+ezdg=; b=R/gjcNu+fTvxcXClR65EDciD2GdzCvbpYTE3VM8L0bSXArN8vxLSitJu PTyu93tz54f62px8VXoA7IPSMlCHw+M6YXDlhkSRr+l7+XThNSojl7F+0 PxqvmPu7ibNaQQQMw3T+Uk32dtBnS4o78qS5CWw5MdqkYzkMVVVLzENyU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKpdO1GtJXHA/2dsb2JhbABDxGCBXxZ0gi0BAQEDAQEBATc0EA0BCCIUNwslAgQBEgiIBQYMuz4Ejls4gl9hA6dHgwqCJw X-IronPort-AV: E=Sophos;i="4.84,814,1355097600"; d="scan'208";a="185638186" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 09 Mar 2013 16:09:13 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r29G9C8S014721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Mar 2013 16:09:12 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sat, 9 Mar 2013 10:09:00 -0600 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] Call Hold / Mute etc, Thread-Index: AQHOHOBoQwXAhVhDr0W74229bPnZ9A== Date: Sat, 9 Mar 2013 16:09:00 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06891325@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.72.221] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Call Hold / Mute etc, 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, 09 Mar 2013 16:09:14 -0000 > On 09/03/13 5:56 PM, "Hutton, Andrew" > wrote: >Hi, > >Section 3.3 of draft-ram-siprec-call-flows gives an example of a >hold/resume on the CS and how it is reflected on the RS and it shows the >SDP in the RS being set to a=3Dinactive for a participant. > >This does not seem to be consistent with draft-ietf-siprec-protocol which >in section 7.1.1.1 states: > >" Note that when a CS > stream is muted/unmuted, this information is conveyed in the metadata > by the SRC. The SRC SHOULD NOT modify the media stream with > a=3Dinactive for mute since this operation is reserved for pausing the > RS media." A question here: How will SRC know a CS stream is muted /unmuted ? If SRC is going to learn it from SDP direction attribute(a=3Dsendonly/recvonly/inactive) of CS SDP then it has no way to differentiate whether it is mute or hold from the SIP semantics So, indication of mute/unmute could be the same way as hold/resume which is change in direction attribute in SDP. Ram > > >Is this an inconsistency and how exactly is the muted/unmuted indication >conveyed in metadata I could not find this in the metadata draft. > >Regards >Andy >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Sat Mar 9 08:17:07 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 6A3A921F869F for ; Sat, 9 Mar 2013 08:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHra5uSAp5ps for ; Sat, 9 Mar 2013 08:17:06 -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 4EE0421F8600 for ; Sat, 9 Mar 2013 08:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7767; q=dns/txt; s=iport; t=1362845826; x=1364055426; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=SWDItVnFR+Zt8rdSNtE45KwcAnWqcwWxCmjQOkANxc4=; b=LPNjcJ5vHyBhk2MayUYnHhiSs/4+sU2oPWw1Z02o8Fjb0hMY+xH5RP+r Vxd8mezInKqbAJE6WukYrdRs1NwrwQWrKmDK96IlSB6TypwndVZaEkCUg OD80bnvVAkKwLlsvobH/0fpji1FJIjnCaWzw5y57a8A6hSnb7psdHD4iK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACJgO1GtJXG8/2dsb2JhbABDxGCBXxZtB4ItAQEBAwEBAQE3NBAHBgEIEQEDAQEBChQFBC4LFAMGCAIEEwgTh3IGDJpooFsEjlsGIBIGgllhA6dHgVSBNoIn X-IronPort-AV: E=Sophos;i="4.84,814,1355097600"; d="scan'208";a="185451148" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 09 Mar 2013 16:17:05 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r29GH5R0025617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 9 Mar 2013 16:17:05 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Sat, 9 Mar 2013 10:17:05 -0600 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] Common unique-id from multiple SRC to SRS [was RE: Comments on draft-ietf-siprec-metadata-10.] Thread-Index: AQHOHOGJ5gO8KTWl4UiGssOaUszIJg== Date: Sat, 9 Mar 2013 16:17:04 +0000 Message-ID: In-Reply-To: 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.72.221] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was RE: 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, 09 Mar 2013 16:17:07 -0000 To add to the below another simple case a CS with two endpoints where each point acts as SRC and records each side of the conversation via RS. So you would have two RS from two SRCs for the same CS. Ram > On 09/03/13 9:30 PM, "Ram Mohan R (rmohanr)" wrote: >Getting back late on this. I see Andy's question here is > >I am not convinced that we can say anything about the multiple SRC >case other than making sure we keep the id's unique I don't think we said >anything about this in the architecture draft. Can you describe the use >case and requirement that this covers. > > >I think there would definitely be use-cases in real deployments where >there would be multiple SRCs for a single CS. A simplest use-case that I >have heard many times is recording solution for Financial trading centers >where they prefer to have redundant recordings (recorded to different >geographical sites). In such flows we *may* have multiple SRC's each >having its own RS and recording the same CS. > >A simple scenario being both endpoints of a CS acting as SRC. You can >visualize this to the section 3.1.2 of architecture draft with both >endpoints having RS. > >Ram > > >> On 07/03/13 10:38 PM, "Parthasarathi R" >>wrote: > >>Andy, >> >>Sorry for the delay reply. As Paul mentioned, common unique-id from >>multiple >>SRC to SRS shall be discussed in Sec 6.10. The point to be noted is that >>SRS >>should be in the position to receive the common unique-id from multiple >>SRC >>and how unique-id is exchanged between SRCs is outside the scope of >>SIPREC. >>Please let us know in case you have any concern in this approach. >> >>Thanks >>Partha >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Saturday, February 02, 2013 11:25 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >>>=20 >>> Some comments inline. >>>=20 >>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>>=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." >>> >> >>> > >>> > Ok but still it really does not have anything to do with the >>> case of 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. >>> . >>>=20 >>> IMO the point to get across is that multiple SRCs are *permitted* to >>> refer to the same entities by using a common UUID. (The SRS must not >>> consider this an error.) *How* the SRCs determine they are referring to >>> the same entity and obtain the same UUID for it is out of scope for >>> this >>> document. >>>=20 >>> Perhaps it would be better to discuss this in 6.10. >>>=20 >>> >>> 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 case other than making sure we keep the id's unique I don't think >>> we said anything about this in the architecture draft. Can you describe >>> the use case and requirement that this covers. >>>=20 >>> Same comment as above. >>>=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 >>> reason attribute if it is just free form text it is I think more useful >>> if we follow a defined structure such as RFC3326 for this. >>>=20 >>> I agree this is worthy of some discussion as to whether 3326 is >>> sufficient, or if we need a wider range of causes than that provides. >>>=20 >>> I agree with Andy that just having a string, that might or might not be >>> a standard string from 3326 is dubious. With that you can never be >>> certain if the reason has the exact semantics of a 3326 reason. >>>=20 >>> So I'm inclined to think we should be able to carry everything from a >>> Reason header. >>>=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 should be removed. >>>=20 >>> Certainly we can't enumerate all the things we *don't* cover. >>> IIRC this was added because some people expected that we *would* >>> include >>> info about desired retention policy, and we wanted to make it clear >>> that >>> we were not. I see no harm in that. >>>=20 >>>=20 >>> _______________________________________________ >>> 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 Sat Mar 9 15:32:28 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 47FC621F8644 for ; Sat, 9 Mar 2013 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eY1PXdEF-gB for ; Sat, 9 Mar 2013 15:32:27 -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 AED7A21F863F for ; Sat, 9 Mar 2013 15:32:27 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E4F281EB8562; Sun, 10 Mar 2013 00:32:26 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Sun, 10 Mar 2013 00:32:26 +0100 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] Call Hold / Mute etc, Thread-Index: Ac4cMeYcP5V7UHt5QoqIt6bze2tKQQApiEcAABFN1AA= Date: Sat, 9 Mar 2013 23:32:26 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF06891325@MCHP04MSX.global-ad.net> In-Reply-To: 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] Call Hold / Mute etc, 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, 09 Mar 2013 23:32:28 -0000 On 09 March 2013 11:09 : Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] W= rote: >=20 > A question here: >=20 > How will SRC know a CS stream is muted /unmuted ? If SRC is going to > learn > it from SDP direction attribute(a=3Dsendonly/recvonly/inactive) of CS SDP > then it has no way to differentiate whether it is mute or hold from the > SIP semantics As you say the only thing the SRC knows about the CS is from SDP so we are = talking about the direction of the CS nothing else.=20 >=20 > So, indication of mute/unmute could be the same way as hold/resume > which > is change in direction attribute in SDP. > We have always stated in the protocol draft that setting the direction of t= he RS to "a=3Dinactive" is reserved for the case when the recording is paus= ed and does not reflect the direction of the CS. =20 Andy =20 From rmohanr@cisco.com Sun Mar 10 07:25:48 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 46B5321F8675 for ; Sun, 10 Mar 2013 07:25:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GA-9EJ0b58M for ; Sun, 10 Mar 2013 07:25:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9995921F86CA for ; Sun, 10 Mar 2013 07:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1568; q=dns/txt; s=iport; t=1362925546; x=1364135146; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=48HL6wIY2rniExXfXFD1pyNjwu45Y3zKjRhh6CleVPE=; b=C4JwdHNzwn5JRc4x1+7rKObnNV0PKidMOyq7YXbOpjtQF6JlKFU1lMch ZOlui5MRdEJwoHO4949d0/znJ70xQmjTguCw7gR2eDaB+0MbZSA1hc2jl BZZhcXiV54iy5qjIt71WVywTQCmNR22oPdTMKUYo1C4CZ8Xaq58rPm2Sq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIOXPFGtJXHA/2dsb2JhbABDxD+BShZtB4ImAQEBAwE6RA0BCCIUCTkUEQIEEwiIBQabC6BAjlsCOIJfYQOnSoMKgig X-IronPort-AV: E=Sophos;i="4.84,817,1355097600"; d="scan'208";a="185607284" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 10 Mar 2013 14:25:46 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2AEPk4N012388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 10 Mar 2013 14:25:46 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 09:25:45 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] Call Hold / Mute etc, Thread-Index: AQHOHZsnGIg0H4yL8kONNsqH1W9O+w== Date: Sun, 10 Mar 2013 14:25:45 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.66.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <3811FFBC722ED543B0C0D0F4EC90F470@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Call Hold / Mute etc, 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: Sun, 10 Mar 2013 14:25:48 -0000 > On 10/03/13 5:02 AM, "Hutton, Andrew" > wrote: >On 09 March 2013 11:09 : Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >Wrote: >>=20 >> A question here: >>=20 >> How will SRC know a CS stream is muted /unmuted ? If SRC is going to >> learn >> it from SDP direction attribute(a=3Dsendonly/recvonly/inactive) of CS SD= P >> then it has no way to differentiate whether it is mute or hold from the >> SIP semantics > >As you say the only thing the SRC knows about the CS is from SDP so we >are talking about the direction of the CS nothing else. > >>=20 >> So, indication of mute/unmute could be the same way as hold/resume >> which >> is change in direction attribute in SDP. >> > >We have always stated in the protocol draft that setting the direction of >the RS to "a=3Dinactive" is reserved for the case when the recording is >paused and does not reflect the direction of the CS. I think we have discussed about representing hold/resume of CS from SRC to SRS in the past and the preference has been to use SIP/SDP semantics rather than re-inventing another approach in XML. Is there some thing that has changed which requires us the re-look at this ? On the other hand when you say recording is paused, how does SRC / SRS know it is pause and not hold ? SIP semantics does not indicate any thing. So I believe SRS/SRC may not really differentiate on whether it is pause/hold unless you have a some other means (non-SIP) to learn the same. Regards, Ram =20 > >Andy >=20 > > > From andrew.hutton@siemens-enterprise.com Sun Mar 10 08:52: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 F35AB21F86BB for ; Sun, 10 Mar 2013 08:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ97ECdBE4IC for ; Sun, 10 Mar 2013 08:52:13 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4836621F8633 for ; Sun, 10 Mar 2013 08:52:12 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id EC86C23F03FF; Sun, 10 Mar 2013 16:52:10 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Sun, 10 Mar 2013 16:52:10 +0100 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] Call Hold / Mute etc, Thread-Index: Ac4cMeYcP5V7UHt5QoqIt6bze2tKQQApiEcAABFN1AAAHWGmgAAENOmA Date: Sun, 10 Mar 2013 15:52:10 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net> In-Reply-To: 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] Call Hold / Mute etc, 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: Sun, 10 Mar 2013 15:52:17 -0000 Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote >=20 > I think we have discussed about representing hold/resume of CS from SRC > to > SRS in the past and the preference has been to use SIP/SDP semantics > rather than re-inventing another approach in XML. Is there some thing > that > has changed which requires us the re-look at this ? [AndyH] - Might be my memory that is the issue if you can point me at the d= iscussion we had that would help. However I checked the protocol document a= nd this has always stated that "inactive" on the RS means that the recordin= g is paused and does not imply anything about the CS direction. The stateme= nt about indicating this is metadata was added in version 01 of the protoco= l draft and has been unchanged since then. > On the other hand when you say recording is paused, how does SRC / SRS > know it is pause and not hold ? SIP semantics does not indicate any > thing. > So I believe SRS/SRC may not really differentiate on whether it is > pause/hold unless you have a some other means (non-SIP) to learn the > same. [AndyH] Which is why I assume the protocol draft states that metadata is us= ed for this. >=20 > Regards, > Ram >=20 > > > >Andy > > > > > > > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Sun Mar 10 20:12:37 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 96C6621F892D for ; Sun, 10 Mar 2013 20:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RmtX1E8V+ha for ; Sun, 10 Mar 2013 20:12:36 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 7289B21F87FF for ; Sun, 10 Mar 2013 20:12:36 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta12.emeryville.ca.mail.comcast.net with comcast id A2AJ1l0021zF43QAC3CUpp; Mon, 11 Mar 2013 03:12:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:1d9f:4522:3569:ca14]) by omta24.emeryville.ca.mail.comcast.net with comcast id A3CT1l00D4B9e0B8k3CTdH; Mon, 11 Mar 2013 03:12:28 +0000 Message-ID: <513D4B9B.2010609@alum.mit.edu> Date: Mon, 11 Mar 2013 11:12:27 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: siprec@ietf.org References: <00d901ce19c9$4496af90$cdc40eb0$@co.in> <5138F11D.9000104@alum.mit.edu> In-Reply-To: <5138F11D.9000104@alum.mit.edu> 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=1362971548; bh=vIe+s1fr/76R6AwxXnZ18RPqFcIOP5uJJnb7nNxYe/c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s6SEaAzZJSX9KLaJJTfYqTGBIUgbdYbMAmUxQx9phLdlYNWnzchNnAO0ChjSWVYiw qctL9lplfS+k299vFm0gTk/H2j6THYf8zkjgcYKAl/nsiZi6QTD0aRsFb77MqIxy14 Era9lwV+mTMddWvQlQt+ALWvRMKs9PXegZ0dfg8hWJKwCwHD5W2Oi7qJ9VRqgyPfN5 cbcwoArxKekwZr+90Wn0ANPewW6goQ6gErbnFjYLwdbkeGu6zty4fa2qaNMd+cVwvc N+EwY+DUGRkmnFKaW4JwQAJgswRC96UwX+Ab7lghynjhrVL9tCkWLnDIpAsWft0GHE vxqrwcuzD5KRA== Subject: Re: [siprec] Reason element usage 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: Mon, 11 Mar 2013 03:12:37 -0000 After some side discussions I realize I was wrong, and we do want to be compatible with the Reason header, so that we can copy values for the CS. So then the question is: HOW? We could just copy the full value of the Reason header, as unparsed text, with parameters and everything. But that seems gross to me. I see a couple of plausible syntaxes. Here are some examples: Call completed elsewhere Terminated OR SIP 200 Call completed elsewhere Q.850 16 Terminated Note that in either case we need the schema to permit multiple instances of , because you can have multiple reasons in a Reason header. I personally prefer the former for style and conciseness, but I can live with the other one too. Thanks, Paul On 3/8/13 3:57 AM, Paul Kyzivat wrote: > I have some questions about this idea. What is the goal? How closely do > you want to follow the Reason header (RFC3326)? > > - 3326 doesn't use xml, so at best it provides a conceptual model. > - each reason-value consists of a protocol name, cause number > for that protocol, and some text. The currently defined protocols > are SIP and Q.850. But I don't think either the SIP or Q.850 > causes will make any sense for siprec. > - 3326 allows multiple reason-values. > I doubt that makes any sense for siprec. > > So I *think* what people mean when they say to copy the reason header is > that we should provide both a machine-understandable numeric value plus > a human-friendly text value. But then we will need to define our own > numeric values. Unfortunately, doing that means that we need to open up > discussion about what numeric values we should define. Maybe that will > be a useful discussion, maybe not. But it will take some time. > > Is it worth it? > Or can we live with a string? I don't think we expect any programatic > recovery action, so a machine readable value isn't so important. > > Thanks, > Paul > > > On 3/6/13 3:52 AM, Mary Barnes wrote: >> I think it would be better to follow the format of the Reason header >> field as defined in RFC 3326. >> >> Mary. >> >> On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R >> wrote: >>> Hi all, >>> >>> As per draft-ietf-siprec-metadata-11, Reason element is a string and not >>> required to be as per RFC3326(SIP reason header). Could you please >>> let us >>> know your opinion whether SIPREC has to follow "reason" element as >>> string or >>> "reason" element has to be updated as per RFC 3326. >>> >>> Thanks >>> Partha >>> >>> PS: See Sec 6.3.1 comment in the below mail for more details >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of >>> Paul Kyzivat >>> Sent: Saturday, February 02, 2013 11:25 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >>> >>> Some comments inline. >>> >>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>> >>>>>> 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." >>>>> >>>> >>>> Ok but still it really does not have anything to do with the >>>> case >>> of 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. . >>> >>> IMO the point to get across is that multiple SRCs are *permitted* to >>> refer to the same entities by using a common UUID. (The SRS must not >>> consider this an error.) *How* the SRCs determine they are referring to >>> the same entity and obtain the same UUID for it is out of scope for this >>> document. >>> >>> Perhaps it would be better to discuss this in 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 >>> case other than making sure we keep the id's unique I don't think we >>> said >>> anything about this in the architecture draft. Can you describe the >>> use case >>> and requirement that this covers. >>> >>> Same comment as above. >>> >>>>>> 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 >>> reason attribute if it is just free form text it is I think more >>> useful if >>> we follow a defined structure such as RFC3326 for this. >>> >>> I agree this is worthy of some discussion as to whether 3326 is >>> sufficient, or if we need a wider range of causes than that provides. >>> >>> I agree with Andy that just having a string, that might or might not be >>> a standard string from 3326 is dubious. With that you can never be >>> certain if the reason has the exact semantics of a 3326 reason. >>> >>> So I'm inclined to think we should be able to carry everything from a >>> Reason header. >>> >>>>>> 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 >>> should be removed. >>> >>> Certainly we can't enumerate all the things we *don't* cover. >>> IIRC this was added because some people expected that we *would* include >>> info about desired retention policy, and we wanted to make it clear that >>> we were not. I see no harm in that. >>> >>> >>> _______________________________________________ >>> 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 rmohanr@cisco.com Sun Mar 10 21:12:12 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 ACBE321F893D for ; Sun, 10 Mar 2013 21:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq8mqtoqaUq1 for ; Sun, 10 Mar 2013 21:12:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF5B11E80E1 for ; Sun, 10 Mar 2013 21:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9654; q=dns/txt; s=iport; t=1362975131; x=1364184731; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=9wJNB4QrOeXHQYUMjCtIBvPmaYOKjemm6jXN+iJuwmQ=; b=D1hqnsr8QQBCIJJqlnIr4VFYc+cYRiQvqZs+vFNiZVxoJK4H8q5FneyZ x35qqUVC+kg/L3lFYuVQT5E/6DF1PLhTbTVBdPpbLt4lTQZSPSJTdmFJO 5PQd6YKRchf74KO7eH+vbOKQJg0xWGPlJpFoq1bSWcdRaWQrVvecnJM8K k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOJXPVGtJXG+/2dsb2JhbABDxEuBTxZtB4IkAQEBAwEBAQE3NBAHBgEIEQEDAQEBChQJLgsUAwYIAgQTCIgFBgybWKA6BI1dgQAGIBIGgllhA6dKgwqBczU X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185934433" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 11 Mar 2013 04:12:11 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2B4CAGB017139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Mar 2013 04:12:10 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 23:12:10 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] Reason element usage Thread-Index: AQHOHg6aBfOpjCFRfE6VLRXJ3enpew== Date: Mon, 11 Mar 2013 04:12:10 +0000 Message-ID: In-Reply-To: <513D4B9B.2010609@alum.mit.edu> 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.84.235] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C6BD95E63715D41B9F43659162E4E8E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Reason element usage 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: Mon, 11 Mar 2013 04:12:12 -0000 > On 11/03/13 8:42 AM, "Paul Kyzivat" wrote: >After some side discussions I realize I was wrong, and we do want to be >compatible with the Reason header, so that we can copy values for the >CS. So then the question is: HOW? > >We could just copy the full value of the Reason header, as unparsed >text, with parameters and everything. But that seems gross to me. > >I see a couple of plausible syntaxes. Here are some examples: > >Call completed elsewhere >Terminated I also prefer the above approach as its compact when compared to other representation below. Ram > >OR > > > SIP > 200 > Call completed elsewhere > > > Q.850 > 16 > Terminated > > >Note that in either case we need the schema to permit multiple instances >of , because you can have multiple reasons in a Reason header. > >I personally prefer the former for style and conciseness, but I can live >with the other one too. > > Thanks, > Paul > >On 3/8/13 3:57 AM, Paul Kyzivat wrote: >> I have some questions about this idea. What is the goal? How closely do >> you want to follow the Reason header (RFC3326)? >> >> - 3326 doesn't use xml, so at best it provides a conceptual model. >> - each reason-value consists of a protocol name, cause number >> for that protocol, and some text. The currently defined protocols >> are SIP and Q.850. But I don't think either the SIP or Q.850 >> causes will make any sense for siprec. >> - 3326 allows multiple reason-values. >> I doubt that makes any sense for siprec. >> >> So I *think* what people mean when they say to copy the reason header is >> that we should provide both a machine-understandable numeric value plus >> a human-friendly text value. But then we will need to define our own >> numeric values. Unfortunately, doing that means that we need to open up >> discussion about what numeric values we should define. Maybe that will >> be a useful discussion, maybe not. But it will take some time. >> >> Is it worth it? >> Or can we live with a string? I don't think we expect any programatic >> recovery action, so a machine readable value isn't so important. >> >> Thanks, >> Paul >> >> >> On 3/6/13 3:52 AM, Mary Barnes wrote: >>> I think it would be better to follow the format of the Reason header >>> field as defined in RFC 3326. >>> >>> Mary. >>> >>> On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R >>> wrote: >>>> Hi all, >>>> >>>> As per draft-ietf-siprec-metadata-11, Reason element is a string and >>>>not >>>> required to be as per RFC3326(SIP reason header). Could you please >>>> let us >>>> know your opinion whether SIPREC has to follow "reason" element as >>>> string or >>>> "reason" element has to be updated as per RFC 3326. >>>> >>>> Thanks >>>> Partha >>>> >>>> PS: See Sec 6.3.1 comment in the below mail for more details >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of >>>> Paul Kyzivat >>>> Sent: Saturday, February 02, 2013 11:25 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >>>> >>>> Some comments inline. >>>> >>>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>>> >>>>>>> 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." >>>>>> >>>>> >>>>> Ok but still it really does not have anything to do with the >>>>> case >>>> of 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. . >>>> >>>> IMO the point to get across is that multiple SRCs are *permitted* to >>>> refer to the same entities by using a common UUID. (The SRS must not >>>> consider this an error.) *How* the SRCs determine they are referring >>>>to >>>> the same entity and obtain the same UUID for it is out of scope for >>>>this >>>> document. >>>> >>>> Perhaps it would be better to discuss this in 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 >>>> case other than making sure we keep the id's unique I don't think we >>>> said >>>> anything about this in the architecture draft. Can you describe the >>>> use case >>>> and requirement that this covers. >>>> >>>> Same comment as above. >>>> >>>>>>> 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 >>>> reason attribute if it is just free form text it is I think more >>>> useful if >>>> we follow a defined structure such as RFC3326 for this. >>>> >>>> I agree this is worthy of some discussion as to whether 3326 is >>>> sufficient, or if we need a wider range of causes than that provides. >>>> >>>> I agree with Andy that just having a string, that might or might not >>>>be >>>> a standard string from 3326 is dubious. With that you can never be >>>> certain if the reason has the exact semantics of a 3326 reason. >>>> >>>> So I'm inclined to think we should be able to carry everything from a >>>> Reason header. >>>> >>>>>>> 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 >>>> should be removed. >>>> >>>> Certainly we can't enumerate all the things we *don't* cover. >>>> IIRC this was added because some people expected that we *would* >>>>include >>>> info about desired retention policy, and we wanted to make it clear >>>>that >>>> we were not. I see no harm in that. >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From henry.lum@genesyslab.com Mon Mar 11 09:19:54 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 C126421F8C49 for ; Mon, 11 Mar 2013 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFjg2fWxYWNP for ; Mon, 11 Mar 2013 09:19:54 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id DB8FF21F8C00 for ; Mon, 11 Mar 2013 09:19:53 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Mon, 11 Mar 2013 12:19:51 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 09:19:47 -0700 From: Henry Lum To: "Hutton, Andrew" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] Call Hold / Mute etc, Thread-Index: Ac4cMeYcP5V7UHt5QoqIt6bze2tKQQA8ZEEAAA98mgAAHRpugAADBKEAACR1LSA= Date: Mon, 11 Mar 2013 16:19:47 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.47.225.126] MIME-Version: 1.0 X-MC-Unique: 113031112195101001 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [siprec] Call Hold / Mute etc, 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: Mon, 11 Mar 2013 16:19:54 -0000 I found an old discussion about mute/unmute and I think we forgot to post t= his on the mailing list and even incorporating the change in the draft. The suggestion came from Andy to make a change to avoid using the word mute= /unmute to avoid any confusion of terminology on how mute is operated by th= e handsets. The a=3Dinactive is still reserved for pausing and unpausing th= e recorded media, while metadata is used for conveying CS stream changes. Other than this I don't think there was any other mentions on mute and this= statement on the protocol draft. As Andy mentioned, this statement has bee= n on the protocol draft since -00. Regards, Henry > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Thursday, October 25, 2012 9:47 AM > To: Charles Eckel (eckelcu); Henry Lum > Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com > Subject: draft-ietf-siprec-protocol mute-unmute >=20 > Hi, >=20 > Changing the name of the thread to cover this specific point. >=20 > Regarding the following part of the chain which refers to mute/unmute on > the CS see comment below. >=20 > > > > > > > > > > 5) Section 7.1.1.1 ends with: > > > > > > > > > > Note that when a CS > > > > > stream is muted/unmuted, this information is conveyed in the > > > > metadata > > > > > by the SRC. The SRC SHOULD NOT modify the media stream with > > > > > a=3Dinactive for mute since this operation is reserved for > > pausing > > > > the > > > > > RS media. > > > > > > > > > > How does the SRC know that the stream is muted/unmuted? > > > > > > > > > > > > > > [hlum] The SRC should know that the stream is being set to inactive > > since > > > the SRC is sending the recorded media from the CS and the SRC is in > > the > > > signaling path of the CS to know that a media stream is being set to > > inactive. > > > > In my experience, even within the CS, the media stream does not get > > changed from sendrecv to inactive during a mute operation. Instead, the > > endpoint that mutes itself does so silently. In some cases, there is > > some proprietary signaling or media packet marking indicating mute, but > > in general the SRC would not know if the endpoint was simply quiet or > > really had done a mute locally. > > >=20 > The problem here is terminology in that mute normally implies a local > operation at the SIP UA rather than a hold operation which actually invol= ves > SIP Signaling and an offer/answer. So I would suggest that we do need to > make a minor change to the text to clarify what we are referring to. >=20 > Maybe something like this would help. >=20 > "Note that when a CS stream's direction is changed, for example to inacti= ve, > this information is conveyed in the metadata by the SRC. The SRC SHOULD > NOT in this case change the RS media stream direction since this operatio= n > is reserved for pausing the RS media". >=20 > This would avoid talking about services such as hold, mute etc. >=20 > Regards > Andy >=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: March-10-13 11:52 AM To: Ram Mohan R (rmohanr); siprec@ietf.org Subject: Re: [siprec] Call Hold / Mute etc, Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote >=20 > I think we have discussed about representing hold/resume of CS from SRC > to > SRS in the past and the preference has been to use SIP/SDP semantics > rather than re-inventing another approach in XML. Is there some thing > that > has changed which requires us the re-look at this ? [AndyH] - Might be my memory that is the issue if you can point me at the d= iscussion we had that would help. However I checked the protocol document a= nd this has always stated that "inactive" on the RS means that the recordin= g is paused and does not imply anything about the CS direction. The stateme= nt about indicating this is metadata was added in version 01 of the protoco= l draft and has been unchanged since then. > On the other hand when you say recording is paused, how does SRC / SRS > know it is pause and not hold ? SIP semantics does not indicate any > thing. > So I believe SRS/SRC may not really differentiate on whether it is > pause/hold unless you have a some other means (non-SIP) to learn the > same. [AndyH] Which is why I assume the protocol draft states that metadata is us= ed for this. >=20 > Regards, > Ram >=20 > > > >Andy > > > > > > > > >=20 >=20 > _______________________________________________ > 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 Tue Mar 12 07:04:18 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 575C521F8596 for ; Tue, 12 Mar 2013 07:04:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX+trsyGJDL7 for ; Tue, 12 Mar 2013 07:04:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE0821F84FF for ; Tue, 12 Mar 2013 07:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10665; q=dns/txt; s=iport; t=1363097055; x=1364306655; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ASB7ug2iVwX2MLJk4RXx4WnwovCFAx1548cbT8QxwJU=; b=HcLfaW+xUgIbxxaj9rjy+PGRoUeovQxiZdqy7why6I4W4Ln/GuVZvOoa 3Cv5sZkPcQBsHeLAY0DVdULaKG+2+CGRpN6VK5U8SlJj0L3CR5EChLRJu bDp9MqVJygM1hIas+jqD+rcTQusgqpmlo7VfB0BI4M/WeEs1Bmnzt5Bf3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN80P1GtJXG8/2dsb2JhbABDxGWBSRZ0gigBAQEEAQEBNzQXBAIBCBEBAwEBAQoUCQcnCxQDBggCBAESCIgMDLA2kAQTBI1cgQAGIBIGgllhA6dMgwqBczU X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="scan'208";a="183548656" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 12 Mar 2013 14:04:14 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2CE4E1h025955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Mar 2013 14:04:14 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 09:04:14 -0500 From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] Reason element usage Thread-Index: Ac4Bbn8O/lGsxcy9QnSCjuKe+jbn4QYV7BswABHAioAAZMRLgACj+hCAAAIV6AAAPHip0A== Date: Tue, 12 Mar 2013 14:04:13 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D25A5@xmb-aln-x08.cisco.com> References: <513D4B9B.2010609@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Reason element usage 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, 12 Mar 2013 14:04:18 -0000 +1 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Ram Mohan R (rmohanr) > Sent: Monday, March 11, 2013 12:12 AM > To: siprec@ietf.org > Subject: Re: [siprec] Reason element usage >=20 > > On 11/03/13 8:42 AM, "Paul Kyzivat" wrote: >=20 > >After some side discussions I realize I was wrong, and we do want to be > >compatible with the Reason header, so that we can copy values for the > >CS. So then the question is: HOW? > > > >We could just copy the full value of the Reason header, as unparsed > >text, with parameters and everything. But that seems gross to me. > > > >I see a couple of plausible syntaxes. Here are some examples: > > > >Call completed elsewhere > >Terminated >=20 > I also prefer the above approach as its compact when compared to other > representation below. >=20 > Ram >=20 > > > >OR > > > > > > SIP > > 200 > > Call completed elsewhere > > > > > > Q.850 > > 16 > > Terminated > > > > > >Note that in either case we need the schema to permit multiple instances > >of , because you can have multiple reasons in a Reason header. > > > >I personally prefer the former for style and conciseness, but I can live > >with the other one too. > > > > Thanks, > > Paul > > > >On 3/8/13 3:57 AM, Paul Kyzivat wrote: > >> I have some questions about this idea. What is the goal? How closely d= o > >> you want to follow the Reason header (RFC3326)? > >> > >> - 3326 doesn't use xml, so at best it provides a conceptual model. > >> - each reason-value consists of a protocol name, cause number > >> for that protocol, and some text. The currently defined protocols > >> are SIP and Q.850. But I don't think either the SIP or Q.850 > >> causes will make any sense for siprec. > >> - 3326 allows multiple reason-values. > >> I doubt that makes any sense for siprec. > >> > >> So I *think* what people mean when they say to copy the reason header > is > >> that we should provide both a machine-understandable numeric value > plus > >> a human-friendly text value. But then we will need to define our own > >> numeric values. Unfortunately, doing that means that we need to open > up > >> discussion about what numeric values we should define. Maybe that will > >> be a useful discussion, maybe not. But it will take some time. > >> > >> Is it worth it? > >> Or can we live with a string? I don't think we expect any programatic > >> recovery action, so a machine readable value isn't so important. > >> > >> Thanks, > >> Paul > >> > >> > >> On 3/6/13 3:52 AM, Mary Barnes wrote: > >>> I think it would be better to follow the format of the Reason header > >>> field as defined in RFC 3326. > >>> > >>> Mary. > >>> > >>> On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R > >>> wrote: > >>>> Hi all, > >>>> > >>>> As per draft-ietf-siprec-metadata-11, Reason element is a string and > >>>>not > >>>> required to be as per RFC3326(SIP reason header). Could you please > >>>> let us > >>>> know your opinion whether SIPREC has to follow "reason" element as > >>>> string or > >>>> "reason" element has to be updated as per RFC 3326. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> PS: See Sec 6.3.1 comment in the below mail for more details > >>>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of > >>>> Paul Kyzivat > >>>> Sent: Saturday, February 02, 2013 11:25 PM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. > >>>> > >>>> Some comments inline. > >>>> > >>>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: > >>>> > >>>>>>> 3. Section 6.2.1 Which discusses CS session attributes includes t= he > >>>>>>> following statement: "SRC (or SRS) is responsible for ensuring th= e > >>>>>>> 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 ca= se > >>>>>> multiple SRC interacts with the same SRS." > >>>>>> > >>>>> > >>>>> Ok but still it really does not have anything to do with th= e > >>>>> case > >>>> of 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. . > >>>> > >>>> IMO the point to get across is that multiple SRCs are *permitted* to > >>>> refer to the same entities by using a common UUID. (The SRS must not > >>>> consider this an error.) *How* the SRCs determine they are referring > >>>>to > >>>> the same entity and obtain the same UUID for it is out of scope for > >>>>this > >>>> document. > >>>> > >>>> Perhaps it would be better to discuss this in 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 ca= n > >>>>>>>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 t= he > >>>>>>> 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 > >>>> case other than making sure we keep the id's unique I don't think we > >>>> said > >>>> anything about this in the architecture draft. Can you describe the > >>>> use case > >>>> and requirement that this covers. > >>>> > >>>> Same comment as above. > >>>> > >>>>>>> 6. Section 6.3.1 Communication Session Attributes. I think we nee= d > >>>>>> 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 t= he > >>>> reason attribute if it is just free form text it is I think more > >>>> useful if > >>>> we follow a defined structure such as RFC3326 for this. > >>>> > >>>> I agree this is worthy of some discussion as to whether 3326 is > >>>> sufficient, or if we need a wider range of causes than that provides= . > >>>> > >>>> I agree with Andy that just having a string, that might or might not > >>>>be > >>>> a standard string from 3326 is dubious. With that you can never be > >>>> certain if the reason has the exact semantics of a 3326 reason. > >>>> > >>>> So I'm inclined to think we should be able to carry everything from = a > >>>> Reason header. > >>>> > >>>>>>> 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 thin= k > >>>> it is > >>>> useful to put possible usages of extension data in the draft when an= y > >>>> such > >>>> usage will be proprietary and not interoperable. I think this > >>>>paragraph > >>>> should be removed. > >>>> > >>>> Certainly we can't enumerate all the things we *don't* cover. > >>>> IIRC this was added because some people expected that we *would* > >>>>include > >>>> info about desired retention policy, and we wanted to make it clear > >>>>that > >>>> we were not. I see no harm in that. > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From mary.ietf.barnes@gmail.com Tue Mar 12 07:06:23 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 0AFF421F8ABD for ; Tue, 12 Mar 2013 07:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.755 X-Spam-Level: X-Spam-Status: No, score=-103.755 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4Z7helxY2Hn for ; Tue, 12 Mar 2013 07:06:21 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id B68F321F8675 for ; Tue, 12 Mar 2013 07:06:21 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id 1so2989095qee.30 for ; Tue, 12 Mar 2013 07:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=onHFZ3PHr1gYn0c/7KHxQpBRNZSfn75VDUngeej/+W0=; b=S6+vaYt/z4SgM0k9FiaupxvvC4hRzxNJs9Tq6JN+7UtKyGN+bziI8cGRf0mYVjb2OJ vYoX69KsVTeGmRVH8hRva6rTMW6ZqXWH1h8J4D2Ty2bF6Dkf88GAZptIRizSvHZe/Iof yXwH+jPqHeCQ7DbE2IcTIl72Fv9qZIhBpRS6EUj0R1fdqKzP/SanTH1Ed1vxO4x9rWkI ExMKcs82VN8fJm45JMlx6mtvYZhlhYiomh/1JA6Px+3Zow2Ck5bQlF3+LbpK9qXWg6p7 Gn8pPv8uYLr8fkWWi5TXzb1RHidPIXT9+ptuy2kg63MbWVqV9YlN4Xue9xjLmo/dJI8F UEFA== MIME-Version: 1.0 X-Received: by 10.224.27.136 with SMTP id i8mr22737399qac.63.1363097166132; Tue, 12 Mar 2013 07:06:06 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Tue, 12 Mar 2013 07:06:06 -0700 (PDT) In-Reply-To: <513D4B9B.2010609@alum.mit.edu> References: <00d901ce19c9$4496af90$cdc40eb0$@co.in> <5138F11D.9000104@alum.mit.edu> <513D4B9B.2010609@alum.mit.edu> Date: Tue, 12 Mar 2013 09:06:06 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: "siprec@ietf.org" Subject: Re: [siprec] Reason element usage 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, 12 Mar 2013 14:06:23 -0000 I also prefer the first style. Thanks, Mary. On Sun, Mar 10, 2013 at 10:12 PM, Paul Kyzivat wrote: > After some side discussions I realize I was wrong, and we do want to be > compatible with the Reason header, so that we can copy values for the CS. So > then the question is: HOW? > > We could just copy the full value of the Reason header, as unparsed text, > with parameters and everything. But that seems gross to me. > > I see a couple of plausible syntaxes. Here are some examples: > > Call completed elsewhere > Terminated > > OR > > > SIP > 200 > Call completed elsewhere > > > Q.850 > 16 > Terminated > > > Note that in either case we need the schema to permit multiple instances of > , because you can have multiple reasons in a Reason header. > > I personally prefer the former for style and conciseness, but I can live > with the other one too. > > Thanks, > Paul > > > On 3/8/13 3:57 AM, Paul Kyzivat wrote: >> >> I have some questions about this idea. What is the goal? How closely do >> you want to follow the Reason header (RFC3326)? >> >> - 3326 doesn't use xml, so at best it provides a conceptual model. >> - each reason-value consists of a protocol name, cause number >> for that protocol, and some text. The currently defined protocols >> are SIP and Q.850. But I don't think either the SIP or Q.850 >> causes will make any sense for siprec. >> - 3326 allows multiple reason-values. >> I doubt that makes any sense for siprec. >> >> So I *think* what people mean when they say to copy the reason header is >> that we should provide both a machine-understandable numeric value plus >> a human-friendly text value. But then we will need to define our own >> numeric values. Unfortunately, doing that means that we need to open up >> discussion about what numeric values we should define. Maybe that will >> be a useful discussion, maybe not. But it will take some time. >> >> Is it worth it? >> Or can we live with a string? I don't think we expect any programatic >> recovery action, so a machine readable value isn't so important. >> >> Thanks, >> Paul >> >> >> On 3/6/13 3:52 AM, Mary Barnes wrote: >>> >>> I think it would be better to follow the format of the Reason header >>> field as defined in RFC 3326. >>> >>> Mary. >>> >>> On Tue, Mar 5, 2013 at 11:45 AM, Parthasarathi R >>> wrote: >>>> >>>> Hi all, >>>> >>>> As per draft-ietf-siprec-metadata-11, Reason element is a string and not >>>> required to be as per RFC3326(SIP reason header). Could you please >>>> let us >>>> know your opinion whether SIPREC has to follow "reason" element as >>>> string or >>>> "reason" element has to be updated as per RFC 3326. >>>> >>>> Thanks >>>> Partha >>>> >>>> PS: See Sec 6.3.1 comment in the below mail for more details >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of >>>> Paul Kyzivat >>>> Sent: Saturday, February 02, 2013 11:25 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >>>> >>>> Some comments inline. >>>> >>>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>>> >>>>>>> 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." >>>>>> >>>>> >>>>> Ok but still it really does not have anything to do with the >>>>> case >>>> >>>> of 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. . >>>> >>>> IMO the point to get across is that multiple SRCs are *permitted* to >>>> refer to the same entities by using a common UUID. (The SRS must not >>>> consider this an error.) *How* the SRCs determine they are referring to >>>> the same entity and obtain the same UUID for it is out of scope for this >>>> document. >>>> >>>> Perhaps it would be better to discuss this in 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 >>>> >>>> case other than making sure we keep the id's unique I don't think we >>>> said >>>> anything about this in the architecture draft. Can you describe the >>>> use case >>>> and requirement that this covers. >>>> >>>> Same comment as above. >>>> >>>>>>> 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 >>>> >>>> reason attribute if it is just free form text it is I think more >>>> useful if >>>> we follow a defined structure such as RFC3326 for this. >>>> >>>> I agree this is worthy of some discussion as to whether 3326 is >>>> sufficient, or if we need a wider range of causes than that provides. >>>> >>>> I agree with Andy that just having a string, that might or might not be >>>> a standard string from 3326 is dubious. With that you can never be >>>> certain if the reason has the exact semantics of a 3326 reason. >>>> >>>> So I'm inclined to think we should be able to carry everything from a >>>> Reason header. >>>> >>>>>>> 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 >>>> should be removed. >>>> >>>> Certainly we can't enumerate all the things we *don't* cover. >>>> IIRC this was added because some people expected that we *would* include >>>> info about desired retention policy, and we wanted to make it clear that >>>> we were not. I see no harm in that. >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partha@parthasarathi.co.in Tue Mar 12 08:44:23 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 9A22911E80A6 for ; Tue, 12 Mar 2013 08:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP4dhUuxdElO for ; Tue, 12 Mar 2013 08:44:22 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34B11E80A5 for ; Tue, 12 Mar 2013 08:44:22 -0700 (PDT) Received: from userPC (unknown [122.179.84.57]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 170751EBFF26; Tue, 12 Mar 2013 15:44:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1363103062; bh=YeWhJU2zwXkwFV5f1n+lH2EnNL7lkz55T0GHJ/y6mZE=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WznBy7AkpLm8dqllG4UpzoIJseeBDdvKRu9dBcF9MX9IpDggAHtkJUDOgqo7r51Nv s9c9Ar9GyR+EkPvK1jbfsvJBB0SZ9zh08gq0mw6KraG8HoO1k0VIN4eRr/GwZ86B5n ffH6AClrHp1nf9OyWD4eXJhCIToasZSfcWvNI2iE= From: "Parthasarathi R" To: "'Henry Lum'" , "'Hutton, Andrew'" , "'Ram Mohan R \(rmohanr\)'" , References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net> In-Reply-To: Date: Tue, 12 Mar 2013 21:14:13 +0530 Message-ID: <00a201ce1f38$76b20190$641604b0$@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: Ac4cMeYcP5V7UHt5QoqIt6bze2tKQQA8ZEEAAA98mgAAHRpugAADBKEAACR1LSAAL6bwoA== Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0203.513F4D56.0056, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Subject: Re: [siprec] Call Hold / Mute etc, 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, 12 Mar 2013 15:44:23 -0000 Hi all, I agree that pause and resume are the only terminology mentioned in SIPREC(RFC 6341). "Call Hold" word is used in Sec 3.3. of draft-ram-siprec-callflows for easy understanding. In case it confuses, we will update with Pause and resume. Also, SIPREC protocol draft has to be updated with pause & resume. Pause of the stream shall be achieved by setting inactive as direction attribute and resume has to be mentioned by sendrecv direction attribute. IMO, Mute & Unmute are not signaled between SIP entities. call hold shall achieved in multiple ways in SDP like 1) Media direction attribute change as inactive 2) Media direction attribute change as sendonly (Music on Hold) 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be removed. The supplementary Service information shall be indicated through metadata extension data if required. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > Sent: Monday, March 11, 2013 9:50 PM > To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, > > I found an old discussion about mute/unmute and I think we forgot to > post this on the mailing list and even incorporating the change in the > draft. > > The suggestion came from Andy to make a change to avoid using the word > mute/unmute to avoid any confusion of terminology on how mute is > operated by the handsets. The a=inactive is still reserved for pausing > and unpausing the recorded media, while metadata is used for conveying > CS stream changes. > > Other than this I don't think there was any other mentions on mute and > this statement on the protocol draft. As Andy mentioned, this statement > has been on the protocol draft since -00. > > Regards, > Henry > > > -----Original Message----- > > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > > Sent: Thursday, October 25, 2012 9:47 AM > > To: Charles Eckel (eckelcu); Henry Lum > > Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com > > Subject: draft-ietf-siprec-protocol mute-unmute > > > > Hi, > > > > Changing the name of the thread to cover this specific point. > > > > Regarding the following part of the chain which refers to mute/unmute > on > > the CS see comment below. > > > > > > > > > > > > > > 5) Section 7.1.1.1 ends with: > > > > > > > > > > > > Note that when a CS > > > > > > stream is muted/unmuted, this information is conveyed in > the > > > > > metadata > > > > > > by the SRC. The SRC SHOULD NOT modify the media stream > with > > > > > > a=inactive for mute since this operation is reserved for > > > pausing > > > > > the > > > > > > RS media. > > > > > > > > > > > > How does the SRC know that the stream is muted/unmuted? > > > > > > > > > > > > > > > > > > [hlum] The SRC should know that the stream is being set to > inactive > > > since > > > > the SRC is sending the recorded media from the CS and the SRC is > in > > > the > > > > signaling path of the CS to know that a media stream is being set > to > > > inactive. > > > > > > In my experience, even within the CS, the media stream does not get > > > changed from sendrecv to inactive during a mute operation. Instead, > the > > > endpoint that mutes itself does so silently. In some cases, there > is > > > some proprietary signaling or media packet marking indicating mute, > but > > > in general the SRC would not know if the endpoint was simply quiet > or > > > really had done a mute locally. > > > > > > > The problem here is terminology in that mute normally implies a local > > operation at the SIP UA rather than a hold operation which actually > involves > > SIP Signaling and an offer/answer. So I would suggest that we do need > to > > make a minor change to the text to clarify what we are referring to. > > > > Maybe something like this would help. > > > > "Note that when a CS stream's direction is changed, for example to > inactive, > > this information is conveyed in the metadata by the SRC. The SRC > SHOULD > > NOT in this case change the RS media stream direction since this > operation > > is reserved for pausing the RS media". > > > > This would avoid talking about services such as hold, mute etc. > > > > Regards > > Andy > > > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: March-10-13 11:52 AM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, > > > Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote > > > > > > I think we have discussed about representing hold/resume of CS from > SRC > > to > > SRS in the past and the preference has been to use SIP/SDP semantics > > rather than re-inventing another approach in XML. Is there some thing > > that > > has changed which requires us the re-look at this ? > > [AndyH] - Might be my memory that is the issue if you can point me at > the discussion we had that would help. However I checked the protocol > document and this has always stated that "inactive" on the RS means > that the recording is paused and does not imply anything about the CS > direction. The statement about indicating this is metadata was added in > version 01 of the protocol draft and has been unchanged since then. > > > > > On the other hand when you say recording is paused, how does SRC / > SRS > > know it is pause and not hold ? SIP semantics does not indicate any > > thing. > > So I believe SRS/SRC may not really differentiate on whether it is > > pause/hold unless you have a some other means (non-SIP) to learn the > > same. > > [AndyH] Which is why I assume the protocol draft states that metadata > is used for this. > > > > > > Regards, > > Ram > > > > > > > >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 > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From henry.lum@genesyslab.com Tue Mar 12 09:05: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 37DA611E8102 for ; Tue, 12 Mar 2013 09:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBPr+LSEMapW for ; Tue, 12 Mar 2013 09:05:08 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id E415611E80E8 for ; Tue, 12 Mar 2013 09:05:06 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Tue, 12 Mar 2013 12:05:05 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 09:05:03 -0700 From: Henry Lum To: Parthasarathi R , "'Hutton, Andrew'" , "'Ram Mohan R (rmohanr)'" , "siprec@ietf.org" Thread-Topic: [siprec] Call Hold / Mute etc, Thread-Index: Ac4cMeYcP5V7UHt5QoqIt6bze2tKQQA8ZEEAAA98mgAAHRpugAADBKEAACR1LSAAL6bwoAACIsKQ Date: Tue, 12 Mar 2013 16:05:03 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net> <00a201ce1f38$76b20190$641604b0$@co.in> In-Reply-To: <00a201ce1f38$76b20190$641604b0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.90] MIME-Version: 1.0 X-MC-Unique: 113031212050505102 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [siprec] Call Hold / Mute etc, 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, 12 Mar 2013 16:05:13 -0000 When a participant goes on hold, then it's a just the direction of the part= icipant stream gets modified like what is shown in section 3.3 of call flow= draft. According to what is specified in the protocol draft, the media dir= ection of the RS stream does not change since it also signals that the reco= rded media is also being paused along with the change of participant stream= . Regards, Henry -----Original Message----- From: Parthasarathi R [mailto:partha@parthasarathi.co.in]=20 Sent: March-12-13 11:44 AM To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; siprec@ietf.org Subject: RE: [siprec] Call Hold / Mute etc, Hi all, I agree that pause and resume are the only terminology mentioned in SIPREC(RFC 6341). "Call Hold" word is used in Sec 3.3. of=20 draft-ram-siprec-callflows for easy understanding. In case it confuses, we will update with Pause and resume. Also, SIPREC protocol draft has=20 to be updated with pause & resume. Pause of the stream shall be achieved by setting inactive as direction attribute and resume has to be mentioned by sendrecv direction=20 attribute. IMO, Mute & Unmute are not signaled between SIP entities. call hold shall achieved in multiple ways in SDP like 1) Media direction attribute change as inactive 2) Media direction attribute change as sendonly (Music on Hold) 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be removed.=20 The supplementary Service information shall be indicated through=20 metadata extension data if required. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > Sent: Monday, March 11, 2013 9:50 PM > To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, >=20 > I found an old discussion about mute/unmute and I think we forgot to > post this on the mailing list and even incorporating the change in the > draft. >=20 > The suggestion came from Andy to make a change to avoid using the word > mute/unmute to avoid any confusion of terminology on how mute is > operated by the handsets. The a=3Dinactive is still reserved for pausing > and unpausing the recorded media, while metadata is used for conveying > CS stream changes. >=20 > Other than this I don't think there was any other mentions on mute and > this statement on the protocol draft. As Andy mentioned, this statement > has been on the protocol draft since -00. >=20 > Regards, > Henry >=20 > > -----Original Message----- > > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > > Sent: Thursday, October 25, 2012 9:47 AM > > To: Charles Eckel (eckelcu); Henry Lum > > Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com > > Subject: draft-ietf-siprec-protocol mute-unmute > > > > Hi, > > > > Changing the name of the thread to cover this specific point. > > > > Regarding the following part of the chain which refers to mute/unmute > on > > the CS see comment below. > > > > > > > > > > > > > > 5) Section 7.1.1.1 ends with: > > > > > > > > > > > > Note that when a CS > > > > > > stream is muted/unmuted, this information is conveyed in > the > > > > > metadata > > > > > > by the SRC. The SRC SHOULD NOT modify the media stream > with > > > > > > a=3Dinactive for mute since this operation is reserved for > > > pausing > > > > > the > > > > > > RS media. > > > > > > > > > > > > How does the SRC know that the stream is muted/unmuted? > > > > > > > > > > > > > > > > > > [hlum] The SRC should know that the stream is being set to > inactive > > > since > > > > the SRC is sending the recorded media from the CS and the SRC is > in > > > the > > > > signaling path of the CS to know that a media stream is being set > to > > > inactive. > > > > > > In my experience, even within the CS, the media stream does not get > > > changed from sendrecv to inactive during a mute operation. Instead, > the > > > endpoint that mutes itself does so silently. In some cases, there > is > > > some proprietary signaling or media packet marking indicating mute, > but > > > in general the SRC would not know if the endpoint was simply quiet > or > > > really had done a mute locally. > > > > > > > The problem here is terminology in that mute normally implies a local > > operation at the SIP UA rather than a hold operation which actually > involves > > SIP Signaling and an offer/answer. So I would suggest that we do need > to > > make a minor change to the text to clarify what we are referring to. > > > > Maybe something like this would help. > > > > "Note that when a CS stream's direction is changed, for example to > inactive, > > this information is conveyed in the metadata by the SRC. The SRC > SHOULD > > NOT in this case change the RS media stream direction since this > operation > > is reserved for pausing the RS media". > > > > This would avoid talking about services such as hold, mute etc. > > > > Regards > > Andy > > >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: March-10-13 11:52 AM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, >=20 >=20 > Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote >=20 >=20 > > > > I think we have discussed about representing hold/resume of CS from > SRC > > to > > SRS in the past and the preference has been to use SIP/SDP semantics > > rather than re-inventing another approach in XML. Is there some thing > > that > > has changed which requires us the re-look at this ? >=20 > [AndyH] - Might be my memory that is the issue if you can point me at > the discussion we had that would help. However I checked the protocol > document and this has always stated that "inactive" on the RS means > that the recording is paused and does not imply anything about the CS > direction. The statement about indicating this is metadata was added in > version 01 of the protocol draft and has been unchanged since then. >=20 >=20 >=20 > > On the other hand when you say recording is paused, how does SRC / > SRS > > know it is pause and not hold ? SIP semantics does not indicate any > > thing. > > So I believe SRS/SRC may not really differentiate on whether it is > > pause/hold unless you have a some other means (non-SIP) to learn the > > same. >=20 > [AndyH] Which is why I assume the protocol draft states that metadata > is used for this. >=20 >=20 > > > > Regards, > > Ram > > > > > > > >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 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From DAVE.HIGTON@nice.com Tue Mar 12 09:11:26 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 115EF21F8A55 for ; Tue, 12 Mar 2013 09:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMpcqUNvgvYu for ; Tue, 12 Mar 2013 09:11:25 -0700 (PDT) Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7221F8A40 for ; Tue, 12 Mar 2013 09:11:24 -0700 (PDT) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Tue, 12 Mar 2013 16:11:23 +0000 Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Mar 2013 16:11:22 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Tue, 12 Mar 2013 16:11:22 +0000 From: "Dave Higton" To: Date: Tue, 12 Mar 2013 16:11:21 +0000 Thread-Topic: [siprec] Call Hold / Mute etc, Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Index: Ac4cMeYcP5V7UHt5QoqIt6bze2tKQQA8ZEEAAA98mgAAHRpugAADBKEAACR1LSAAL6bwoAACIsKQAAA4upA= Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com> References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net><9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net><00a201ce1f38$76b20190$641604b0$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2013 16:11:22.0806 (UTC) FILETIME=[3D58ED60:01CE1F3C] Subject: Re: [siprec] Call Hold / Mute etc, 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, 12 Mar 2013 16:11:26 -0000 AFAIK, mute has never been signalled on any telephone system. The = terminal just sends silence. In VoIP, there are of course two ways of sending silence: send packets = containing silence, or stop sending packets. Is knowledge of the mute state important? Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Henry Lum Sent: 12 March 2013 16:05 To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; = siprec@ietf.org Subject: Re: [siprec] Call Hold / Mute etc, When a participant goes on hold, then it's a just the direction of the = participant stream gets modified like what is shown in section 3.3 of = call flow draft. According to what is specified in the protocol draft, = the media direction of the RS stream does not change since it also = signals that the recorded media is also being paused along with the = change of participant stream. Regards, Henry -----Original Message----- From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: March-12-13 11:44 AM To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; = siprec@ietf.org Subject: RE: [siprec] Call Hold / Mute etc, Hi all, I agree that pause and resume are the only terminology mentioned in = SIPREC(RFC 6341). "Call Hold" word is used in Sec 3.3. of = draft-ram-siprec-callflows for easy understanding. In case it confuses, = we will update with Pause and resume. Also, SIPREC protocol draft has to = be updated with pause & resume. Pause of the stream shall be achieved by setting inactive as direction = attribute and resume has to be mentioned by sendrecv direction = attribute. IMO, Mute & Unmute are not signaled between SIP entities. call hold = shall achieved in multiple ways in SDP like 1) Media direction attribute change as inactive 2) Media direction attribute change as sendonly (Music on Hold) 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be removed.=20 The supplementary Service information shall be indicated through = metadata extension data if required. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Henry Lum > Sent: Monday, March 11, 2013 9:50 PM > To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, >=20 > I found an old discussion about mute/unmute and I think we forgot to=20 > post this on the mailing list and even incorporating the change in the = > draft. >=20 > The suggestion came from Andy to make a change to avoid using the word = > mute/unmute to avoid any confusion of terminology on how mute is=20 > operated by the handsets. The a=3Dinactive is still reserved for = pausing=20 > and unpausing the recorded media, while metadata is used for conveying = > CS stream changes. >=20 > Other than this I don't think there was any other mentions on mute and = > this statement on the protocol draft. As Andy mentioned, this=20 > statement has been on the protocol draft since -00. >=20 > Regards, > Henry >=20 > > -----Original Message----- > > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > > Sent: Thursday, October 25, 2012 9:47 AM > > To: Charles Eckel (eckelcu); Henry Lum > > Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com > > Subject: draft-ietf-siprec-protocol mute-unmute > > > > Hi, > > > > Changing the name of the thread to cover this specific point. > > > > Regarding the following part of the chain which refers to=20 > > mute/unmute > on > > the CS see comment below. > > > > > > > > > > > > > > 5) Section 7.1.1.1 ends with: > > > > > > > > > > > > Note that when a CS > > > > > > stream is muted/unmuted, this information is conveyed in > the > > > > > metadata > > > > > > by the SRC. The SRC SHOULD NOT modify the media stream > with > > > > > > a=3Dinactive for mute since this operation is reserved = for > > > pausing > > > > > the > > > > > > RS media. > > > > > > > > > > > > How does the SRC know that the stream is muted/unmuted? > > > > > > > > > > > > > > > > > > [hlum] The SRC should know that the stream is being set to > inactive > > > since > > > > the SRC is sending the recorded media from the CS and the SRC is > in > > > the > > > > signaling path of the CS to know that a media stream is being=20 > > > > set > to > > > inactive. > > > > > > In my experience, even within the CS, the media stream does not=20 > > > get changed from sendrecv to inactive during a mute operation.=20 > > > Instead, > the > > > endpoint that mutes itself does so silently. In some cases, there > is > > > some proprietary signaling or media packet marking indicating=20 > > > mute, > but > > > in general the SRC would not know if the endpoint was simply quiet > or > > > really had done a mute locally. > > > > > > > The problem here is terminology in that mute normally implies a=20 > > local operation at the SIP UA rather than a hold operation which=20 > > actually > involves > > SIP Signaling and an offer/answer. So I would suggest that we do=20 > > need > to > > make a minor change to the text to clarify what we are referring to. > > > > Maybe something like this would help. > > > > "Note that when a CS stream's direction is changed, for example to > inactive, > > this information is conveyed in the metadata by the SRC. The SRC > SHOULD > > NOT in this case change the RS media stream direction since this > operation > > is reserved for pausing the RS media". > > > > This would avoid talking about services such as hold, mute etc. > > > > Regards > > Andy > > >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hutton, Andrew > Sent: March-10-13 11:52 AM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, >=20 >=20 > Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote >=20 >=20 > > > > I think we have discussed about representing hold/resume of CS from > SRC > > to > > SRS in the past and the preference has been to use SIP/SDP semantics = > > rather than re-inventing another approach in XML. Is there some=20 > > thing that has changed which requires us the re-look at this ? >=20 > [AndyH] - Might be my memory that is the issue if you can point me at=20 > the discussion we had that would help. However I checked the protocol=20 > document and this has always stated that "inactive" on the RS means=20 > that the recording is paused and does not imply anything about the CS=20 > direction. The statement about indicating this is metadata was added=20 > in version 01 of the protocol draft and has been unchanged since then. >=20 >=20 >=20 > > On the other hand when you say recording is paused, how does SRC / > SRS > > know it is pause and not hold ? SIP semantics does not indicate any=20 > > thing. > > So I believe SRS/SRC may not really differentiate on whether it is=20 > > pause/hold unless you have a some other means (non-SIP) to learn the = > > same. >=20 > [AndyH] Which is why I assume the protocol draft states that metadata=20 > is used for this. >=20 >=20 > > > > Regards, > > Ram > > > > > > > >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 >=20 > _______________________________________________ > 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 NICE Systems UK Limited ("NICE") is registered in England under company = number, 3403044. The registered office of NICE is at Tollbar Way, Hedge = End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for = the above-named persons only and may be confidential and/or legally = privileged. Any opinions expressed in this communication are not = necessarily those of NICE. If this communication has come to you in = error you must take no action based on it, nor must you copy or show it = to anyone; please delete/destroy and inform the sender by e-mail = immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail = and attachments are free from any virus, we advise that in keeping with = good computing practice the recipient should ensure they are actually = virus free. From br@brianrosen.net Tue Mar 12 09:21:36 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 7C7CE21F86D5 for ; Tue, 12 Mar 2013 09:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab17nzqsHPy9 for ; Tue, 12 Mar 2013 09:21:35 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4208C21F89FB for ; Tue, 12 Mar 2013 09:21:35 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id o13so1688321qaj.5 for ; Tue, 12 Mar 2013 09:21:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=89pZh6ZtH44Y5hrvyklIGTDM4L48Fc0dYmBqHC3QkUE=; b=ExBSl4mUX24Qqju2mj3FafoWWn420rHX4qIA8HOSM/BN4Yp/8Rwp9tygHlMo5kkwo/ vaUGWGGTiyUBoCUXYR5ujHNVzY/Dc8iOcfc8A89x5dN9x04VMqV+KqysG8yGRVpANBcm XLkNxdjGJGd5NxVPKJLIqxnCCJjbZGflKk/4yBnISLst/0p3bpeueKS/dU/BKqVRBcVh /MlrnayCOMWQrZkwGOVtD335k6NFqRIVtYZEkC9JO5lE1EAPoTE5wRfoU0bQHoVtLnDm Ou/P1PNMhXk9P3P1w2pJqOFLfmjsjwFcXaOutFMNVq+Zma//v3eLOGS8x4mZHz8RIsZt bJKg== X-Received: by 10.49.86.35 with SMTP id m3mr26741718qez.13.1363105294601; Tue, 12 Mar 2013 09:21:34 -0700 (PDT) Received: from [192.168.133.159] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPS id o5sm32319011qao.12.2013.03.12.09.21.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 09:21:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Rosen In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com> Date: Tue, 12 Mar 2013 12:21:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77C803CA-6326-4769-A0D3-49698792C2EC@brianrosen.net> References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net><9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net><00a201ce1f38$76b20190$641604b0$@co.in> <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com> To: Dave Higton X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkRt5Pza2A1/EbZ5xlhrLr/l5byZcREfJgfbC14hUh8FSG/axWtqHfcq3q9Y09TRkVvbcak Cc: siprec@ietf.org Subject: Re: [siprec] Call Hold / Mute etc, 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, 12 Mar 2013 16:21:36 -0000 With my 9-1-1/1-1-2 hat on, it does, or at least it would be helpful to = know that there are no packets (or silence packets) for a sustained = time. Brian On Mar 12, 2013, at 12:11 PM, Dave Higton wrote: > AFAIK, mute has never been signalled on any telephone system. The = terminal just sends silence. >=20 > In VoIP, there are of course two ways of sending silence: send packets = containing silence, or stop sending packets. >=20 > Is knowledge of the mute state important? >=20 > Dave >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Henry Lum > Sent: 12 March 2013 16:05 > To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; = siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, >=20 > When a participant goes on hold, then it's a just the direction of the = participant stream gets modified like what is shown in section 3.3 of = call flow draft. According to what is specified in the protocol draft, = the media direction of the RS stream does not change since it also = signals that the recorded media is also being paused along with the = change of participant stream. >=20 > Regards, > Henry >=20 > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: March-12-13 11:44 AM > To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; = siprec@ietf.org > Subject: RE: [siprec] Call Hold / Mute etc, >=20 > Hi all, >=20 > I agree that pause and resume are the only terminology mentioned in = SIPREC(RFC 6341). "Call Hold" word is used in Sec 3.3. of = draft-ram-siprec-callflows for easy understanding. In case it confuses, = we will update with Pause and resume. Also, SIPREC protocol draft has to = be updated with pause & resume. >=20 > Pause of the stream shall be achieved by setting inactive as direction = attribute and resume has to be mentioned by sendrecv direction = attribute. >=20 > IMO, Mute & Unmute are not signaled between SIP entities. call hold = shall achieved in multiple ways in SDP like >=20 > 1) Media direction attribute change as inactive > 2) Media direction attribute change as sendonly (Music on Hold) > 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) >=20 > So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be = removed.=20 > The supplementary Service information shall be indicated through = metadata extension data if required. >=20 > Thanks > Partha >=20 >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Henry Lum >> Sent: Monday, March 11, 2013 9:50 PM >> To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org >> Subject: Re: [siprec] Call Hold / Mute etc, >>=20 >> I found an old discussion about mute/unmute and I think we forgot to=20= >> post this on the mailing list and even incorporating the change in = the=20 >> draft. >>=20 >> The suggestion came from Andy to make a change to avoid using the = word=20 >> mute/unmute to avoid any confusion of terminology on how mute is=20 >> operated by the handsets. The a=3Dinactive is still reserved for = pausing=20 >> and unpausing the recorded media, while metadata is used for = conveying=20 >> CS stream changes. >>=20 >> Other than this I don't think there was any other mentions on mute = and=20 >> this statement on the protocol draft. As Andy mentioned, this=20 >> statement has been on the protocol draft since -00. >>=20 >> Regards, >> Henry >>=20 >>> -----Original Message----- >>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>> Sent: Thursday, October 25, 2012 9:47 AM >>> To: Charles Eckel (eckelcu); Henry Lum >>> Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com >>> Subject: draft-ietf-siprec-protocol mute-unmute >>>=20 >>> Hi, >>>=20 >>> Changing the name of the thread to cover this specific point. >>>=20 >>> Regarding the following part of the chain which refers to=20 >>> mute/unmute >> on >>> the CS see comment below. >>>=20 >>>>>>>=20 >>>>>>> 5) Section 7.1.1.1 ends with: >>>>>>>=20 >>>>>>> Note that when a CS >>>>>>> stream is muted/unmuted, this information is conveyed in >> the >>>>>> metadata >>>>>>> by the SRC. The SRC SHOULD NOT modify the media stream >> with >>>>>>> a=3Dinactive for mute since this operation is reserved for >>>> pausing >>>>>> the >>>>>>> RS media. >>>>>>>=20 >>>>>>> How does the SRC know that the stream is muted/unmuted? >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>> [hlum] The SRC should know that the stream is being set to >> inactive >>>> since >>>>> the SRC is sending the recorded media from the CS and the SRC is >> in >>>> the >>>>> signaling path of the CS to know that a media stream is being=20 >>>>> set >> to >>>> inactive. >>>>=20 >>>> In my experience, even within the CS, the media stream does not=20 >>>> get changed from sendrecv to inactive during a mute operation.=20 >>>> Instead, >> the >>>> endpoint that mutes itself does so silently. In some cases, there >> is >>>> some proprietary signaling or media packet marking indicating=20 >>>> mute, >> but >>>> in general the SRC would not know if the endpoint was simply quiet >> or >>>> really had done a mute locally. >>>>=20 >>>=20 >>> The problem here is terminology in that mute normally implies a=20 >>> local operation at the SIP UA rather than a hold operation which=20 >>> actually >> involves >>> SIP Signaling and an offer/answer. So I would suggest that we do=20 >>> need >> to >>> make a minor change to the text to clarify what we are referring to. >>>=20 >>> Maybe something like this would help. >>>=20 >>> "Note that when a CS stream's direction is changed, for example to >> inactive, >>> this information is conveyed in the metadata by the SRC. The SRC >> SHOULD >>> NOT in this case change the RS media stream direction since this >> operation >>> is reserved for pausing the RS media". >>>=20 >>> This would avoid talking about services such as hold, mute etc. >>>=20 >>> Regards >>> Andy >>>=20 >>=20 >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Hutton, Andrew >> Sent: March-10-13 11:52 AM >> To: Ram Mohan R (rmohanr); siprec@ietf.org >> Subject: Re: [siprec] Call Hold / Mute etc, >>=20 >>=20 >> Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote >>=20 >>=20 >>>=20 >>> I think we have discussed about representing hold/resume of CS from >> SRC >>> to >>> SRS in the past and the preference has been to use SIP/SDP semantics=20= >>> rather than re-inventing another approach in XML. Is there some=20 >>> thing that has changed which requires us the re-look at this ? >>=20 >> [AndyH] - Might be my memory that is the issue if you can point me at=20= >> the discussion we had that would help. However I checked the protocol=20= >> document and this has always stated that "inactive" on the RS means=20= >> that the recording is paused and does not imply anything about the CS=20= >> direction. The statement about indicating this is metadata was added=20= >> in version 01 of the protocol draft and has been unchanged since = then. >>=20 >>=20 >>=20 >>> On the other hand when you say recording is paused, how does SRC / >> SRS >>> know it is pause and not hold ? SIP semantics does not indicate any=20= >>> thing. >>> So I believe SRS/SRC may not really differentiate on whether it is=20= >>> pause/hold unless you have a some other means (non-SIP) to learn the=20= >>> same. >>=20 >> [AndyH] Which is why I assume the protocol draft states that metadata=20= >> is used for this. >>=20 >>=20 >>>=20 >>> Regards, >>> Ram >>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 >=20 > NICE Systems UK Limited ("NICE") is registered in England under = company number, 3403044. The registered office of NICE is at Tollbar = Way, Hedge End, Southampton, Hampshire SO30 2ZP. >=20 > Confidentiality: This communication and any attachments are intended = for the above-named persons only and may be confidential and/or legally = privileged. Any opinions expressed in this communication are not = necessarily those of NICE. If this communication has come to you in = error you must take no action based on it, nor must you copy or show it = to anyone; please delete/destroy and inform the sender by e-mail = immediately. >=20 > Monitoring: NICE may monitor incoming and outgoing e-mails. >=20 > Viruses: Although we have taken steps toward ensuring that this e-mail = and attachments are free from any virus, we advise that in keeping with = good computing practice the recipient should ensure they are actually = virus free. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From MSmith@dss-corp.com Tue Mar 12 09:34:21 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 808C721F8CAD for ; Tue, 12 Mar 2013 09:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyPx9i+aUi3T for ; Tue, 12 Mar 2013 09:34:19 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7021F8C93 for ; Tue, 12 Mar 2013 09:34:19 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h7td020171sv for ; Tue, 12 Mar 2013 12:38:20 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Tue, 12 Mar 2013 12:38:20 -0400 Received: from EXC01.dss.lan ([fe80::6540:2e8d:f781:8389]) by exc01.dss.lan ([fe80::6540:2e8d:f781:8389%16]) with mapi; Tue, 12 Mar 2013 12:34:16 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Call Hold / Mute etc, Thread-Index: AQHOHOB1plsJ1cF1iE61wqNlQYlP35ieVscAgADo1ICAABglAIABmgyAgAGIZYCAAAXSgIAAAcKAgAAC1gD//71MUA== Date: Tue, 12 Mar 2013 16:34:02 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880DC02F244A@exc01.dss.lan> References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net><9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net><00a201ce1f38$76b20190$641604b0$@co.in> <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com> <77C803CA-6326-4769-A0D3-49698792C2EC@brianrosen.net> In-Reply-To: <77C803CA-6326-4769-A0D3-49698792C2EC@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201303121638200086523 Subject: Re: [siprec] Call Hold / Mute etc, 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, 12 Mar 2013 16:34:21 -0000 With my 9-1-1/1-1-2 hat on as well, +1 to Brian's comment. If you put a SIP session on hold, the media stops in both directions. We do= n't want to do that on an emergency call - we want the caller's media to co= ntinue so it can be recorded. So we have the agent mute their own transmit.= We want the SRC to continue to receive the caller's audio, even if the age= nt's UA mutes the caller's audio to the agent's ear (which may be appropria= te).=20 A similar use case for non-emergency calls would be where we want the calle= r's comments recorded while the agent's voice is muted. Hearing them gripe = about your product, company, or support is good QA info. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Brian Rosen Sent: Tuesday, March 12, 2013 12:22 PM To: Dave Higton Cc: siprec@ietf.org Subject: Re: [siprec] Call Hold / Mute etc, With my 9-1-1/1-1-2 hat on, it does, or at least it would be helpful to kno= w that there are no packets (or silence packets) for a sustained time. Brian On Mar 12, 2013, at 12:11 PM, Dave Higton wrote: > AFAIK, mute has never been signalled on any telephone system. The termin= al just sends silence. >=20 > In VoIP, there are of course two ways of sending silence: send packets co= ntaining silence, or stop sending packets. >=20 > Is knowledge of the mute state important? >=20 > Dave >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Henry Lum > Sent: 12 March 2013 16:05 > To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)';=20 > siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, >=20 > When a participant goes on hold, then it's a just the direction of the pa= rticipant stream gets modified like what is shown in section 3.3 of call fl= ow draft. According to what is specified in the protocol draft, the media d= irection of the RS stream does not change since it also signals that the re= corded media is also being paused along with the change of participant stre= am. >=20 > Regards, > Henry >=20 > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: March-12-13 11:44 AM > To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)';=20 > siprec@ietf.org > Subject: RE: [siprec] Call Hold / Mute etc, >=20 > Hi all, >=20 > I agree that pause and resume are the only terminology mentioned in SIPRE= C(RFC 6341). "Call Hold" word is used in Sec 3.3. of draft-ram-siprec-callf= lows for easy understanding. In case it confuses, we will update with Pause= and resume. Also, SIPREC protocol draft has to be updated with pause & res= ume. >=20 > Pause of the stream shall be achieved by setting inactive as direction at= tribute and resume has to be mentioned by sendrecv direction attribute. >=20 > IMO, Mute & Unmute are not signaled between SIP entities. call hold=20 > shall achieved in multiple ways in SDP like >=20 > 1) Media direction attribute change as inactive > 2) Media direction attribute change as sendonly (Music on Hold) > 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) >=20 > So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be removed.=20 > The supplementary Service information shall be indicated through metadata= extension data if required. >=20 > Thanks > Partha >=20 >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Henry Lum >> Sent: Monday, March 11, 2013 9:50 PM >> To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org >> Subject: Re: [siprec] Call Hold / Mute etc, >>=20 >> I found an old discussion about mute/unmute and I think we forgot to=20 >> post this on the mailing list and even incorporating the change in=20 >> the draft. >>=20 >> The suggestion came from Andy to make a change to avoid using the=20 >> word mute/unmute to avoid any confusion of terminology on how mute is=20 >> operated by the handsets. The a=3Dinactive is still reserved for=20 >> pausing and unpausing the recorded media, while metadata is used for=20 >> conveying CS stream changes. >>=20 >> Other than this I don't think there was any other mentions on mute=20 >> and this statement on the protocol draft. As Andy mentioned, this=20 >> statement has been on the protocol draft since -00. >>=20 >> Regards, >> Henry >>=20 >>> -----Original Message----- >>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>> Sent: Thursday, October 25, 2012 9:47 AM >>> To: Charles Eckel (eckelcu); Henry Lum >>> Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com >>> Subject: draft-ietf-siprec-protocol mute-unmute >>>=20 >>> Hi, >>>=20 >>> Changing the name of the thread to cover this specific point. >>>=20 >>> Regarding the following part of the chain which refers to=20 >>> mute/unmute >> on >>> the CS see comment below. >>>=20 >>>>>>>=20 >>>>>>> 5) Section 7.1.1.1 ends with: >>>>>>>=20 >>>>>>> Note that when a CS >>>>>>> stream is muted/unmuted, this information is conveyed in >> the >>>>>> metadata >>>>>>> by the SRC. The SRC SHOULD NOT modify the media stream >> with >>>>>>> a=3Dinactive for mute since this operation is reserved for >>>> pausing >>>>>> the >>>>>>> RS media. >>>>>>>=20 >>>>>>> How does the SRC know that the stream is muted/unmuted? >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>> [hlum] The SRC should know that the stream is being set to >> inactive >>>> since >>>>> the SRC is sending the recorded media from the CS and the SRC is >> in >>>> the >>>>> signaling path of the CS to know that a media stream is being set >> to >>>> inactive. >>>>=20 >>>> In my experience, even within the CS, the media stream does not get=20 >>>> changed from sendrecv to inactive during a mute operation. >>>> Instead, >> the >>>> endpoint that mutes itself does so silently. In some cases, there >> is >>>> some proprietary signaling or media packet marking indicating mute, >> but >>>> in general the SRC would not know if the endpoint was simply quiet >> or >>>> really had done a mute locally. >>>>=20 >>>=20 >>> The problem here is terminology in that mute normally implies a=20 >>> local operation at the SIP UA rather than a hold operation which=20 >>> actually >> involves >>> SIP Signaling and an offer/answer. So I would suggest that we do=20 >>> need >> to >>> make a minor change to the text to clarify what we are referring to. >>>=20 >>> Maybe something like this would help. >>>=20 >>> "Note that when a CS stream's direction is changed, for example to >> inactive, >>> this information is conveyed in the metadata by the SRC. The SRC >> SHOULD >>> NOT in this case change the RS media stream direction since this >> operation >>> is reserved for pausing the RS media". >>>=20 >>> This would avoid talking about services such as hold, mute etc. >>>=20 >>> Regards >>> Andy >>>=20 >>=20 >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Hutton, Andrew >> Sent: March-10-13 11:52 AM >> To: Ram Mohan R (rmohanr); siprec@ietf.org >> Subject: Re: [siprec] Call Hold / Mute etc, >>=20 >>=20 >> Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote >>=20 >>=20 >>>=20 >>> I think we have discussed about representing hold/resume of CS from >> SRC >>> to >>> SRS in the past and the preference has been to use SIP/SDP semantics=20 >>> rather than re-inventing another approach in XML. Is there some=20 >>> thing that has changed which requires us the re-look at this ? >>=20 >> [AndyH] - Might be my memory that is the issue if you can point me at=20 >> the discussion we had that would help. However I checked the protocol=20 >> document and this has always stated that "inactive" on the RS means=20 >> that the recording is paused and does not imply anything about the CS=20 >> direction. The statement about indicating this is metadata was added=20 >> in version 01 of the protocol draft and has been unchanged since then. >>=20 >>=20 >>=20 >>> On the other hand when you say recording is paused, how does SRC / >> SRS >>> know it is pause and not hold ? SIP semantics does not indicate any=20 >>> thing. >>> So I believe SRS/SRC may not really differentiate on whether it is=20 >>> pause/hold unless you have a some other means (non-SIP) to learn the=20 >>> same. >>=20 >> [AndyH] Which is why I assume the protocol draft states that metadata=20 >> is used for this. >>=20 >>=20 >>>=20 >>> Regards, >>> Ram >>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 >=20 > NICE Systems UK Limited ("NICE") is registered in England under company n= umber, 3403044. The registered office of NICE is at Tollbar Way, Hedge End,= Southampton, Hampshire SO30 2ZP. >=20 > Confidentiality: This communication and any attachments are intended for = the above-named persons only and may be confidential and/or legally privile= ged. Any opinions expressed in this communication are not necessarily those= of NICE. If this communication has come to you in error you must take no a= ction based on it, nor must you copy or show it to anyone; please delete/de= stroy and inform the sender by e-mail immediately. >=20 > Monitoring: NICE may monitor incoming and outgoing e-mails. >=20 > Viruses: Although we have taken steps toward ensuring that this e-mail an= d attachments are free from any virus, we advise that in keeping with good = computing practice the recipient should ensure they are actually virus free= . > _______________________________________________ > 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 Tue Mar 12 09:51: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 CE32111E80BA for ; Tue, 12 Mar 2013 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi7X5IA2VtdZ for ; Tue, 12 Mar 2013 09:50:57 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30411E80EC for ; Tue, 12 Mar 2013 09:50:57 -0700 (PDT) Received: from userPC (unknown [122.179.84.57]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id D75D5190816C; Tue, 12 Mar 2013 16:50:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1363107055; bh=tCJbMO+NFMFDdOqOqTj0eK3W0P6RHgrO7uXfjOJPpSI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ECXL9hYsrvoSz9yyfxBDoFbl1hJe2H9MKEke5p3Dm36CKsNM8XqFuql9CswNC86+l oQfTNAYucPBmWRp8Q4In2Z4WBW9L+dl/sUmsRWSac19PmIAWp+SVa9/EoXDY4pomnC ZLW2mPAI3rOk88EbJjcRP6QKugXQdrxwsKxYAPmE= From: "Parthasarathi R" To: "'Henry Lum'" , "'Hutton, Andrew'" , "'Ram Mohan R \(rmohanr\)'" , References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net> <00a201ce1f38$76b20190$641604b0$@co.in> In-Reply-To: Date: Tue, 12 Mar 2013 22:20:46 +0530 Message-ID: <00a301ce1f41$c29baa80$47d2ff80$@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: Ac4cMeYcP5V7UHt5QoqIt6bze2tKQQA8ZEEAAA98mgAAHRpugAADBKEAACR1LSAAL6bwoAACIsKQAAD+h+A= Content-Language: en-us x-cr-hashedpuzzle: I30= CDoq Fg+R M9iA PL36 Pr1q QbGN RgXG YPLb ecUy fgh/ g2cG mG2u m7Ig oOS3 p3o3; 4; YQBuAGQAcgBlAHcALgBoAHUAdAB0AG8AbgBAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBoAGUAbgByAHkALgBsAHUAbQBAAGcAZQBuAGUAcwB5AHMAbABhAGIALgBjAG8AbQA7AHIAbQBvAGgAYQBuAHIAQABjAGkAcwBjAG8ALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {1A907261-57FC-4F97-B09E-D5D10FBB58B6}; cABhAHIAdABoAGEAQABwAGEAcgB0AGgAYQBzAGEAcgBhAHQAaABpAC4AYwBvAC4AaQBuAA==; Tue, 12 Mar 2013 16:50:38 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABDAGEAbABsACAASABvAGwAZAAgAC8AIABNAHUAdABlACAAZQB0AGMALAA= x-cr-puzzleid: {1A907261-57FC-4F97-B09E-D5D10FBB58B6} X-CTCH-RefID: str=0001.0A0C0202.513F5CEF.00FE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Subject: Re: [siprec] Call Hold / Mute etc, 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, 12 Mar 2013 16:51:00 -0000 Henry, I'm not very clear about your conclusion. I'm modifying you statement for clarification: "When a participant pause the stream, then it's a just the direction of the participant stream gets modified like what is shown in section 3.3 of call flow draft." The above statement just calls for the update in draft-ram-siprec-callflows and we will do it in the next revision. " According to what is specified in the protocol draft, the media direction of the RS stream does not change since it also signals that the recorded media is also being paused along with the change of participant stream" Please note that SIPREC metadata is the combination of XML + SDP because stream element does not indicate about the SDP information but it provides the label for linking SDP in RS. Pausing of the stream is the matter of SDP which will be indicated by direction attribute of the specific "m" line in RS. So, there is a need to change in SIPREC protocol draft. Please clarify in case I'm missing something. Thanks Partha > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@genesyslab.com] > Sent: Tuesday, March 12, 2013 9:35 PM > To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; > siprec@ietf.org > Subject: RE: [siprec] Call Hold / Mute etc, > > When a participant goes on hold, then it's a just the direction of the > participant stream gets modified like what is shown in section 3.3 of > call flow draft. According to what is specified in the protocol draft, > the media direction of the RS stream does not change since it also > signals that the recorded media is also being paused along with the > change of participant stream. > > Regards, > Henry > > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: March-12-13 11:44 AM > To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; > siprec@ietf.org > Subject: RE: [siprec] Call Hold / Mute etc, > > Hi all, > > I agree that pause and resume are the only terminology mentioned in > SIPREC(RFC 6341). "Call Hold" word is used in Sec 3.3. of > draft-ram-siprec-callflows for easy understanding. In case it confuses, > we will update with Pause and resume. Also, SIPREC protocol draft has > to be updated with pause & resume. > > Pause of the stream shall be achieved by setting inactive as direction > attribute and resume has to be mentioned by sendrecv direction > attribute. > > IMO, Mute & Unmute are not signaled between SIP entities. call hold > shall achieved in multiple ways in SDP like > > 1) Media direction attribute change as inactive > 2) Media direction attribute change as sendonly (Music on Hold) > 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) > > So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be removed. > The supplementary Service information shall be indicated through > metadata extension data if required. > > Thanks > Partha > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Henry Lum > > Sent: Monday, March 11, 2013 9:50 PM > > To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: Re: [siprec] Call Hold / Mute etc, > > > > I found an old discussion about mute/unmute and I think we forgot to > > post this on the mailing list and even incorporating the change in > the > > draft. > > > > The suggestion came from Andy to make a change to avoid using the > word > > mute/unmute to avoid any confusion of terminology on how mute is > > operated by the handsets. The a=inactive is still reserved for > pausing > > and unpausing the recorded media, while metadata is used for > conveying > > CS stream changes. > > > > Other than this I don't think there was any other mentions on mute > and > > this statement on the protocol draft. As Andy mentioned, this > statement > > has been on the protocol draft since -00. > > > > Regards, > > Henry > > > > > -----Original Message----- > > > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > > > Sent: Thursday, October 25, 2012 9:47 AM > > > To: Charles Eckel (eckelcu); Henry Lum > > > Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com > > > Subject: draft-ietf-siprec-protocol mute-unmute > > > > > > Hi, > > > > > > Changing the name of the thread to cover this specific point. > > > > > > Regarding the following part of the chain which refers to > mute/unmute > > on > > > the CS see comment below. > > > > > > > > > > > > > > > > > 5) Section 7.1.1.1 ends with: > > > > > > > > > > > > > > Note that when a CS > > > > > > > stream is muted/unmuted, this information is conveyed in > > the > > > > > > metadata > > > > > > > by the SRC. The SRC SHOULD NOT modify the media stream > > with > > > > > > > a=inactive for mute since this operation is reserved for > > > > pausing > > > > > > the > > > > > > > RS media. > > > > > > > > > > > > > > How does the SRC know that the stream is muted/unmuted? > > > > > > > > > > > > > > > > > > > > > > [hlum] The SRC should know that the stream is being set to > > inactive > > > > since > > > > > the SRC is sending the recorded media from the CS and the SRC > is > > in > > > > the > > > > > signaling path of the CS to know that a media stream is being > set > > to > > > > inactive. > > > > > > > > In my experience, even within the CS, the media stream does not > get > > > > changed from sendrecv to inactive during a mute operation. > Instead, > > the > > > > endpoint that mutes itself does so silently. In some cases, there > > is > > > > some proprietary signaling or media packet marking indicating > mute, > > but > > > > in general the SRC would not know if the endpoint was simply > quiet > > or > > > > really had done a mute locally. > > > > > > > > > > The problem here is terminology in that mute normally implies a > local > > > operation at the SIP UA rather than a hold operation which actually > > involves > > > SIP Signaling and an offer/answer. So I would suggest that we do > need > > to > > > make a minor change to the text to clarify what we are referring > to. > > > > > > Maybe something like this would help. > > > > > > "Note that when a CS stream's direction is changed, for example to > > inactive, > > > this information is conveyed in the metadata by the SRC. The SRC > > SHOULD > > > NOT in this case change the RS media stream direction since this > > operation > > > is reserved for pausing the RS media". > > > > > > This would avoid talking about services such as hold, mute etc. > > > > > > Regards > > > Andy > > > > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: March-10-13 11:52 AM > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: Re: [siprec] Call Hold / Mute etc, > > > > > > Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote > > > > > > > > > > I think we have discussed about representing hold/resume of CS from > > SRC > > > to > > > SRS in the past and the preference has been to use SIP/SDP > semantics > > > rather than re-inventing another approach in XML. Is there some > thing > > > that > > > has changed which requires us the re-look at this ? > > > > [AndyH] - Might be my memory that is the issue if you can point me at > > the discussion we had that would help. However I checked the protocol > > document and this has always stated that "inactive" on the RS means > > that the recording is paused and does not imply anything about the CS > > direction. The statement about indicating this is metadata was added > in > > version 01 of the protocol draft and has been unchanged since then. > > > > > > > > > On the other hand when you say recording is paused, how does SRC / > > SRS > > > know it is pause and not hold ? SIP semantics does not indicate any > > > thing. > > > So I believe SRS/SRC may not really differentiate on whether it is > > > pause/hold unless you have a some other means (non-SIP) to learn > the > > > same. > > > > [AndyH] Which is why I assume the protocol draft states that metadata > > is used for this. > > > > > > > > > > Regards, > > > Ram > > > > > > > > > > >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 > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From partha@parthasarathi.co.in Tue Mar 12 10:03:22 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 3172F11E80E1 for ; Tue, 12 Mar 2013 10:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCw49Kx-b1xl for ; Tue, 12 Mar 2013 10:03:21 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id EBC1911E80AE for ; Tue, 12 Mar 2013 10:03:20 -0700 (PDT) Received: from userPC (unknown [122.179.84.57]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 0DCB9190807E; Tue, 12 Mar 2013 17:03:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1363107800; bh=PolDBgeJnHAbJPiApDcp46BySda299n9inTdyEmJPyA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=L3jC2WzwM50wBp17uTEutO/4HWlfVfuCyWm3/a1VpT66FrWI1cun8rc6v2oVYm0ii /fZAc8DkgIDZQa2GuMlqRCCXgQAECu+NDnfJFL7cfTAE39tiST8Jk9CuRf00RGEvV/ HlVgJ9JItRB0bqmPMAspBEyV+1YhUhDHt8W4C0O4= From: "Parthasarathi R" To: "'Brian Rosen'" , "'Dave Higton'" References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net><9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net><00a201ce1f38$76b20190$641604b0$@co.in> <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com> <77C803CA-6326-4769-A0D3-49698792C2EC@brianrosen.net> In-Reply-To: <77C803CA-6326-4769-A0D3-49698792C2EC@brianrosen.net> Date: Tue, 12 Mar 2013 22:33:12 +0530 Message-ID: <00a401ce1f43$7e977c90$7bc675b0$@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: Ac4fPayg59qU5fbaTS+WkD+iGS+OmAABBNgw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.513F5FD8.00DD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: siprec@ietf.org Subject: Re: [siprec] Call Hold / Mute etc, 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, 12 Mar 2013 17:03:22 -0000 Brian, SIPREC pause operation is indicated to SRS from SRC. This helps emergency calls. Also, SRS shall identify "no packets" from RS RTP streams. Having said that, Mute does not falls under SIPREC pause operation as there is no signaling involved. In case SRC has to monitor RTP (media) layer and report as "SIPREC pause from SRC to SRS" based on no RTP packets for sustained time, then it is new Requirement for SRC. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Brian Rosen > Sent: Tuesday, March 12, 2013 9:52 PM > To: Dave Higton > Cc: siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, > > With my 9-1-1/1-1-2 hat on, it does, or at least it would be helpful to > know that there are no packets (or silence packets) for a sustained > time. > > Brian > > On Mar 12, 2013, at 12:11 PM, Dave Higton wrote: > > > AFAIK, mute has never been signalled on any telephone system. The > terminal just sends silence. > > > > In VoIP, there are of course two ways of sending silence: send > packets containing silence, or stop sending packets. > > > > Is knowledge of the mute state important? > > > > Dave > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > > Sent: 12 March 2013 16:05 > > To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; > siprec@ietf.org > > Subject: Re: [siprec] Call Hold / Mute etc, > > > > When a participant goes on hold, then it's a just the direction of > the participant stream gets modified like what is shown in section 3.3 > of call flow draft. According to what is specified in the protocol > draft, the media direction of the RS stream does not change since it > also signals that the recorded media is also being paused along with > the change of participant stream. > > > > Regards, > > Henry > > > > -----Original Message----- > > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > > Sent: March-12-13 11:44 AM > > To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; > siprec@ietf.org > > Subject: RE: [siprec] Call Hold / Mute etc, > > > > Hi all, > > > > I agree that pause and resume are the only terminology mentioned in > SIPREC(RFC 6341). "Call Hold" word is used in Sec 3.3. of draft-ram- > siprec-callflows for easy understanding. In case it confuses, we will > update with Pause and resume. Also, SIPREC protocol draft has to be > updated with pause & resume. > > > > Pause of the stream shall be achieved by setting inactive as > direction attribute and resume has to be mentioned by sendrecv > direction attribute. > > > > IMO, Mute & Unmute are not signaled between SIP entities. call hold > shall achieved in multiple ways in SDP like > > > > 1) Media direction attribute change as inactive > > 2) Media direction attribute change as sendonly (Music on Hold) > > 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) > > > > So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be > removed. > > The supplementary Service information shall be indicated through > metadata extension data if required. > > > > Thanks > > Partha > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Henry Lum > >> Sent: Monday, March 11, 2013 9:50 PM > >> To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org > >> Subject: Re: [siprec] Call Hold / Mute etc, > >> > >> I found an old discussion about mute/unmute and I think we forgot to > >> post this on the mailing list and even incorporating the change in > the > >> draft. > >> > >> The suggestion came from Andy to make a change to avoid using the > word > >> mute/unmute to avoid any confusion of terminology on how mute is > >> operated by the handsets. The a=inactive is still reserved for > pausing > >> and unpausing the recorded media, while metadata is used for > conveying > >> CS stream changes. > >> > >> Other than this I don't think there was any other mentions on mute > and > >> this statement on the protocol draft. As Andy mentioned, this > >> statement has been on the protocol draft since -00. > >> > >> Regards, > >> Henry > >> > >>> -----Original Message----- > >>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > >>> Sent: Thursday, October 25, 2012 9:47 AM > >>> To: Charles Eckel (eckelcu); Henry Lum > >>> Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com > >>> Subject: draft-ietf-siprec-protocol mute-unmute > >>> > >>> Hi, > >>> > >>> Changing the name of the thread to cover this specific point. > >>> > >>> Regarding the following part of the chain which refers to > >>> mute/unmute > >> on > >>> the CS see comment below. > >>> > >>>>>>> > >>>>>>> 5) Section 7.1.1.1 ends with: > >>>>>>> > >>>>>>> Note that when a CS > >>>>>>> stream is muted/unmuted, this information is conveyed in > >> the > >>>>>> metadata > >>>>>>> by the SRC. The SRC SHOULD NOT modify the media stream > >> with > >>>>>>> a=inactive for mute since this operation is reserved for > >>>> pausing > >>>>>> the > >>>>>>> RS media. > >>>>>>> > >>>>>>> How does the SRC know that the stream is muted/unmuted? > >>>>>>> > >>>>> > >>>>> > >>>>> [hlum] The SRC should know that the stream is being set to > >> inactive > >>>> since > >>>>> the SRC is sending the recorded media from the CS and the SRC is > >> in > >>>> the > >>>>> signaling path of the CS to know that a media stream is being > >>>>> set > >> to > >>>> inactive. > >>>> > >>>> In my experience, even within the CS, the media stream does not > >>>> get changed from sendrecv to inactive during a mute operation. > >>>> Instead, > >> the > >>>> endpoint that mutes itself does so silently. In some cases, there > >> is > >>>> some proprietary signaling or media packet marking indicating > >>>> mute, > >> but > >>>> in general the SRC would not know if the endpoint was simply quiet > >> or > >>>> really had done a mute locally. > >>>> > >>> > >>> The problem here is terminology in that mute normally implies a > >>> local operation at the SIP UA rather than a hold operation which > >>> actually > >> involves > >>> SIP Signaling and an offer/answer. So I would suggest that we do > >>> need > >> to > >>> make a minor change to the text to clarify what we are referring > to. > >>> > >>> Maybe something like this would help. > >>> > >>> "Note that when a CS stream's direction is changed, for example to > >> inactive, > >>> this information is conveyed in the metadata by the SRC. The SRC > >> SHOULD > >>> NOT in this case change the RS media stream direction since this > >> operation > >>> is reserved for pausing the RS media". > >>> > >>> This would avoid talking about services such as hold, mute etc. > >>> > >>> Regards > >>> Andy > >>> > >> > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Hutton, Andrew > >> Sent: March-10-13 11:52 AM > >> To: Ram Mohan R (rmohanr); siprec@ietf.org > >> Subject: Re: [siprec] Call Hold / Mute etc, > >> > >> > >> Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote > >> > >> > >>> > >>> I think we have discussed about representing hold/resume of CS from > >> SRC > >>> to > >>> SRS in the past and the preference has been to use SIP/SDP > semantics > >>> rather than re-inventing another approach in XML. Is there some > >>> thing that has changed which requires us the re-look at this ? > >> > >> [AndyH] - Might be my memory that is the issue if you can point me > at > >> the discussion we had that would help. However I checked the > protocol > >> document and this has always stated that "inactive" on the RS means > >> that the recording is paused and does not imply anything about the > CS > >> direction. The statement about indicating this is metadata was added > >> in version 01 of the protocol draft and has been unchanged since > then. > >> > >> > >> > >>> On the other hand when you say recording is paused, how does SRC / > >> SRS > >>> know it is pause and not hold ? SIP semantics does not indicate any > >>> thing. > >>> So I believe SRS/SRC may not really differentiate on whether it is > >>> pause/hold unless you have a some other means (non-SIP) to learn > the > >>> same. > >> > >> [AndyH] Which is why I assume the protocol draft states that > metadata > >> is used for this. > >> > >> > >>> > >>> Regards, > >>> Ram > >>> > >>>> > >>>> 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 > >> > >> _______________________________________________ > >> 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 > > > > > > NICE Systems UK Limited ("NICE") is registered in England under > company number, 3403044. The registered office of NICE is at Tollbar > Way, Hedge End, Southampton, Hampshire SO30 2ZP. > > > > Confidentiality: This communication and any attachments are intended > for the above-named persons only and may be confidential and/or legally > privileged. Any opinions expressed in this communication are not > necessarily those of NICE. If this communication has come to you in > error you must take no action based on it, nor must you copy or show it > to anyone; please delete/destroy and inform the sender by e-mail > immediately. > > > > Monitoring: NICE may monitor incoming and outgoing e-mails. > > > > Viruses: Although we have taken steps toward ensuring that this e- > mail and attachments are free from any virus, we advise that in keeping > with good computing practice the recipient should ensure they are > actually virus free. > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Mar 12 10:52:59 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 459F811E80FC for ; Tue, 12 Mar 2013 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyfD+aw-7pTC for ; Tue, 12 Mar 2013 10:52:57 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0D23911E80E9 for ; Tue, 12 Mar 2013 10:52:50 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E536D1EB84D1; Tue, 12 Mar 2013 18:52:38 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 18:52:38 +0100 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] Common unique-id from multiple SRC to SRS [was RE: Comments on draft-ietf-siprec-metadata-10.] Thread-Index: AQHOHN8+Pzm+iYfF6UCYgBtOnVo8+pideJAAgATbmjA= Date: Tue, 12 Mar 2013 17:52:38 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0689703B@MCHP04MSX.global-ad.net> References: In-Reply-To: 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] Common unique-id from multiple SRC to SRS [was RE: 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, 12 Mar 2013 17:52:59 -0000 Hi, I understand the use case although it might be argued that these are not sp= ecified in RFC 6341 and therefore might be considered out of scope. However the main issue is that if this is possible that the spec is clear w= hen an SRS might expect to encounter the same identifier from different SRC= 's and what this means to an SRS that receives it. At present it does not a= ppear to be. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: 09 March 2013 11:17 > To: siprec@ietf.org > Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was > RE: Comments on draft-ietf-siprec-metadata-10.] >=20 > To add to the below another simple case a CS with two endpoints where > each > point acts as SRC and records each side of the conversation via RS. So > you > would have two RS from two SRCs for the same CS. >=20 > Ram >=20 > > On 09/03/13 9:30 PM, "Ram Mohan R (rmohanr)" > wrote: >=20 > >Getting back late on this. I see Andy's question here is > > > >I am not convinced that we can say anything about the multiple > SRC > >case other than making sure we keep the id's unique I don't think we > said > >anything about this in the architecture draft. Can you describe the > use > >case and requirement that this covers. > > > > > >I think there would definitely be use-cases in real deployments where > >there would be multiple SRCs for a single CS. A simplest use-case that > I > >have heard many times is recording solution for Financial trading > centers > >where they prefer to have redundant recordings (recorded to different > >geographical sites). In such flows we *may* have multiple SRC's each > >having its own RS and recording the same CS. > > > >A simple scenario being both endpoints of a CS acting as SRC. You can > >visualize this to the section 3.1.2 of architecture draft with both > >endpoints having RS. > > > >Ram > > > > > >> On 07/03/13 10:38 PM, "Parthasarathi R" > >>wrote: > > > >>Andy, > >> > >>Sorry for the delay reply. As Paul mentioned, common unique-id from > >>multiple > >>SRC to SRS shall be discussed in Sec 6.10. The point to be noted is > that > >>SRS > >>should be in the position to receive the common unique-id from > multiple > >>SRC > >>and how unique-id is exchanged between SRCs is outside the scope of > >>SIPREC. > >>Please let us know in case you have any concern in this approach. > >> > >>Thanks > >>Partha > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Paul Kyzivat > >>> Sent: Saturday, February 02, 2013 11:25 PM > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. > >>> > >>> Some comments inline. > >>> > >>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: > >>> > >>> >>> 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." > >>> >> > >>> > > >>> > Ok but still it really does not have anything to do with > the > >>> case of 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. > >>> . > >>> > >>> IMO the point to get across is that multiple SRCs are *permitted* > to > >>> refer to the same entities by using a common UUID. (The SRS must > not > >>> consider this an error.) *How* the SRCs determine they are > referring to > >>> the same entity and obtain the same UUID for it is out of scope for > >>> this > >>> document. > >>> > >>> Perhaps it would be better to discuss this in 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 case other than making sure we keep the id's unique I don't > think > >>> we said anything about this in the architecture draft. Can you > describe > >>> the use case and requirement that this covers. > >>> > >>> Same comment as above. > >>> > >>> >>> 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 > >>> reason attribute if it is just free form text it is I think more > useful > >>> if we follow a defined structure such as RFC3326 for this. > >>> > >>> I agree this is worthy of some discussion as to whether 3326 is > >>> sufficient, or if we need a wider range of causes than that > provides. > >>> > >>> I agree with Andy that just having a string, that might or might > not be > >>> a standard string from 3326 is dubious. With that you can never be > >>> certain if the reason has the exact semantics of a 3326 reason. > >>> > >>> So I'm inclined to think we should be able to carry everything from > a > >>> Reason header. > >>> > >>> >>> 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 should be removed. > >>> > >>> Certainly we can't enumerate all the things we *don't* cover. > >>> IIRC this was added because some people expected that we *would* > >>> include > >>> info about desired retention policy, and we wanted to make it clear > >>> that > >>> we were not. I see no harm in that. > >>> > >>> > >>> _______________________________________________ > >>> 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 > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Mar 12 12:20:22 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 EE3ED11E8123 for ; Tue, 12 Mar 2013 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3v8AIvNv6sa for ; Tue, 12 Mar 2013 12:20:21 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id 2105011E8130 for ; Tue, 12 Mar 2013 12:20:19 -0700 (PDT) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Aj1b1l0020cQ2SLA9jLKZs; Tue, 12 Mar 2013 19:20:19 +0000 Received: from dhcp-11c0.meeting.ietf.org ([IPv6:2001:df8:0:16:ac21:7643:ad53:6187]) by omta10.emeryville.ca.mail.comcast.net with comcast id AjLJ1l00a5K13wh8WjLJAb; Tue, 12 Mar 2013 19:20:19 +0000 Message-ID: <513F7FF1.9050008@alum.mit.edu> Date: Wed, 13 Mar 2013 03:20:17 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF0689703B@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0689703B@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363116019; bh=n3f2eCbg2FKWMnc81NfeBYuixEkwMNq0JE9RXz6thHk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tgzK2N+rWK8r0x//2de45vrxm+tUUcIQVfqeBmR6qCTmxs+rqp6LDNuBjj00p/BuZ ah3P5+BnfaSaHRigfGuncCPHtj46k1u6/4gfjgWcV/Oi7rvde9VQ5skzdxCvmGc6A9 4kEyUWBuU0brv6vJTZTJ+tbn2UO+fYjBuApL8DJ/F7ci4zG5MmHWxCaPjcjBSL6C6L WlAIHVpw9kvHQKBa7voS26S67s9V/ZHOxmBZ3IZvtTAoeyuncCNPTcPBv4krqLMt4G nwZVBuFdumD/X05RxnPYRtjV/gesOpX/K7nWuo9DY+0oge4eIH6WGvqmmn4dMO4uky SR86Jt5DRPNAg== Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was RE: 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, 12 Mar 2013 19:20:22 -0000 On 3/13/13 1:52 AM, Hutton, Andrew wrote: > Hi, > > I understand the use case although it might be argued that these are not specified in RFC 6341 and therefore might be considered out of scope. > > However the main issue is that if this is possible that the spec is clear when an SRS might expect to encounter the same identifier from different SRC's and what this means to an SRS that receives it. At present it does not appear to be. IMO this behavior in intrinsic to the way IDs and metadata are defined. But I agree it might not be entirely clear, so we should do whatever we have to to ensure it *is* clear. Thanks, Paul > Regards > Andy > > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ram Mohan R (rmohanr) >> Sent: 09 March 2013 11:17 >> To: siprec@ietf.org >> Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was >> RE: Comments on draft-ietf-siprec-metadata-10.] >> >> To add to the below another simple case a CS with two endpoints where >> each >> point acts as SRC and records each side of the conversation via RS. So >> you >> would have two RS from two SRCs for the same CS. >> >> Ram >> >>> On 09/03/13 9:30 PM, "Ram Mohan R (rmohanr)" >> wrote: >> >>> Getting back late on this. I see Andy's question here is >>> >>> I am not convinced that we can say anything about the multiple >> SRC >>> case other than making sure we keep the id's unique I don't think we >> said >>> anything about this in the architecture draft. Can you describe the >> use >>> case and requirement that this covers. >>> >>> >>> I think there would definitely be use-cases in real deployments where >>> there would be multiple SRCs for a single CS. A simplest use-case that >> I >>> have heard many times is recording solution for Financial trading >> centers >>> where they prefer to have redundant recordings (recorded to different >>> geographical sites). In such flows we *may* have multiple SRC's each >>> having its own RS and recording the same CS. >>> >>> A simple scenario being both endpoints of a CS acting as SRC. You can >>> visualize this to the section 3.1.2 of architecture draft with both >>> endpoints having RS. >>> >>> Ram >>> >>> >>>> On 07/03/13 10:38 PM, "Parthasarathi R" >>>> wrote: >>> >>>> Andy, >>>> >>>> Sorry for the delay reply. As Paul mentioned, common unique-id from >>>> multiple >>>> SRC to SRS shall be discussed in Sec 6.10. The point to be noted is >> that >>>> SRS >>>> should be in the position to receive the common unique-id from >> multiple >>>> SRC >>>> and how unique-id is exchanged between SRCs is outside the scope of >>>> SIPREC. >>>> Please let us know in case you have any concern in this approach. >>>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: Saturday, February 02, 2013 11:25 PM >>>>> To: siprec@ietf.org >>>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >>>>> >>>>> Some comments inline. >>>>> >>>>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>>>> >>>>>>>> 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." >>>>>>> >>>>>> >>>>>> Ok but still it really does not have anything to do with >> the >>>>> case of 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. >>>>> . >>>>> >>>>> IMO the point to get across is that multiple SRCs are *permitted* >> to >>>>> refer to the same entities by using a common UUID. (The SRS must >> not >>>>> consider this an error.) *How* the SRCs determine they are >> referring to >>>>> the same entity and obtain the same UUID for it is out of scope for >>>>> this >>>>> document. >>>>> >>>>> Perhaps it would be better to discuss this in 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 case other than making sure we keep the id's unique I don't >> think >>>>> we said anything about this in the architecture draft. Can you >> describe >>>>> the use case and requirement that this covers. >>>>> >>>>> Same comment as above. >>>>> >>>>>>>> 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 >>>>> reason attribute if it is just free form text it is I think more >> useful >>>>> if we follow a defined structure such as RFC3326 for this. >>>>> >>>>> I agree this is worthy of some discussion as to whether 3326 is >>>>> sufficient, or if we need a wider range of causes than that >> provides. >>>>> >>>>> I agree with Andy that just having a string, that might or might >> not be >>>>> a standard string from 3326 is dubious. With that you can never be >>>>> certain if the reason has the exact semantics of a 3326 reason. >>>>> >>>>> So I'm inclined to think we should be able to carry everything from >> a >>>>> Reason header. >>>>> >>>>>>>> 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 should be removed. >>>>> >>>>> Certainly we can't enumerate all the things we *don't* cover. >>>>> IIRC this was added because some people expected that we *would* >>>>> include >>>>> info about desired retention policy, and we wanted to make it clear >>>>> that >>>>> we were not. I see no harm in that. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From ietf@meetecho.com Tue Mar 12 13:23:15 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 A0DCA11E8198 for ; Tue, 12 Mar 2013 13:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+zQrWx2JWLB for ; Tue, 12 Mar 2013 13:23:14 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg5.aruba.it [62.149.158.235]) by ietfa.amsl.com (Postfix) with ESMTP id C164F11E818E for ; Tue, 12 Mar 2013 13:23:09 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd05.ad.aruba.it with bizsmtp id AkP41l00U2w8SR601kP6jF; Tue, 12 Mar 2013 21:23:07 +0100 Date: Tue, 12 Mar 2013 16:23:02 -0400 (EDT) From: Meetecho Team To: siprec@ietf.org Message-ID: <25971327.11.1363119782193.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10_27921979.1363119782191" Subject: [siprec] Meetecho support for SIPREC session 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, 12 Mar 2013 20:23:15 -0000 ------=_Part_10_27921979.1363119782191 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the SIPREC WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/siprec The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_10_27921979.1363119782191-- From rmohanr@cisco.com Tue Mar 12 19:51: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 315BC11E80F9 for ; Tue, 12 Mar 2013 19:51:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po4pLCjGSQjz for ; Tue, 12 Mar 2013 19:51:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C04E911E8111 for ; Tue, 12 Mar 2013 19:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10407; q=dns/txt; s=iport; t=1363143074; x=1364352674; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=zKhiH8qeXR+aG+baL7Fk5tmSiKCZanNMs0x1k9iyKHc=; b=E7GeJbfPDfk3/UmGxRvOU3YaZm4mkZjB0TF0pd8dBoF7ufXjBkEjP6nE mbMTaG6vCKhQP8bMJxv9zjbV4bcz4cFQNOPso0XcfMCBNdyZEZ5Og69xI 2+/OYEv4GBUAWVYkXJIFCYNmBdP3vhFhrtwVPjiJIXig5r/MyaxFY/YXd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAvoP1GtJXHA/2dsb2JhbABDxHOBTBZtB4IpAQEBAwEBAQE3NBAHBgEIEQEDAQEBChQFBC4LFAMGCAIEEwgTh3MGDKBgky2NTxMEjlwGIBIGgllhA6dMgVSBKQ2CKA X-IronPort-AV: E=Sophos;i="4.84,833,1355097600"; d="scan'208";a="183827615" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 13 Mar 2013 02:51:14 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2D2pDxL013229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Mar 2013 02:51:13 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.34]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 21:51:13 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] Common unique-id from multiple SRC to SRS [was RE: Comments on draft-ietf-siprec-metadata-10.] Thread-Index: AQHOH5Wfp3bndhWfV0ymUCwmriV25w== Date: Wed, 13 Mar 2013 02:51:13 +0000 Message-ID: In-Reply-To: <513F7FF1.9050008@alum.mit.edu> 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: [72.163.212.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <930655E3973ED245B6EBA9508E26D6A8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was RE: 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: Wed, 13 Mar 2013 02:51:16 -0000 Can some one suggest on what text to include (in section 6.2.1) to make this clear ? Do we need some text on what SRS needs to do if it receives same identifier from two SRCs ? I assume that we don't want to mention about how SRCs ensure the same identifier is used for related RecordingSessions(of same CS). Ram > On 13/03/13 12:50 AM, "Paul Kyzivat" wrote: >On 3/13/13 1:52 AM, Hutton, Andrew wrote: >> Hi, >> >> I understand the use case although it might be argued that these are >>not specified in RFC 6341 and therefore might be considered out of scope. >> >> However the main issue is that if this is possible that the spec is >>clear when an SRS might expect to encounter the same identifier from >>different SRC's and what this means to an SRS that receives it. At >>present it does not appear to be. > >IMO this behavior in intrinsic to the way IDs and metadata are defined. >But I agree it might not be entirely clear, so we should do whatever we >have to to ensure it *is* clear. > > Thanks, > Paul > >> Regards >> Andy >> >> >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Ram Mohan R (rmohanr) >>> Sent: 09 March 2013 11:17 >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was >>> RE: Comments on draft-ietf-siprec-metadata-10.] >>> >>> To add to the below another simple case a CS with two endpoints where >>> each >>> point acts as SRC and records each side of the conversation via RS. So >>> you >>> would have two RS from two SRCs for the same CS. >>> >>> Ram >>> >>>> On 09/03/13 9:30 PM, "Ram Mohan R (rmohanr)" >>> wrote: >>> >>>> Getting back late on this. I see Andy's question here is >>>> >>>> I am not convinced that we can say anything about the multiple >>> SRC >>>> case other than making sure we keep the id's unique I don't think we >>> said >>>> anything about this in the architecture draft. Can you describe the >>> use >>>> case and requirement that this covers. >>>> >>>> >>>> I think there would definitely be use-cases in real deployments where >>>> there would be multiple SRCs for a single CS. A simplest use-case that >>> I >>>> have heard many times is recording solution for Financial trading >>> centers >>>> where they prefer to have redundant recordings (recorded to different >>>> geographical sites). In such flows we *may* have multiple SRC's each >>>> having its own RS and recording the same CS. >>>> >>>> A simple scenario being both endpoints of a CS acting as SRC. You can >>>> visualize this to the section 3.1.2 of architecture draft with both >>>> endpoints having RS. >>>> >>>> Ram >>>> >>>> >>>>> On 07/03/13 10:38 PM, "Parthasarathi R" >>>>> wrote: >>>> >>>>> Andy, >>>>> >>>>> Sorry for the delay reply. As Paul mentioned, common unique-id from >>>>> multiple >>>>> SRC to SRS shall be discussed in Sec 6.10. The point to be noted is >>> that >>>>> SRS >>>>> should be in the position to receive the common unique-id from >>> multiple >>>>> SRC >>>>> and how unique-id is exchanged between SRCs is outside the scope of >>>>> SIPREC. >>>>> Please let us know in case you have any concern in this approach. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Saturday, February 02, 2013 11:25 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >>>>>> >>>>>> Some comments inline. >>>>>> >>>>>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>>>>> >>>>>>>>> 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." >>>>>>>> >>>>>>> >>>>>>> Ok but still it really does not have anything to do with >>> the >>>>>> case of 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. >>>>>> . >>>>>> >>>>>> IMO the point to get across is that multiple SRCs are *permitted* >>> to >>>>>> refer to the same entities by using a common UUID. (The SRS must >>> not >>>>>> consider this an error.) *How* the SRCs determine they are >>> referring to >>>>>> the same entity and obtain the same UUID for it is out of scope for >>>>>> this >>>>>> document. >>>>>> >>>>>> Perhaps it would be better to discuss this in 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 case other than making sure we keep the id's unique I don't >>> think >>>>>> we said anything about this in the architecture draft. Can you >>> describe >>>>>> the use case and requirement that this covers. >>>>>> >>>>>> Same comment as above. >>>>>> >>>>>>>>> 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 >>>>>> reason attribute if it is just free form text it is I think more >>> useful >>>>>> if we follow a defined structure such as RFC3326 for this. >>>>>> >>>>>> I agree this is worthy of some discussion as to whether 3326 is >>>>>> sufficient, or if we need a wider range of causes than that >>> provides. >>>>>> >>>>>> I agree with Andy that just having a string, that might or might >>> not be >>>>>> a standard string from 3326 is dubious. With that you can never be >>>>>> certain if the reason has the exact semantics of a 3326 reason. >>>>>> >>>>>> So I'm inclined to think we should be able to carry everything from >>> a >>>>>> Reason header. >>>>>> >>>>>>>>> 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 should be removed. >>>>>> >>>>>> Certainly we can't enumerate all the things we *don't* cover. >>>>>> IIRC this was added because some people expected that we *would* >>>>>> include >>>>>> info about desired retention policy, and we wanted to make it clear >>>>>> that >>>>>> we were not. I see no harm in that. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Tue Mar 12 20:25: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 BA77A11E80F0 for ; Tue, 12 Mar 2013 20:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mukhu-aP0-dk for ; Tue, 12 Mar 2013 20:24:59 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 673A111E80D1 for ; Tue, 12 Mar 2013 20:24:59 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id ArG71l0090EZKEL5DrQy39; Wed, 13 Mar 2013 03:24:58 +0000 Received: from map-experiment-12878.meeting.ietf.org ([IPv6:2001:df8:0:128:498:e025:3033:fbe5]) by omta01.westchester.pa.mail.comcast.net with comcast id ArQy1l00F0Q4PXh3MrQykR; Wed, 13 Mar 2013 03:24:58 +0000 Message-ID: <513FF189.2040005@alum.mit.edu> Date: Wed, 13 Mar 2013 11:24:57 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363145098; bh=qyNMiNoQ+cEWfLHc4N8ZkcK+JVzE+LGYwYA56bqYoOk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KbRTX6F/GHuFRB6egbWJZc68S4fHkEX40IWpfLhS/LdQ5eQOnZKTSzCXUJtTEhp7W POmX427rbCYKdJ7RkvtJms6XbOH/VuXEzQVrwLYA7aI2wWrTcK2supglNpoun0GvMs TWJECK9TX3aCCTZaNh8gWJ9b4nCgpRLc3lk31f2YeG0rJN/54b/eLyGBNXRieKbJkP VlisG8FpRDrp/eluf76qiiAosbQPShhWU9jRTZzgFVlrHLxV3SnPCJ37hbBkKDC4zt CtI7066PyIlB+RwGOx63PqJYUzHYsNU+dvGn/hUpNPMkcsuxWb15VyyaqGyywrkzIy A5ivoK6A4mJZA== Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was RE: 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: Wed, 13 Mar 2013 03:25:00 -0000 On 3/13/13 10:51 AM, Ram Mohan R (rmohanr) wrote: > Can some one suggest on what text to include (in section 6.2.1) to make > this clear ? > Do we need some text on what SRS needs to do if it receives same > identifier from two SRCs ? I went looking for a place. 6.2.1 is not a sufficient place - that is only one place where there is a reference by id. The behavior applies to all references. I finally decided there is no good place in the metadata document - it doesn't talk about SRC and SRS behavior. That is done in the protocol document. I think the best place would be in section 9.2 of the protocol document. How about adding the following at the end of that section: "The metadata received by the SRS frequently contains ID elements used to cross reference one element to another. An element containing the definition of an ID, and an element containing a reference to that ID will often be received from the same SRC. But it is also valid for those elements to be received from different SRCs. The SRS MUST NOT consider this an error." Thanks, Paul > I assume that we don't want to mention about how SRCs ensure the same > identifier is used for related RecordingSessions(of same CS). > > Ram > >> On 13/03/13 12:50 AM, "Paul Kyzivat" wrote: > >> On 3/13/13 1:52 AM, Hutton, Andrew wrote: >>> Hi, >>> >>> I understand the use case although it might be argued that these are >>> not specified in RFC 6341 and therefore might be considered out of scope. >>> >>> However the main issue is that if this is possible that the spec is >>> clear when an SRS might expect to encounter the same identifier from >>> different SRC's and what this means to an SRS that receives it. At >>> present it does not appear to be. >> >> IMO this behavior in intrinsic to the way IDs and metadata are defined. >> But I agree it might not be entirely clear, so we should do whatever we >> have to to ensure it *is* clear. >> >> Thanks, >> Paul >> >>> Regards >>> Andy >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Ram Mohan R (rmohanr) >>>> Sent: 09 March 2013 11:17 >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was >>>> RE: Comments on draft-ietf-siprec-metadata-10.] >>>> >>>> To add to the below another simple case a CS with two endpoints where >>>> each >>>> point acts as SRC and records each side of the conversation via RS. So >>>> you >>>> would have two RS from two SRCs for the same CS. >>>> >>>> Ram >>>> >>>>> On 09/03/13 9:30 PM, "Ram Mohan R (rmohanr)" >>>> wrote: >>>> >>>>> Getting back late on this. I see Andy's question here is >>>>> >>>>> I am not convinced that we can say anything about the multiple >>>> SRC >>>>> case other than making sure we keep the id's unique I don't think we >>>> said >>>>> anything about this in the architecture draft. Can you describe the >>>> use >>>>> case and requirement that this covers. >>>>> >>>>> >>>>> I think there would definitely be use-cases in real deployments where >>>>> there would be multiple SRCs for a single CS. A simplest use-case that >>>> I >>>>> have heard many times is recording solution for Financial trading >>>> centers >>>>> where they prefer to have redundant recordings (recorded to different >>>>> geographical sites). In such flows we *may* have multiple SRC's each >>>>> having its own RS and recording the same CS. >>>>> >>>>> A simple scenario being both endpoints of a CS acting as SRC. You can >>>>> visualize this to the section 3.1.2 of architecture draft with both >>>>> endpoints having RS. >>>>> >>>>> Ram >>>>> >>>>> >>>>>> On 07/03/13 10:38 PM, "Parthasarathi R" >>>>>> wrote: >>>>> >>>>>> Andy, >>>>>> >>>>>> Sorry for the delay reply. As Paul mentioned, common unique-id from >>>>>> multiple >>>>>> SRC to SRS shall be discussed in Sec 6.10. The point to be noted is >>>> that >>>>>> SRS >>>>>> should be in the position to receive the common unique-id from >>>> multiple >>>>>> SRC >>>>>> and how unique-id is exchanged between SRCs is outside the scope of >>>>>> SIPREC. >>>>>> Please let us know in case you have any concern in this approach. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>>> Behalf Of Paul Kyzivat >>>>>>> Sent: Saturday, February 02, 2013 11:25 PM >>>>>>> To: siprec@ietf.org >>>>>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10. >>>>>>> >>>>>>> Some comments inline. >>>>>>> >>>>>>> On 1/29/13 11:32 AM, Hutton, Andrew wrote: >>>>>>> >>>>>>>>>> 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." >>>>>>>>> >>>>>>>> >>>>>>>> Ok but still it really does not have anything to do with >>>> the >>>>>>> case of 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. >>>>>>> . >>>>>>> >>>>>>> IMO the point to get across is that multiple SRCs are *permitted* >>>> to >>>>>>> refer to the same entities by using a common UUID. (The SRS must >>>> not >>>>>>> consider this an error.) *How* the SRCs determine they are >>>> referring to >>>>>>> the same entity and obtain the same UUID for it is out of scope for >>>>>>> this >>>>>>> document. >>>>>>> >>>>>>> Perhaps it would be better to discuss this in 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 case other than making sure we keep the id's unique I don't >>>> think >>>>>>> we said anything about this in the architecture draft. Can you >>>> describe >>>>>>> the use case and requirement that this covers. >>>>>>> >>>>>>> Same comment as above. >>>>>>> >>>>>>>>>> 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 >>>>>>> reason attribute if it is just free form text it is I think more >>>> useful >>>>>>> if we follow a defined structure such as RFC3326 for this. >>>>>>> >>>>>>> I agree this is worthy of some discussion as to whether 3326 is >>>>>>> sufficient, or if we need a wider range of causes than that >>>> provides. >>>>>>> >>>>>>> I agree with Andy that just having a string, that might or might >>>> not be >>>>>>> a standard string from 3326 is dubious. With that you can never be >>>>>>> certain if the reason has the exact semantics of a 3326 reason. >>>>>>> >>>>>>> So I'm inclined to think we should be able to carry everything from >>>> a >>>>>>> Reason header. >>>>>>> >>>>>>>>>> 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 should be removed. >>>>>>> >>>>>>> Certainly we can't enumerate all the things we *don't* cover. >>>>>>> IIRC this was added because some people expected that we *would* >>>>>>> include >>>>>>> info about desired retention policy, and we wanted to make it clear >>>>>>> that >>>>>>> we were not. I see no harm in that. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> _______________________________________________ >>> 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 pkyzivat@alum.mit.edu Wed Mar 13 05:39:05 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 0732D21F8D1C for ; Wed, 13 Mar 2013 05:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXbgsiLNYThS for ; Wed, 13 Mar 2013 05:39:03 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id BD89E21F8D1A for ; Wed, 13 Mar 2013 05:39:03 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta12.emeryville.ca.mail.comcast.net with comcast id AzxX1l0031zF43QAC0f3QC; Wed, 13 Mar 2013 12:39:03 +0000 Received: from dhcp-11c0.meeting.ietf.org ([IPv6:2001:df8:0:16:ec98:1711:aa4f:7da3]) by omta24.emeryville.ca.mail.comcast.net with comcast id B0f21l00g1qbhlv8k0f2UM; Wed, 13 Mar 2013 12:39:03 +0000 Message-ID: <51407366.5010401@alum.mit.edu> Date: Wed, 13 Mar 2013 20:39:02 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net><9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net><00a201ce1f38$76b20190$641604b0$@co.in> <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com> <77C803CA-6326-4769-A0D3-49698792C2EC@brianrosen.net> <05D56509F27CCE4DAF8136C02386880DC02F244A@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880DC02F244A@exc01.dss.lan> 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=1363178343; bh=/oVqGxPgFoj0epV2wPgP9eywlnrzlbJbWB3EfKQmVbA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=d53fL1SV03Atw8XupMpRTx/yIFPekrU9pBMABgrNj/QRHmGO43IoKyKZtCWK5o1RB D5C12M48Ltd2yeGBrD891BQaOW7cE+7rQpDjG3LvshuM80E7nDWOsTP+klUJb07BP2 qcPvoxSN/0XY3NdBEcHkzXrbl8aN2T4Y1CcD6HUvzsHwDyvl2Tdabe7BdBQx6lZMEy tAHcGYi3DLedNIC+lsJG00Kc4ayvn4BVItX7BEr1cE4XmnMs2EbMEqGvub67LrMjIf AXxJYBN6u6Vw4ttBHKaVkuuGe2KxI1fihcBg8tL86ulgZ3wXaxYWVGjm7+YOSK2cYc 1cnx9VTBqja5w== Subject: Re: [siprec] Call Hold / Mute etc, 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, 13 Mar 2013 12:39:05 -0000 I don't understand what you and Brian are asking. It is not the intent of SIPREC to alter in any way what goes on in the communication session. (Except for signaling that recording is happening.) If emergency calls block, or alter the behavior of hold, then so be it. The recorder should record whatever happens, unless recording is turned off. (And I guess for emergency calls the recording is never turned off.) Thanks, Paul On 3/13/13 12:34 AM, Michael Smith wrote: > With my 9-1-1/1-1-2 hat on as well, +1 to Brian's comment. > > If you put a SIP session on hold, the media stops in both directions. We don't want to do that on an emergency call - we want the caller's media to continue so it can be recorded. So we have the agent mute their own transmit. We want the SRC to continue to receive the caller's audio, even if the agent's UA mutes the caller's audio to the agent's ear (which may be appropriate). > > A similar use case for non-emergency calls would be where we want the caller's comments recorded while the agent's voice is muted. Hearing them gripe about your product, company, or support is good QA info. > > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Tuesday, March 12, 2013 12:22 PM > To: Dave Higton > Cc: siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, > > With my 9-1-1/1-1-2 hat on, it does, or at least it would be helpful to know that there are no packets (or silence packets) for a sustained time. > > Brian > > On Mar 12, 2013, at 12:11 PM, Dave Higton wrote: > >> AFAIK, mute has never been signalled on any telephone system. The terminal just sends silence. >> >> In VoIP, there are of course two ways of sending silence: send packets containing silence, or stop sending packets. >> >> Is knowledge of the mute state important? >> >> Dave >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Henry Lum >> Sent: 12 March 2013 16:05 >> To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; >> siprec@ietf.org >> Subject: Re: [siprec] Call Hold / Mute etc, >> >> When a participant goes on hold, then it's a just the direction of the participant stream gets modified like what is shown in section 3.3 of call flow draft. According to what is specified in the protocol draft, the media direction of the RS stream does not change since it also signals that the recorded media is also being paused along with the change of participant stream. >> >> Regards, >> Henry >> >> -----Original Message----- >> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >> Sent: March-12-13 11:44 AM >> To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; >> siprec@ietf.org >> Subject: RE: [siprec] Call Hold / Mute etc, >> >> Hi all, >> >> I agree that pause and resume are the only terminology mentioned in SIPREC(RFC 6341). "Call Hold" word is used in Sec 3.3. of draft-ram-siprec-callflows for easy understanding. In case it confuses, we will update with Pause and resume. Also, SIPREC protocol draft has to be updated with pause & resume. >> >> Pause of the stream shall be achieved by setting inactive as direction attribute and resume has to be mentioned by sendrecv direction attribute. >> >> IMO, Mute & Unmute are not signaled between SIP entities. call hold >> shall achieved in multiple ways in SDP like >> >> 1) Media direction attribute change as inactive >> 2) Media direction attribute change as sendonly (Music on Hold) >> 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) >> >> So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be removed. >> The supplementary Service information shall be indicated through metadata extension data if required. >> >> Thanks >> Partha >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Henry Lum >>> Sent: Monday, March 11, 2013 9:50 PM >>> To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org >>> Subject: Re: [siprec] Call Hold / Mute etc, >>> >>> I found an old discussion about mute/unmute and I think we forgot to >>> post this on the mailing list and even incorporating the change in >>> the draft. >>> >>> The suggestion came from Andy to make a change to avoid using the >>> word mute/unmute to avoid any confusion of terminology on how mute is >>> operated by the handsets. The a=inactive is still reserved for >>> pausing and unpausing the recorded media, while metadata is used for >>> conveying CS stream changes. >>> >>> Other than this I don't think there was any other mentions on mute >>> and this statement on the protocol draft. As Andy mentioned, this >>> statement has been on the protocol draft since -00. >>> >>> Regards, >>> Henry >>> >>>> -----Original Message----- >>>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>>> Sent: Thursday, October 25, 2012 9:47 AM >>>> To: Charles Eckel (eckelcu); Henry Lum >>>> Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com >>>> Subject: draft-ietf-siprec-protocol mute-unmute >>>> >>>> Hi, >>>> >>>> Changing the name of the thread to cover this specific point. >>>> >>>> Regarding the following part of the chain which refers to >>>> mute/unmute >>> on >>>> the CS see comment below. >>>> >>>>>>>> >>>>>>>> 5) Section 7.1.1.1 ends with: >>>>>>>> >>>>>>>> Note that when a CS >>>>>>>> stream is muted/unmuted, this information is conveyed in >>> the >>>>>>> metadata >>>>>>>> by the SRC. The SRC SHOULD NOT modify the media stream >>> with >>>>>>>> a=inactive for mute since this operation is reserved for >>>>> pausing >>>>>>> the >>>>>>>> RS media. >>>>>>>> >>>>>>>> How does the SRC know that the stream is muted/unmuted? >>>>>>>> >>>>>> >>>>>> >>>>>> [hlum] The SRC should know that the stream is being set to >>> inactive >>>>> since >>>>>> the SRC is sending the recorded media from the CS and the SRC is >>> in >>>>> the >>>>>> signaling path of the CS to know that a media stream is being set >>> to >>>>> inactive. >>>>> >>>>> In my experience, even within the CS, the media stream does not get >>>>> changed from sendrecv to inactive during a mute operation. >>>>> Instead, >>> the >>>>> endpoint that mutes itself does so silently. In some cases, there >>> is >>>>> some proprietary signaling or media packet marking indicating mute, >>> but >>>>> in general the SRC would not know if the endpoint was simply quiet >>> or >>>>> really had done a mute locally. >>>>> >>>> >>>> The problem here is terminology in that mute normally implies a >>>> local operation at the SIP UA rather than a hold operation which >>>> actually >>> involves >>>> SIP Signaling and an offer/answer. So I would suggest that we do >>>> need >>> to >>>> make a minor change to the text to clarify what we are referring to. >>>> >>>> Maybe something like this would help. >>>> >>>> "Note that when a CS stream's direction is changed, for example to >>> inactive, >>>> this information is conveyed in the metadata by the SRC. The SRC >>> SHOULD >>>> NOT in this case change the RS media stream direction since this >>> operation >>>> is reserved for pausing the RS media". >>>> >>>> This would avoid talking about services such as hold, mute etc. >>>> >>>> Regards >>>> Andy >>>> >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: March-10-13 11:52 AM >>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>> Subject: Re: [siprec] Call Hold / Mute etc, >>> >>> >>> Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote >>> >>> >>>> >>>> I think we have discussed about representing hold/resume of CS from >>> SRC >>>> to >>>> SRS in the past and the preference has been to use SIP/SDP semantics >>>> rather than re-inventing another approach in XML. Is there some >>>> thing that has changed which requires us the re-look at this ? >>> >>> [AndyH] - Might be my memory that is the issue if you can point me at >>> the discussion we had that would help. However I checked the protocol >>> document and this has always stated that "inactive" on the RS means >>> that the recording is paused and does not imply anything about the CS >>> direction. The statement about indicating this is metadata was added >>> in version 01 of the protocol draft and has been unchanged since then. >>> >>> >>> >>>> On the other hand when you say recording is paused, how does SRC / >>> SRS >>>> know it is pause and not hold ? SIP semantics does not indicate any >>>> thing. >>>> So I believe SRS/SRC may not really differentiate on whether it is >>>> pause/hold unless you have a some other means (non-SIP) to learn the >>>> same. >>> >>> [AndyH] Which is why I assume the protocol draft states that metadata >>> is used for this. >>> >>> >>>> >>>> Regards, >>>> Ram >>>> >>>>> >>>>> 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 >>> >>> _______________________________________________ >>> 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 >> >> >> NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP. >> >> Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. >> >> Monitoring: NICE may monitor incoming and outgoing e-mails. >> >> Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From MSmith@dss-corp.com Wed Mar 13 07:24: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 1FFC421F8DB9 for ; Wed, 13 Mar 2013 07:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZGAWoiLqfnm for ; Wed, 13 Mar 2013 07:24:56 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67F21F8CB7 for ; Wed, 13 Mar 2013 07:24:56 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h826j20171sn for ; Wed, 13 Mar 2013 10:29:04 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Wed, 13 Mar 2013 10:29:03 -0400 Received: from EXC01.dss.lan ([fe80::6540:2e8d:f781:8389]) by exc01.dss.lan ([fe80::6540:2e8d:f781:8389%16]) with mapi; Wed, 13 Mar 2013 10:24:54 -0400 From: Michael Smith To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Call Hold / Mute etc, Thread-Index: AQHOHOB1plsJ1cF1iE61wqNlQYlP35ieVscAgADo1ICAABglAIABmgyAgAGIZYCAAAXSgIAAAcKAgAAC1gD//71MUIABluEA///ZxhA= Date: Wed, 13 Mar 2013 14:24:36 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880DC02F27E4@exc01.dss.lan> References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net><9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net><00a201ce1f38$76b20190$641604b0$@co.in> <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com> <77C803CA-6326-4769-A0D3-49698792C2EC@brianrosen.net> <05D56509F27CCE4DAF8136C02386880DC02F244A@exc01.dss.lan> <51407366.5010401@alum.mit.edu> In-Reply-To: <51407366.5010401@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201303131429030091298 Subject: Re: [siprec] Call Hold / Mute etc, 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, 13 Mar 2013 14:24:58 -0000 We were responding to Dave Higton's email below, which made general stateme= nts about mute - that's all. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Wednesday, March 13, 2013 8:39 AM To: siprec@ietf.org Subject: Re: [siprec] Call Hold / Mute etc, I don't understand what you and Brian are asking. It is not the intent of SIPREC to alter in any way what goes on in the comm= unication session. (Except for signaling that recording is happening.) If emergency calls block, or alter the behavior of hold, then so be it.=20 The recorder should record whatever happens, unless recording is turned off= . (And I guess for emergency calls the recording is never turned off.) Thanks, Paul On 3/13/13 12:34 AM, Michael Smith wrote: > With my 9-1-1/1-1-2 hat on as well, +1 to Brian's comment. > > If you put a SIP session on hold, the media stops in both directions. We = don't want to do that on an emergency call - we want the caller's media to = continue so it can be recorded. So we have the agent mute their own transmi= t. We want the SRC to continue to receive the caller's audio, even if the a= gent's UA mutes the caller's audio to the agent's ear (which may be appropr= iate). > > A similar use case for non-emergency calls would be where we want the cal= ler's comments recorded while the agent's voice is muted. Hearing them grip= e about your product, company, or support is good QA info. > > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Brian Rosen > Sent: Tuesday, March 12, 2013 12:22 PM > To: Dave Higton > Cc: siprec@ietf.org > Subject: Re: [siprec] Call Hold / Mute etc, > > With my 9-1-1/1-1-2 hat on, it does, or at least it would be helpful to k= now that there are no packets (or silence packets) for a sustained time. > > Brian > > On Mar 12, 2013, at 12:11 PM, Dave Higton wrote: > >> AFAIK, mute has never been signalled on any telephone system. The termi= nal just sends silence. >> >> In VoIP, there are of course two ways of sending silence: send packets c= ontaining silence, or stop sending packets. >> >> Is knowledge of the mute state important? >> >> Dave >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Henry Lum >> Sent: 12 March 2013 16:05 >> To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)';=20 >> siprec@ietf.org >> Subject: Re: [siprec] Call Hold / Mute etc, >> >> When a participant goes on hold, then it's a just the direction of the p= articipant stream gets modified like what is shown in section 3.3 of call f= low draft. According to what is specified in the protocol draft, the media = direction of the RS stream does not change since it also signals that the r= ecorded media is also being paused along with the change of participant str= eam. >> >> Regards, >> Henry >> >> -----Original Message----- >> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >> Sent: March-12-13 11:44 AM >> To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)';=20 >> siprec@ietf.org >> Subject: RE: [siprec] Call Hold / Mute etc, >> >> Hi all, >> >> I agree that pause and resume are the only terminology mentioned in SIPR= EC(RFC 6341). "Call Hold" word is used in Sec 3.3. of draft-ram-siprec-call= flows for easy understanding. In case it confuses, we will update with Paus= e and resume. Also, SIPREC protocol draft has to be updated with pause & re= sume. >> >> Pause of the stream shall be achieved by setting inactive as direction a= ttribute and resume has to be mentioned by sendrecv direction attribute. >> >> IMO, Mute & Unmute are not signaled between SIP entities. call hold=20 >> shall achieved in multiple ways in SDP like >> >> 1) Media direction attribute change as inactive >> 2) Media direction attribute change as sendonly (Music on Hold) >> 3) changing the "c" line with 0.0.0.0. (Approach is deprecated) >> >> So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be removed. >> The supplementary Service information shall be indicated through metadat= a extension data if required. >> >> Thanks >> Partha >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Henry Lum >>> Sent: Monday, March 11, 2013 9:50 PM >>> To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org >>> Subject: Re: [siprec] Call Hold / Mute etc, >>> >>> I found an old discussion about mute/unmute and I think we forgot to=20 >>> post this on the mailing list and even incorporating the change in=20 >>> the draft. >>> >>> The suggestion came from Andy to make a change to avoid using the=20 >>> word mute/unmute to avoid any confusion of terminology on how mute=20 >>> is operated by the handsets. The a=3Dinactive is still reserved for=20 >>> pausing and unpausing the recorded media, while metadata is used for=20 >>> conveying CS stream changes. >>> >>> Other than this I don't think there was any other mentions on mute=20 >>> and this statement on the protocol draft. As Andy mentioned, this=20 >>> statement has been on the protocol draft since -00. >>> >>> Regards, >>> Henry >>> >>>> -----Original Message----- >>>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>>> Sent: Thursday, October 25, 2012 9:47 AM >>>> To: Charles Eckel (eckelcu); Henry Lum >>>> Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com >>>> Subject: draft-ietf-siprec-protocol mute-unmute >>>> >>>> Hi, >>>> >>>> Changing the name of the thread to cover this specific point. >>>> >>>> Regarding the following part of the chain which refers to=20 >>>> mute/unmute >>> on >>>> the CS see comment below. >>>> >>>>>>>> >>>>>>>> 5) Section 7.1.1.1 ends with: >>>>>>>> >>>>>>>> Note that when a CS >>>>>>>> stream is muted/unmuted, this information is conveyed in >>> the >>>>>>> metadata >>>>>>>> by the SRC. The SRC SHOULD NOT modify the media stream >>> with >>>>>>>> a=3Dinactive for mute since this operation is reserved for >>>>> pausing >>>>>>> the >>>>>>>> RS media. >>>>>>>> >>>>>>>> How does the SRC know that the stream is muted/unmuted? >>>>>>>> >>>>>> >>>>>> >>>>>> [hlum] The SRC should know that the stream is being set to >>> inactive >>>>> since >>>>>> the SRC is sending the recorded media from the CS and the SRC is >>> in >>>>> the >>>>>> signaling path of the CS to know that a media stream is being set >>> to >>>>> inactive. >>>>> >>>>> In my experience, even within the CS, the media stream does not=20 >>>>> get changed from sendrecv to inactive during a mute operation. >>>>> Instead, >>> the >>>>> endpoint that mutes itself does so silently. In some cases, there >>> is >>>>> some proprietary signaling or media packet marking indicating=20 >>>>> mute, >>> but >>>>> in general the SRC would not know if the endpoint was simply quiet >>> or >>>>> really had done a mute locally. >>>>> >>>> >>>> The problem here is terminology in that mute normally implies a=20 >>>> local operation at the SIP UA rather than a hold operation which=20 >>>> actually >>> involves >>>> SIP Signaling and an offer/answer. So I would suggest that we do=20 >>>> need >>> to >>>> make a minor change to the text to clarify what we are referring to. >>>> >>>> Maybe something like this would help. >>>> >>>> "Note that when a CS stream's direction is changed, for example to >>> inactive, >>>> this information is conveyed in the metadata by the SRC. The SRC >>> SHOULD >>>> NOT in this case change the RS media stream direction since this >>> operation >>>> is reserved for pausing the RS media". >>>> >>>> This would avoid talking about services such as hold, mute etc. >>>> >>>> Regards >>>> Andy >>>> >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Hutton, Andrew >>> Sent: March-10-13 11:52 AM >>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>> Subject: Re: [siprec] Call Hold / Mute etc, >>> >>> >>> Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote >>> >>> >>>> >>>> I think we have discussed about representing hold/resume of CS from >>> SRC >>>> to >>>> SRS in the past and the preference has been to use SIP/SDP=20 >>>> semantics rather than re-inventing another approach in XML. Is=20 >>>> there some thing that has changed which requires us the re-look at thi= s ? >>> >>> [AndyH] - Might be my memory that is the issue if you can point me=20 >>> at the discussion we had that would help. However I checked the=20 >>> protocol document and this has always stated that "inactive" on the=20 >>> RS means that the recording is paused and does not imply anything=20 >>> about the CS direction. The statement about indicating this is=20 >>> metadata was added in version 01 of the protocol draft and has been unc= hanged since then. >>> >>> >>> >>>> On the other hand when you say recording is paused, how does SRC / >>> SRS >>>> know it is pause and not hold ? SIP semantics does not indicate any=20 >>>> thing. >>>> So I believe SRS/SRC may not really differentiate on whether it is=20 >>>> pause/hold unless you have a some other means (non-SIP) to learn=20 >>>> the same. >>> >>> [AndyH] Which is why I assume the protocol draft states that=20 >>> metadata is used for this. >>> >>> >>>> >>>> Regards, >>>> Ram >>>> >>>>> >>>>> 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 >>> >>> _______________________________________________ >>> 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 >> >> >> 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 privil= eged. Any opinions expressed in this communication are not necessarily thos= e of NICE. If this communication has come to you in error you must take no = action based on it, nor must you copy or show it to anyone; please delete/d= estroy and inform the sender by e-mail immediately. >> >> Monitoring: NICE may monitor incoming and outgoing e-mails. >> >> Viruses: Although we have taken steps toward ensuring that this e-mail a= nd attachments are free from any virus, we advise that in keeping with good= computing practice the recipient should ensure they are actually virus fre= e. >> _______________________________________________ >> 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 ietf@meetecho.com Wed Mar 13 07:37:31 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 73A5D21F8E0C for ; Wed, 13 Mar 2013 07:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDLNAa5hje-4 for ; Wed, 13 Mar 2013 07:37:30 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpdg2.aruba.it [62.149.158.232]) by ietfa.amsl.com (Postfix) with ESMTP id 3820C21F8E0B for ; Wed, 13 Mar 2013 07:37:29 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd02.ad.aruba.it with bizsmtp id B2dQ1l0132w8SR6012dSG3; Wed, 13 Mar 2013 15:37:27 +0100 Date: Wed, 13 Mar 2013 10:37:22 -0400 (EDT) From: Meetecho Team To: siprec@ietf.org Message-ID: <4916061.1.1363185443141.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_2614099.1363185443007" Subject: [siprec] SIPREC session recording available 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, 13 Mar 2013 14:37:31 -0000 ------=_Part_0_2614099.1363185443007 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the SIPREC WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#SIPREC In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_2614099.1363185443007-- From br@brianrosen.net Tue Mar 19 13:59:14 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 E01BC21F8D8C for ; Tue, 19 Mar 2013 13:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.387 X-Spam-Level: X-Spam-Status: No, score=-99.387 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXuBrb2Y4gbf for ; Tue, 19 Mar 2013 13:59:13 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id AD93C21F8D85 for ; Tue, 19 Mar 2013 13:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=Mime-Version:To:Date:Message-Id:Subject:Content-Type:From; bh=dCm/4UbmbKDRMbptjOtahRfS6HEdgxxTKlhgixLA1cA=; b=Jh+GP2l5B7KpMV292Y4pnOaU6eXtKs1cnftQo8EMlKpTdo/bCkDobww4QgjcnDxCphZQKdf8F4boZOS6i2YS1P7ijNh2zbvyq9b3Gszaq6Fac0q/iarslL/VXvmYI2n5DbyzaY79AJxAJEcRzFV3sX+nF0fKPQ+4P+4nOP+XobQ=; Received: from neustargw.va.neustar.com ([209.173.53.233]:47526 helo=[192.168.133.137]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UI3cm-0005ys-NU for siprec@ietf.org; Tue, 19 Mar 2013 16:59:12 -0400 From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_0A523204-F894-467A-8A8A-5CD6E91AC181" Message-Id: <30C5144D-93B5-4596-88E4-0A76822B6C07@brianrosen.net> Date: Tue, 19 Mar 2013 16:59:11 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Subject: [siprec] Minutes Posted 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, 19 Mar 2013 20:59:15 -0000 --Apple-Mail=_0A523204-F894-467A-8A8A-5CD6E91AC181 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Minutes from IETF86 have been posted. You can find them at: http://www.ietf.org/proceedings/86/minutes/minutes-86-siprec Thanks to Mary for her usual excellent job. Please send any corrections to the list. Brian --Apple-Mail=_0A523204-F894-467A-8A8A-5CD6E91AC181 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Minutes from IETF86 have been posted.  You can find them at:

Thanks to Mary for her usual excellent job.

Please send any corrections to the list.

Brian
--Apple-Mail=_0A523204-F894-467A-8A8A-5CD6E91AC181-- From internet-drafts@ietf.org Mon Mar 25 11:53:01 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 29BC821F94FC; Mon, 25 Mar 2013 11:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4xkc2x3mnBo; Mon, 25 Mar 2013 11:53:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC33A21F915F; Mon, 25 Mar 2013 11:53:00 -0700 (PDT) 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.43 Message-ID: <20130325185300.14097.64349.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2013 11:53:00 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-callflows-00.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: Mon, 25 Mar 2013 18:53:01 -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 Call Flows Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-callflows-00.txt Pages : 18 Date : 2013-03-25 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows that has snapshot of metadata sent from SRC to SRS, the metadata format for which is described in [I-D.ietf-siprec-metadata] . This is purely an informational document that is written to support the model defined in the metadata draft. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-callflows-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/