From thomas.stach@siemens-enterprise.com Fri Jun 1 04:53:41 2012 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 AA96D21F85C9 for ; Fri, 1 Jun 2012 04:53:41 -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_110=0.6, 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 nBNCutkYKoFH for ; Fri, 1 Jun 2012 04:53:40 -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 4BA0C21F8619 for ; Fri, 1 Jun 2012 04:53:40 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id AAAFA1EB840B for ; Fri, 1 Jun 2012 13:53:38 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Fri, 1 Jun 2012 13:53:38 +0200 From: "Stach, Thomas" To: "siprec@ietf.org" Thread-Topic: Comments on draft-ietf-siprec-protocol-04.txt Thread-Index: Ac0/7TIgzKfBodLOQ5uuQGRK/AIn/Q== Date: Fri, 1 Jun 2012 11:53:37 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.249.89] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Comments on draft-ietf-siprec-protocol-04.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: Fri, 01 Jun 2012 11:53:41 -0000 Leon, I read through the draft. It is already well progressed, but I also have some questions and comments. Regards Thomas =20 4. Overview of operations =20 The architecture document draft-ietf-siprec-architecture-04 describes scena= rios where either the SRC or the SRS can establish the recording session. H= owever, section 4 of the protocol document has the focus on the case where = the SRC initiates the RS and doesn't describe the other option. Other sect= ion have similar issues as detailed further down. =20 5.1. Procedures at the SRC ... In addition, when an SRC sends a REGISTER request to a registrar, the SRC MUST include the '+sip.src' feature tag to indicate the that it is a SRC. =20 This would only be the case if the SRC is located in a SIP UA. A B2BUA woul= d not register. Section 5.1 does not specify behaviour of the SRC when it receives the init= ial INVITE from the SRS. How should the SRC behave when the SRS establishes a "permanent" recording = session, how when the recording session is established mid-call.=20 Is there a difference? Should the user get any hint on its UI when the session is recorded? =20 I saw some text afterwards in section 10, but that is far away. Maybe a hin= t would help? =20 5.2. Procedures at the SRS =20 Section 5.2 does not specify behaviour of the SRS when it receives the init= ial INVITE from the SRC. E.g. is it a failure case when the '+sip.srs' feature tag or the "siprec" o= ption tag is missing in the INVITE from the SRC? Other parts of the draft = talk about SIPREC-unaware UAs, so it's probably not an error? =20 6. SDP Handling =20 Although it sounds trivial, should the draft mention that SRC and SRS MUST = support SDP with multiple m-lines? =20 6.1. Procedures at the SRC =20 Since the SRC does not expect to receive media from the SRS, the SRC typically sets each media stream of the SDP offer to only send media, by qualifying them with the a=3Dsendonly attribute, according to the procedures in [RFC3264]. =20 Consider the the SRC sending an SDP answer with the direction attribute set= to a=3Dsendonly. =20 6.2. Procedures at the SRS =20 The SRS only receives RTP streams from the SRC, the SDP answer normally sets each media stream to receive media, by setting them with the a=3Drecvonly attribute, according to the procedures of [RFC3264]. =20 The text only talks about SDP answers. If the SRS initiates the recording s= ession it would set the direction attribute to a=3Drecvonly in the SDP _off= er_ of the INVITE. Of course, the SRS could send an offerless INVITE, which= would again result in the SRC being the offerer, but this is not detailed = in the current text. =20 ... When the SRS is ready to receive recorded streams, the SRS sends a new SDP offer and sets the media streams with a=3Drecvonly attribute. =20 a=3Drecvonly could also be in the initial offer. =20 9. Persistent Recording =20 The draft talks about using the direction attribute a=3Dinactive in earlier= section. That results in RTCP still being sent for a persistent recording session, w= hen there is nothing to record. Is there anything to say about RTCP usage in this situation in more detail? =20 10.1. Procedures at the record-aware user agent =20 A recording-aware UA SHOULD indicate that it can accept reporting of recording indication provided by the SRC. At the risk of being ingnorant of previous discussions, why is this just a = SHOULD? Who would receive this indication? The B2BUA or the peer SIP UA? Both? =20 A new option tag "record- aware" is introduced to indicate such awareness. The recording-aware UA SHOULD include the "record-aware" option tag in the Supported header when initiating or establishing a CS. Again why just SHOULD? Who would receive this indication? =20 10.1.1. Recording preference =20 A recording-aware UA involved in a CS MAY request the CS to be recorded or not recorded. This indication of recording preference can be sent at session establishment time or during the session. =20 Does the UA request the recording? Or is it the user? Who receives this request? Who sends the "indication of recording preferenc= e"? I'd like to see some explicitly spelled out procedures here. =20 A new SDP attribute "recordpref" is introduced. The SDP attribute appears at the media level or session level and can appear in an SDP offer or answer. The recording indication applies to the specified media stream only. What does the session level attribute mean? Probably, all media streams are= peferred to be recorded. What are the rules when there are session and media level attributes? Does a media level attribute override the session level? Is a preference in an offer achknowledged in the answer? If the attribute was omitted in the offer what does it mean when it is incl= uded in the answer? =20 recordpref-attr =3D "a=3Drecordpref:" pref =20 pref =3D "on" / "off" / "pause" / "nopreference" =20 Do you want to make pref extensible by adding "/ token"? Just in case ... =20 on Request for recording if it has not already been started. If the recording is currently paused, request to resume recording. off Request for no recording. If recording has already been started, then this preference indicates a request to stop recording. ... =20 The section title and ABNF syntax say "preference", but the explanatory tex= t talk about "requests". What is it? A preference, an indication, a request, a ocmmand? If it is a request, is there a response? I haven't followed the SIPREC discussions closely, so apologies if this was= already discussed, but would SDP be the right protocol for sending requests/commands? I would expect pushback from the SDP directorate. If this is just an indication of a preference, I also think it is somewhat = questionable, if SDP is the right place or if it would be better at the SIP= level. As the latter would complicate things, I will sit on the fence. =20 10.2. Procedures at the SRC =20 When a UA has indicated that it is recording-aware through the "record-aware" option tag, the SRC MUST provide recording indications in a new SDP attribute described in the following section. I stumbled a little bit over this since the SRC could be located at the UA = or at a B2BUA. Who would get the recording indication? UA A, UA B, both? =20 In the absence of the "record-aware" option tag, meaning that the UA is not recording-aware, an SRC MUST provide recording indications, where SRC is required to do so based on policies, through other means such as playing a tone inband. =20 =20 =20 10.2.1. Recording indication ... The 'record' SDP attribute appears at the media level or session level in either SDP offer or answer. =20 Similar as above, what are the rules when there are session and media leve= l attributes? =20 attribute /=3D record-attr ; attribute defined in RFC 4566 record-attr =3D "record:" indication indication =3D "on" / "off" / "paused" =20 Do you want to make indication extensible by adding "/ token"? Just in case= ... =20 10.2.2. Recording preference =20 When the SRC receives the a=3Drecordpref SDP in an SDP offer or answer, the SRC chooses to honor such request to record the request based on ^ session? local policy on the SRC. Same issue with preference vs. request as above. When the SRC honors the request, the SRC MUST also update the recording indication to reflect the current state of the recording (on/off/paused). ^ by sending to a=3Drecord:XX attribute? =20 Editorial nits =20 The documents talks regularly about SIP headers (e.g. Require header) when = a SIP header field is meant. Although one could accuse me of nit-picking I = would prefer the term header field (e.g. Require header field) since a SIP message has just a single header, which consists of multiple he= ader fields. =20 Reference to RFC3311 (UPDATE) is missing =20 4.2. Delivering recording metadata ... This request allows both SRC and SRS to restart the states with a new metadata snapshot so that further metadata incremental updates will be based on the latest metadata snapshot. =20 Do you mean "synchronize the states" instead of "restart the states"? =20 7.1.1.2. Transcoding Translator =20 When acting as a transcoding translator, an SRC MAY perform transcoding (e.g., from one codec to another), and this may result in a different rate of packets between what the SRC receives and what the sends. ^ missing word SRC? =20 7.1.2. SRC acting as an RTP Mixer ... Optionally an SRC acting as a mixer can perform transcoding, and can even cope with different codings received from different UAs. ^ Do you mean codecs? =20 7.7. Keepalive =20 It is anticipated that media streams in SIPREC may exist in inactive states for extended periods of times for an of a number of valid reasons. ^ does not parse, missing wor= d? =20 7.8.1. Full Intra Request =20 A Full Intra Request (FIR) Command, when received by the designate media sender, ... ^ designat= ed =20 =20 =20 7.8.2. Picture Loss Indicator =20 ... =20 FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video usable for the users. ^ unusable? =20 7.8.3.1. Renegotiation of SDP bandwidth attribute ... Therefore for SIPREC, implementations are RECOMMENDED to use TMMBR for temporary changes, and renegotiation of bandwidth via SDP offer/answer of more permanent changes. ^ suggest to replace with "of changes wit= h a longer duration." =20 8.2. Procedures at the SRS ... Certain errors, such syntax errors or ... ^ as =20 =20 =20 10.2. Procedures at the SRC =20 In the absence of the "record-aware" option tag, meaning that the UA is not recording-aware, an SRC MUST provide recording indications, where SRC is required to do so based on policies, through other means such as playing a tone inband. =20 Prefer to say In the absence of the "record-aware" option tag, meaning that the UA is not recording-aware, an SRC MUST provide recording indications through other means such as playing a tone inband, if the SRC is required to do so e.g. b= ased on policies. =20 Figure 8: Recording indication example =20 Missing (2) for the 200OK, (6) ACK should read (7) ACK Would the (5) re-INVITE (SDP + a=3Drecord:off) also include an a=3Dinactive direction attribute? =20 =20 =20 =20 =20 mit freundlichen Gr=FC=DFen/Kind Regards Dr.-Ing. Thomas Stach Siemens Enterprise Communications Austria RPDC P SE Dietrichgasse 27 A-1030 Vienna Tel: +43 57008 4377 Fax: +43 570085 4377 mailto:thomas.stach@siemens-enterprise.com From andrew.hutton@siemens-enterprise.com Fri Jun 1 08:51:22 2012 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 12E9511E8088 for ; Fri, 1 Jun 2012 08:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_14=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 F8jU2VhtIGi3 for ; Fri, 1 Jun 2012 08:51:21 -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 CF4A011E8089 for ; Fri, 1 Jun 2012 08:51:20 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id D96E11EB847D; Fri, 1 Jun 2012 17:51:19 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Fri, 1 Jun 2012 17:51:19 +0200 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Updated architecture draft after WGLC comments Thread-Index: AQHNP2XSW3sFybvA3ECdu9s0SGzJuJbktBOQgADpeLA= Date: Fri, 1 Jun 2012 15:51:18 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0169A0@MCHP04MSX.global-ad.net> References: <07465C1D981ABC41A344374066AE1A2C3A7AEB818B@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C160396EE@inba-mail01.sonusnet.com> <4FC7CA21.5020504@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C1603977A@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C1603977A@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.249.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Updated architecture draft after WGLC comments 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, 01 Jun 2012 15:51:22 -0000 Hi, I believe we did agree to leave this out of scope for the moment maybe it i= s a possible future work item. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: 01 June 2012 03:17 > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Updated architecture draft after WGLC comments >=20 > Paul, >=20 > Sorry in case I'm reopening the discussion as the current proposed > mechanism proposes for the usage of proprietary vendor specific id > in the B2BUA+SRC deployment. >=20 > Some of the deployment uses SBC (B2BUA) as SRC, IP PBX > provides vendor specific CS id to SBC as well as to SRS and SRS > request for selective CS to be recorded using SRS initiated > recording mechanism. The point to be noted is that SBC has number > of CS simultaneously and not all the sessions are requested by SRS > to record (Selective recording). Here, SRC configuration (local policy) > will not serve the purpose. >=20 > Of course, this issue is not applicable for SRC initiated sessions > as SRS shall reject selectively when RS INVITE is received. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Paul Kyzivat > >Sent: Friday, June 01, 2012 1:15 AM > >To: siprec@ietf.org > >Subject: Re: [siprec] Updated architecture draft after WGLC comments > > > >I thought the definition of a mechanism for the SRS to indicate what > to > >record to an SRC had been declared out of scope for our current > effort. > > > > Thanks, > > Paul > > > >On 5/31/12 3:16 PM, Ravindran, Parthasarathi wrote: > >> Hi Leon, > >> > >> I'm not very clear about the following text in Sec 3.2.2 > >> > >> "o Identify the session that is to be recorded. The actual mechanism > >> > >> of the identification depends on SRC policy." > >> > >> I agree with you in case of SIP UA acts as SRC, the local policy > will > >> serve the purpose. In case of SIP B2BUA (SBC/IP PBX) acts as SRC, > the > >> local policy may not be sufficient as some indication required to > >> which session has to be indicated by SRS as the number of recording > >> session or number of CS within the single RS will vary drastically > >> from 1 session to 1000+ session at a given time. The issue based on > >> local policy over protocol mechanism is that (B2BUA+) SRC MUST > depend > >> on proprietary session-id from SRS in the actual deployment. > >> > >> I'm writing the following solution to explain the issue in the above > >> text. As per > >> http://www.ietf.org/mail-archive/web/siprec/current/msg03198.html > >> thread, I understand that session-id may not be generic enough > >> solution as it is not applicable to persistent usecase wherein > >> session-id does not exist when RS is established. So, I thought of > >> proposing a solution based on new header namely "recording-join" > >> header which shall have > >> > >> Information about: > >> > >> 1)Communication session-id > >> > >> 2)Participant id > >> > >> 3)Communication session group id > >> > >> 4)Stream id ??? > >> > >> 5)Dialog (Normal Join) > >> > >> The header format shall be"Recording-join: id; > >> type=3DCS/Participant/CSG/stream/dialog". > >> > >> Please let me know your opinion on this approach. > >> > >> Thanks > >> > >> Partha > >> > >> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > >> Behalf Of *Leon Portman > >> *Sent:* Wednesday, May 30, 2012 6:09 PM > >> *To:* siprec@ietf.org > >> *Subject:* [siprec] Updated architecture draft after WGLC comments > >> > >> Hello > >> > >> I just published updated draft after WGLC comments. > >> > >> Main changes: > >> > >> 1.Ram's comments: aligning definitions and terms with requirements > and > >> metadata drafts, figures fixing, references updates > >> > >> 2.Charles comments: > >> > >> a.Fixing B2BUA honoring statements (also was comment from Ram). Next > >text: > >> > >> The B2BUA/SRC is responsible for complying with requests from > >> recording aware UAs or through some configured policies indicating > >> that the communication session should not be recorded. > >> > >> b.Terms fixing and spelling mistakes > >> > >> c.Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5. > >> > >> d.IANA reference to the protocol draft > >> > >> e.Updates in the security section > >> > >> 3.IETF 83 meeting minutes > >> > >> Leon > >> > >> > >> > >> _______________________________________________ > >> 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 Fri Jun 1 13:58:19 2012 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 7E6D821F8A06 for ; Fri, 1 Jun 2012 13:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, 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 ZqXSiUbiSdl0 for ; Fri, 1 Jun 2012 13:58:18 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id 27F1021F8A00 for ; Fri, 1 Jun 2012 13:58:18 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q51KwHNa013649; Fri, 1 Jun 2012 13:58:17 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 13:58:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 13:58:15 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74089C9AD9@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comments on draft-ietf-siprec-protocol-04.txt Thread-Index: Ac0/7TIgzKfBodLOQ5uuQGRK/AIn/QAOtySg References: From: "Henry Lum" To: "Stach, Thomas" , X-OriginalArrivalTime: 01 Jun 2012 20:58:17.0365 (UTC) FILETIME=[44B52C50:01CD4039] Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-04.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: Fri, 01 Jun 2012 20:58:19 -0000 Hi Thomas, thanks for the review. Please see inline. I will defer to Charles on the RTP handling sections. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of > Stach, Thomas > Sent: June-01-12 7:54 AM > To: siprec@ietf.org > Subject: [siprec] Comments on draft-ietf-siprec-protocol-04.txt >=20 > Leon, >=20 > I read through the draft. > It is already well progressed, but I also have some questions and = comments. >=20 > Regards > Thomas >=20 >=20 >=20 > 4. Overview of operations >=20 > The architecture document draft-ietf-siprec-architecture-04 describes > scenarios where either the SRC or the SRS can establish the recording = session. > However, section 4 of the protocol document has the focus on the case = where > the SRC initiates the RS and doesn't describe the other option. Other = section > have similar issues as detailed further down. [Henry] Paragraph 1 of section 5.2 mentions that an SRS can establish a = recording session by sending a new INVITE to SRC. We don't specify what = calls SRS wants to record in this recording session and how this is = done; it's beyond the scope of this draft. >=20 >=20 > 5.1. Procedures at the SRC > ... > In addition, when an SRC sends a REGISTER request > to a registrar, the SRC MUST include the '+sip.src' feature tag to > indicate the that it is a SRC. >=20 > This would only be the case if the SRC is located in a SIP UA. A B2BUA = would > not register. [Henry] Whether a SIP UA registers or not it's entirely up to the UA, I = don't think we need to qualify which type of UA it is. This statement = here requires that whenever a SRC UA needs to register it must include = the feature tag. > Section 5.1 does not specify behaviour of the SRC when it receives the = initial > INVITE from the SRS. [Henry] The SRC recognizes a recording session with the presence of the = siprec option. How the SRC chooses to accept the request is up to the = SRC, and the SRC must also include the +sip.src feature tag in the = contact. Can you clarify what other behaviour you are looking for that = needs to be specified? > How should the SRC behave when the SRS establishes a "permanent" = recording > session, how when the recording session is established mid-call. > Is there a difference? [Henry] We always qualify a SIP session as a recording session with the = use of the siprec option. It must be included in the initial INVITE and = you cannot change that in the mid-call. > Should the user get any hint on its UI when the session is recorded? > I saw some text afterwards in section 10, but that is far away. Maybe = a hint > would help? [Henry] Note that the recording session is different than the user call = (communication session) and the recording session purely deals with = transporting recorded media. The recording indication needs to show up = in the communication session so that is why it has a separate section = 10. >=20 > 5.2. Procedures at the SRS >=20 > Section 5.2 does not specify behaviour of the SRS when it receives the = initial > INVITE from the SRC. [Henry] I have a similar question for the SRC behaviour above. The SRS = identifies a recording session with the option tag and it's up to SRS to = accept the INVITE or not. > E.g. is it a failure case when the '+sip.srs' feature tag or the = "siprec" > option tag is missing in the INVITE from the SRC? Other parts of the = draft > talk about SIPREC-unaware UAs, so it's probably not an error? [Henry] When the siprec option or +sip.src is missing then it means that = the SIP session is not qualified as a recording session. The behaviour = for handling a regular SIP session is up to the SRS. >=20 > 6. SDP Handling >=20 > Although it sounds trivial, should the draft mention that SRC and SRS = MUST > support SDP with multiple m-lines? [Henry] This is already covered in RFC3264 section 5. It would be = confusing to add normative statements on what is already normative. >=20 > 6.1. Procedures at the SRC >=20 > Since the SRC does not expect to receive media from the SRS, the = SRC > typically sets each media stream of the SDP offer to only send = media, > by qualifying them with the a=3Dsendonly attribute, according to = the > procedures in [RFC3264]. >=20 > Consider the the SRC sending an SDP answer with the direction = attribute set to > a=3Dsendonly. [Henry] Okay I will add a statement on this. >=20 > 6.2. Procedures at the SRS >=20 > The SRS only receives RTP streams from the SRC, the SDP answer > normally sets each media stream to receive media, by setting them > with the a=3Drecvonly attribute, according to the procedures of > [RFC3264]. >=20 > The text only talks about SDP answers. If the SRS initiates the = recording > session it would set the direction attribute to a=3Drecvonly in the = SDP _offer_ > of the INVITE. Of course, the SRS could send an offerless INVITE, = which would > again result in the SRC being the offerer, but this is not detailed in = the > current text. [Henry] Actually the SRS should not be adding media streams since the = SRS is purely receiving media. Even when the SRS is initiating the = recording session, the INVITE should not have an offer and let the SRC = decide what the recorded streams are. >=20 > ... When the SRS is ready to receive recorded streams, the > SRS sends a new SDP offer and sets the media streams with = a=3Drecvonly > attribute. >=20 > a=3Drecvonly could also be in the initial offer. >=20 > 9. Persistent Recording >=20 > The draft talks about using the direction attribute a=3Dinactive in = earlier > section. > That results in RTCP still being sent for a persistent recording = session, when > there is nothing to record. > Is there anything to say about RTCP usage in this situation in more = detail? >=20 [Henry] The intention of a persistent recording is that the media stream = is still in sendonly state and not in inactive. In any case, RTCP is = still sent periodically, and I don't think we need to have special = handling for RTCP.=20 >=20 > 10.1. Procedures at the record-aware user agent >=20 >=20 > A recording-aware UA SHOULD indicate that it can accept reporting = of > recording indication provided by the SRC. > At the risk of being ingnorant of previous discussions, why is this = just a > SHOULD? > Who would receive this indication? The B2BUA or the peer SIP UA? Both? [Henry] In this section we are talking about the participants in the = call being recorded (the communication session). If the participant = which can be any kind of user agent supports the extensions described in = this section, then the UA should indicate that it supports them. We = don't mandate that a UA must support these extensions since we need to = interoperate with regular 3261 SIP UA to be recorded. >=20 > A new option tag "record- > aware" is introduced to indicate such awareness. The = recording-aware > UA SHOULD include the "record-aware" option tag in the Supported > header when initiating or establishing a CS. > Again why just SHOULD? > Who would receive this indication? [Henry] Only an SRC would care about the record-aware indication since = the SRC would be performing the recording.=20 >=20 > 10.1.1. Recording preference >=20 >=20 > A recording-aware UA involved in a CS MAY request the CS to be > recorded or not recorded. This indication of recording preference > can be sent at session establishment time or during the session. >=20 > Does the UA request the recording? Or is it the user? [Henry] This can be a human user or just the UA requesting the call to = be recorded; the indication is sent by the UA. > Who receives this request? Who sends the "indication of recording = preference"? > I'd like to see some explicitly spelled out procedures here. [Henry] Perhaps I can provide an example here to illustrate how this = works, but the procedures of what a recording-aware UA are already = provided in section 10.1. >=20 > A new SDP attribute "recordpref" is introduced. The SDP attribute > appears at the media level or session level and can appear in an = SDP > offer or answer. The recording indication applies to the specified > media stream only. > What does the session level attribute mean? Probably, all media = streams are > peferred to be recorded. [Henry] the session level mean that all media streams have the attribute = applied. You can also set this at the media stream level to indicate = which media stream you wish to be (or not to be recorded). For example, = you only wish your audio to be recorded but not your video stream, then = you can set the attribute as a=3Drecordpref:on in the audio media stream = and a=3Drecordpref:off in the video media stream. > What are the rules when there are session and media level attributes? > Does a media level attribute override the session level? > Is a preference in an offer achknowledged in the answer? [Henry] An SRC is not required to honor such preference due to its own = policies, so we have not modeled this attribute with any negotiation and = this merely indicate what the user preference is for this media stream = or session. The user will only know whether it is recording or not = through the recording indication, and the SRC is required to provide the = indication via the a=3Drecord attribute.=20 > If the attribute was omitted in the offer what does it mean when it is > included in the answer? [Henry] We have discussion about this before and the conclusion is that = the omission of this attribute is equivalent to = a=3Drecordpref:nopreference. >=20 > recordpref-attr =3D "a=3Drecordpref:" pref >=20 > pref =3D "on" / "off" / "pause" / "nopreference" >=20 > Do you want to make pref extensible by adding "/ token"? Just in case = ... [Henry]=20 >=20 > on Request for recording if it has not already been started. If = the > recording is currently paused, request to resume recording. > off Request for no recording. If recording has already been > started, then this preference indicates a request to stop > recording. > ... >=20 > The section title and ABNF syntax say "preference", but the = explanatory text > talk about "requests". > What is it? A preference, an indication, a request, a ocmmand? > If it is a request, is there a response? [Henry] "request" is indeed a bad choice of wording here. As I mentioned = above, this is not a request/response parameter and I will correct the = wording here.=20 Revised text: on Indicate that the UA wishes to be recorded or resume recording = if the recording is paused. off Indicate that the UA wishes not to be recorded or stop the = recording if a recording is already in progress. pause Indicate that the UA wishes the recording to be paused if the = recording is in progress. > I haven't followed the SIPREC discussions closely, so apologies if = this was > already discussed, but > would SDP be the right protocol for sending requests/commands? > I would expect pushback from the SDP directorate. > If this is just an indication of a preference, I also think it is = somewhat > questionable, if SDP is the right place or if it would be better at = the SIP > level. As the latter would complicate things, I will sit on the fence. [Henry] We had discussions on this before and the reason we use SDP = attribute is that we want media stream level indication and preference. >=20 > 10.2. Procedures at the SRC >=20 > When a UA has indicated that it is recording-aware through the > "record-aware" option tag, the SRC MUST provide recording = indications > in a new SDP attribute described in the following section. > I stumbled a little bit over this since the SRC could be located at = the UA or > at a B2BUA. > Who would get the recording indication? UA A, UA B, both? [Henry] All participants in the communication session must receive the = record-aware indication.=20 >=20 > In the > absence of the "record-aware" option tag, meaning that the UA is = not > recording-aware, an SRC MUST provide recording indications, where = SRC > is required to do so based on policies, through other means such as > playing a tone inband. >=20 >=20 >=20 >=20 > 10.2.1. Recording indication > ... > The 'record' SDP attribute appears at the media level or session > level in either SDP offer or answer. >=20 > Similar as above, what are the rules when there are session and media = level > attributes? [Henry] The SRC can choose to use session level attribute if all the = media streams share the same indication, otherwise the SRC needs to use = the media level attributes. >=20 > attribute /=3D record-attr > ; attribute defined in RFC 4566 > record-attr =3D "record:" indication > indication =3D "on" / "off" / "paused" >=20 > Do you want to make indication extensible by adding "/ token"? Just in = case > ... [Henry] Do we really need a general token? I don't see another = recording state that the SRC can be in. >=20 > 10.2.2. Recording preference >=20 >=20 > When the SRC receives the a=3Drecordpref SDP in an SDP offer or = answer, > the SRC chooses to honor such request to record the request based = on > ^ session? > local policy on the SRC. > Same issue with preference vs. request as above. > When the SRC honors the request, the SRC > MUST also update the recording indication to reflect the current > state of the recording (on/off/paused). > ^ by sending to a=3Drecord:XX attribute? [Henry] The wording should be preference rather than request. Thanks for = catching that and I will reword as follows: When the SRC receives the a=3Drecordpref SDP in an SDP offer or = answer, the SRC chooses to honor such the recording preference based on local policy on the SRC. Whatever actions the SRC chooses, the SRC = MUST also=20 update the recording indication to reflect the current state of the = recording (on/off/paused). >=20 >=20 > Editorial nits >=20 > The documents talks regularly about SIP headers (e.g. Require header) = when a > SIP header field is meant. Although one could accuse me of nit-picking = I would > prefer the term header field (e.g. Require header field) > since a SIP message has just a single header, which consists of = multiple > header fields. >=20 > Reference to RFC3311 (UPDATE) is missing [Henry] Okay I will fix them. >=20 >=20 > 4.2. Delivering recording metadata > ... > This request allows both SRC and SRS to > restart the states with a new metadata snapshot so that further > metadata incremental updates will be based on the latest metadata > snapshot. >=20 > Do you mean "synchronize the states" instead of "restart the states"? [Henry] Okay I can change the word here. =20 >=20 > 7.1.1.2. Transcoding Translator >=20 >=20 > When acting as a transcoding translator, an SRC MAY perform > transcoding (e.g., from one codec to another), and this may result = in > a different rate of packets between what the SRC receives and what > the sends. > ^ missing word SRC? >=20 >=20 > 7.1.2. SRC acting as an RTP Mixer > ... > Optionally an SRC acting as a mixer can perform transcoding, and = can > even cope with different codings received from different UAs. > ^ Do you mean codecs? >=20 >=20 > 7.7. Keepalive >=20 >=20 > It is anticipated that media streams in SIPREC may exist in = inactive > states for extended periods of times for an of a number of valid > reasons. ^ does not parse, = missing word? >=20 >=20 > 7.8.1. Full Intra Request >=20 > A Full Intra Request (FIR) Command, when received by the designate > media sender, ... ^ = designated >=20 >=20 >=20 > 7.8.2. Picture Loss Indicator >=20 > ... >=20 > FIR SHOULD be used only in situations where not > sending a decoder refresh point would render the video usable for = the > users. ^ unusable? >=20 > 7.8.3.1. Renegotiation of SDP bandwidth attribute > ... > Therefore for SIPREC, implementations are > RECOMMENDED to use TMMBR for temporary changes, and renegotiation = of > bandwidth via SDP offer/answer of more permanent changes. > ^ suggest to replace with "of = changes with a > longer duration." >=20 > 8.2. Procedures at the SRS > ... > Certain errors, such syntax errors or ... > ^ as >=20 >=20 >=20 > 10.2. Procedures at the SRC >=20 >=20 > In the > absence of the "record-aware" option tag, meaning that the UA is = not > recording-aware, an SRC MUST provide recording indications, where = SRC > is required to do so based on policies, through other means such as > playing a tone inband. >=20 > Prefer to say > In the absence of the "record-aware" option tag, meaning that the UA = is not > recording-aware, an SRC MUST provide recording indications through = other > means such as playing a tone inband, if the SRC is required to do so = e.g. > based on policies. [Henry] Okay that sounds better. >=20 >=20 > Figure 8: Recording indication example >=20 > Missing (2) for the 200OK, (6) ACK should read (7) ACK [Henry] Oh right, thanks. > Would the > (5) re-INVITE (SDP + a=3Drecord:off) > also include an a=3Dinactive direction attribute? [Henry] Stopping the recording does not mean the media stream in the = communication is paused though. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > mit freundlichen Gr=FC=DFen/Kind Regards >=20 > Dr.-Ing. Thomas Stach > Siemens Enterprise Communications Austria > RPDC P SE > Dietrichgasse 27 > A-1030 Vienna > Tel: +43 57008 4377 > Fax: +43 570085 4377 > mailto:thomas.stach@siemens-enterprise.com >=20 >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Fri Jun 1 18:46:38 2012 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 BA70721F876C for ; Fri, 1 Jun 2012 18:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.828 X-Spam-Level: X-Spam-Status: No, score=-5.828 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] 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 C8wCKasQzyCX for ; Fri, 1 Jun 2012 18:46:38 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7C68D21F876D for ; Fri, 1 Jun 2012 18:46:37 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT8lwfKPgEFdjgnNHmDMuT3klflogCF9D@postini.com; Fri, 01 Jun 2012 18:46:37 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 1 Jun 2012 21:47:03 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Sat, 2 Jun 2012 07:16:31 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Updated architecture draft after WGLC comments Thread-Index: AQHNP2XSW3sFybvA3ECdu9s0SGzJuJbktBOQgADpeLCAAJr60A== Date: Sat, 2 Jun 2012 01:46:29 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16039C57@inba-mail01.sonusnet.com> References: <07465C1D981ABC41A344374066AE1A2C3A7AEB818B@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C160396EE@inba-mail01.sonusnet.com> <4FC7CA21.5020504@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C1603977A@inba-mail01.sonusnet.com> <9F33F40F6F2CD847824537F3C4E37DDF0169A0@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0169A0@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Updated architecture draft after WGLC comments 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, 02 Jun 2012 01:46:38 -0000 Hi Andy, I agree with you that The initial focus of SIPREC was based on SRC-initiate= d callflow and SRS-initiated callflow is added based on SIP UA+SRC. In the = current mechanism SRS-initiated callflow is followed for B2BUA+SRC, It will= be become three stage migration for the products which supports proprietar= y SRS initiated callflow with more interop issue in the deployment as follo= ws: 1) Proprietary SRS initiated callflow with proprietary correlation-id 2) SIPREC SRS initiated callflow with proprietary correlation-id 3) SIPREC SRS initiated callflow with standard correlation-id I'm fine in case SRS initiated callflow is completely outside the scope of = SIPRECv1.0 as it is not fully analyzed. But unfortunately we are making the= middle stance wherein defining the behavior based on SRC local policy (con= figuration) and it works only for SIP UA+SRC solutions and not for B2BUA+SR= C.=20 In case there is strong support for SRS initiated callflow within SIPREC, l= et us work for SRS initiated protocol mechanism as a separate work item and= the architecture document will not propose the exact mechanism (like local= policy) but only mention the support for SIPREC SRS-initiated callflow. Pl= ease let me know your opinion on this. Thanks Partha >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Friday, June 01, 2012 9:21 PM >To: Ravindran, Parthasarathi; Paul Kyzivat; siprec@ietf.org >Subject: RE: [siprec] Updated architecture draft after WGLC comments > >Hi, > >I believe we did agree to leave this out of scope for the moment maybe >it is a possible future work item. > >Regards >Andy (SIPREC Co-Chair). > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: 01 June 2012 03:17 >> To: Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] Updated architecture draft after WGLC comments >> >> Paul, >> >> Sorry in case I'm reopening the discussion as the current proposed >> mechanism proposes for the usage of proprietary vendor specific id in >> the B2BUA+SRC deployment. >> >> Some of the deployment uses SBC (B2BUA) as SRC, IP PBX provides vendor >> specific CS id to SBC as well as to SRS and SRS request for selective >> CS to be recorded using SRS initiated recording mechanism. The point >> to be noted is that SBC has number of CS simultaneously and not all >> the sessions are requested by SRS to record (Selective recording). >> Here, SRC configuration (local policy) will not serve the purpose. >> >> Of course, this issue is not applicable for SRC initiated sessions as >> SRS shall reject selectively when RS INVITE is received. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >> >Of Paul Kyzivat >> >Sent: Friday, June 01, 2012 1:15 AM >> >To: siprec@ietf.org >> >Subject: Re: [siprec] Updated architecture draft after WGLC comments >> > >> >I thought the definition of a mechanism for the SRS to indicate what >> to >> >record to an SRC had been declared out of scope for our current >> effort. >> > >> > Thanks, >> > Paul >> > >> >On 5/31/12 3:16 PM, Ravindran, Parthasarathi wrote: >> >> Hi Leon, >> >> >> >> I'm not very clear about the following text in Sec 3.2.2 >> >> >> >> "o Identify the session that is to be recorded. The actual >> >> mechanism >> >> >> >> of the identification depends on SRC policy." >> >> >> >> I agree with you in case of SIP UA acts as SRC, the local policy >> will >> >> serve the purpose. In case of SIP B2BUA (SBC/IP PBX) acts as SRC, >> the >> >> local policy may not be sufficient as some indication required to >> >> which session has to be indicated by SRS as the number of recording >> >> session or number of CS within the single RS will vary drastically >> >> from 1 session to 1000+ session at a given time. The issue based on >> >> local policy over protocol mechanism is that (B2BUA+) SRC MUST >> depend >> >> on proprietary session-id from SRS in the actual deployment. >> >> >> >> I'm writing the following solution to explain the issue in the >> >> above text. As per >> >> http://www.ietf.org/mail-archive/web/siprec/current/msg03198.html >> >> thread, I understand that session-id may not be generic enough >> >> solution as it is not applicable to persistent usecase wherein >> >> session-id does not exist when RS is established. So, I thought of >> >> proposing a solution based on new header namely "recording-join" >> >> header which shall have >> >> >> >> Information about: >> >> >> >> 1)Communication session-id >> >> >> >> 2)Participant id >> >> >> >> 3)Communication session group id >> >> >> >> 4)Stream id ??? >> >> >> >> 5)Dialog (Normal Join) >> >> >> >> The header format shall be"Recording-join: id; >> >> type=3DCS/Participant/CSG/stream/dialog". >> >> >> >> Please let me know your opinion on this approach. >> >> >> >> Thanks >> >> >> >> Partha >> >> >> >> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On >> >> Behalf Of *Leon Portman >> >> *Sent:* Wednesday, May 30, 2012 6:09 PM >> >> *To:* siprec@ietf.org >> >> *Subject:* [siprec] Updated architecture draft after WGLC comments >> >> >> >> Hello >> >> >> >> I just published updated draft after WGLC comments. >> >> >> >> Main changes: >> >> >> >> 1.Ram's comments: aligning definitions and terms with requirements >> and >> >> metadata drafts, figures fixing, references updates >> >> >> >> 2.Charles comments: >> >> >> >> a.Fixing B2BUA honoring statements (also was comment from Ram). >> >> Next >> >text: >> >> >> >> The B2BUA/SRC is responsible for complying with requests from >> >> recording aware UAs or through some configured policies indicating >> >> that the communication session should not be recorded. >> >> >> >> b.Terms fixing and spelling mistakes >> >> >> >> c.Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5. >> >> >> >> d.IANA reference to the protocol draft >> >> >> >> e.Updates in the security section >> >> >> >> 3.IETF 83 meeting minutes >> >> >> >> Leon >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 thomas.stach@siemens-enterprise.com Mon Jun 4 06:36:07 2012 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 3073221F87AD for ; Mon, 4 Jun 2012 06:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, 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 IliXigKDP-lU for ; Mon, 4 Jun 2012 06:36:05 -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 C17A421F85EA for ; Mon, 4 Jun 2012 06:36:04 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 56A9F1EB8418; Mon, 4 Jun 2012 15:36:03 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Mon, 4 Jun 2012 15:36:03 +0200 From: "Stach, Thomas" To: Henry Lum , "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-protocol-04.txt Thread-Index: Ac0/7TIgzKfBodLOQ5uuQGRK/AIn/QAOtySgAIcLzSA= Date: Mon, 4 Jun 2012 13:36:02 +0000 Message-ID: References: <059AF07365DC474393A19A3AF187DF74089C9AD9@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74089C9AD9@NAHALD.us.int.genesyslab.com> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.3.25] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-04.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, 04 Jun 2012 13:36:07 -0000 Henry, thanks for the response.=20 more inline > -----Urspr=FCngliche Nachricht----- > Von: Henry Lum [mailto:Henry.Lum@genesyslab.com]=20 > Gesendet: Freitag, 01. Juni 2012 22:58 > An: Stach, Thomas; siprec@ietf.org > Betreff: RE: [siprec] Comments on draft-ietf-siprec-protocol-04.txt >=20 > Hi Thomas, thanks for the review. Please see inline. >=20 > I will defer to Charles on the RTP handling sections. >=20 > Henry >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of > > Stach, Thomas > > Sent: June-01-12 7:54 AM > > To: siprec@ietf.org > > Subject: [siprec] Comments on draft-ietf-siprec-protocol-04.txt > >=20 > > Leon, > >=20 > > I read through the draft. > > It is already well progressed, but I also have some=20 > questions and comments. > >=20 > > Regards > > Thomas > >=20 > >=20 > >=20 > > 4. Overview of operations > >=20 > > The architecture document draft-ietf-siprec-architecture-04=20 > describes > > scenarios where either the SRC or the SRS can establish the=20 > recording session. > > However, section 4 of the protocol document has the focus=20 > on the case where > > the SRC initiates the RS and doesn't describe the other=20 > option. Other section > > have similar issues as detailed further down. >=20 > [Henry] Paragraph 1 of section 5.2 mentions that an SRS can=20 > establish a recording session by sending a new INVITE to SRC. Section 5.2 is fine in that respect, my point was that this is not mentione= d in the overview section 4. > We don't specify what calls SRS wants to record in this=20 > recording session and how this is done; it's beyond the scope=20 > of this draft. >=20 > >=20 > >=20 > > 5.1. Procedures at the SRC > > ... > > In addition, when an SRC sends a REGISTER request > > to a registrar, the SRC MUST include the '+sip.src'=20 > feature tag to > > indicate the that it is a SRC. > >=20 > > This would only be the case if the SRC is located in a SIP=20 > UA. A B2BUA would > > not register. >=20 > [Henry] Whether a SIP UA registers or not it's entirely up to=20 > the UA, I don't think we need to qualify which type of UA it=20 > is. This statement here requires that whenever a SRC UA needs=20 > to register it must include the feature tag. OK >=20 > > Section 5.1 does not specify behaviour of the SRC when it=20 > receives the initial > > INVITE from the SRS. >=20 > [Henry] The SRC recognizes a recording session with the=20 > presence of the siprec option. How the SRC chooses to accept=20 > the request is up to the SRC, and the SRC must also include=20 > the +sip.src feature tag in the contact. Can you clarify what=20 > other behaviour you are looking for that needs to be specified? My point is that section 5.1 describes just the sender's side, i.e. how the= SRC builds the INVITE and includes the option/feature tag. I'm missing the counterpart, i.e. what the receiver of such an INVITE (SRS)= should do with it.=20 Such text could include e.g :=20 "On receipt of an INVITE the SRS SHALL check for presence of an 'siprec' op= tion tag and a '+sip.src' feature tag.=20 If present the SRS should start recording of the media streams based on the= SDP in the body of the INVITE.=20 Detailed SDP handling is described in section 6.=20 If metadata is present, the SRS SHALL act as specified in section 8. ..." >=20 > > How should the SRC behave when the SRS establishes a=20 > "permanent" recording > > session, how when the recording session is established mid-call. > > Is there a difference? >=20 > [Henry] We always qualify a SIP session as a recording=20 > session with the use of the siprec option. It must be=20 > included in the initial INVITE and you cannot change that in=20 > the mid-call. I should have asked more clearly. I meant a CS is already going on. At some= time during that CS a "new" adhoc recording session is started. Is there a difference compared to the case where a "permanent" recording se= ssion is already in place?=20 This is probably not the case with respect to the option/feature tags and t= his could be stated in the text. However (as an example) I could imagine different values of the direction a= ttributes "inactive" vs. "sendonly" in the initial INVITE of the recording = session. Now, section 6.1 just mentions usage of "sendonly". A creative dev= eloper might now think that only "sendonly" is allowed in the initial INVIT= E and rejects if the SDP includes "inactive". But that would make perfect s= ense as initial value of "permanent" recording session and should clearly b= e allowed. I would like options like this being explicitly stated in the text in order= to avoid interoperability problems in future implementations. >=20 > > Should the user get any hint on its UI when the session is recorded? > > I saw some text afterwards in section 10, but that is far=20 > away. Maybe a hint > > would help? >=20 > [Henry] Note that the recording session is different than the=20 > user call (communication session) and the recording session=20 > purely deals with transporting recorded media. The recording=20 > indication needs to show up in the communication session so=20 > that is why it has a separate section 10. Yes, I detected that when I later read section 10, but I stumbled over the = issue. As section 4 already gives an overview, you might also want to mention this= indication already there. This make me aware of something that I currently miss and which can probabl= y also be enhanced in section 4. Currently, there is a lot of detailed information spread over different par= ts.=20 I think this fine, but I miss some glue that puts these parts together. Section 4 could probably mention that section 5 describes the INVITE and it= s usage of option/feature tags, Section 6 describes SDP, Section 7 describes RTP issues, Section 8 describe= s metadata, section 10 describes ... > >=20 > > 5.2. Procedures at the SRS > >=20 > > Section 5.2 does not specify behaviour of the SRS when it=20 > receives the initial > > INVITE from the SRC. >=20 > [Henry] I have a similar question for the SRC behaviour=20 > above. The SRS identifies a recording session with the option=20 > tag and it's up to SRS to accept the INVITE or not. Yes, my issue is also similar like for 5.1. 5.2 describes just the sender's= side, I miss what the receiver of the INVITE should do. >=20 > > E.g. is it a failure case when the '+sip.srs' feature tag=20 > or the "siprec" > > option tag is missing in the INVITE from the SRC? Other=20 > parts of the draft > > talk about SIPREC-unaware UAs, so it's probably not an error? >=20 > [Henry] When the siprec option or +sip.src is missing then it=20 > means that the SIP session is not qualified as a recording=20 > session. The behaviour for handling a regular SIP session is=20 > up to the SRS. I think that should be stated in the text. >=20 > >=20 > > 6. SDP Handling > >=20 > > Although it sounds trivial, should the draft mention that=20 > SRC and SRS MUST > > support SDP with multiple m-lines? >=20 > [Henry] This is already covered in RFC3264 section 5. It=20 > would be confusing to add normative statements on what is=20 > already normative. OK, agreed. The reason behind my comments is that we met a lot of implementations that = showed a variety of unexpected behavior when they received multiple m-line.= Maybe we will be better of with recorders. >=20 > >=20 > > 6.1. Procedures at the SRC > >=20 > > Since the SRC does not expect to receive media from the=20 > SRS, the SRC > > typically sets each media stream of the SDP offer to=20 > only send media, > > by qualifying them with the a=3Dsendonly attribute,=20 > according to the > > procedures in [RFC3264]. > >=20 > > Consider the the SRC sending an SDP answer with the=20 > direction attribute set to > > a=3Dsendonly. >=20 > [Henry] Okay I will add a statement on this. >=20 > >=20 > > 6.2. Procedures at the SRS > >=20 > > The SRS only receives RTP streams from the SRC, the SDP answer > > normally sets each media stream to receive media, by setting them > > with the a=3Drecvonly attribute, according to the procedures of > > [RFC3264]. > >=20 > > The text only talks about SDP answers. If the SRS initiates=20 > the recording > > session it would set the direction attribute to a=3Drecvonly=20 > in the SDP _offer_ > > of the INVITE. Of course, the SRS could send an offerless=20 > INVITE, which would > > again result in the SRC being the offerer, but this is not=20 > detailed in the > > current text. >=20 > [Henry] Actually the SRS should not be adding media streams=20 > since the SRS is purely receiving media. Even when the SRS is=20 > initiating the recording session, the INVITE should not have=20 > an offer and let the SRC decide what the recorded streams are. Ok, that works for me, but this is not yet stated in the text. If everybody agrees with that view you should add something like:=20 "When the SRS starts a recording session it MUST initial the INVITE without= an SDP offer." ... and a similar statment on what the SRC does when it receives that INVIT= E. >=20 > >=20 > > ... When the SRS is ready to receive recorded streams, the > > SRS sends a new SDP offer and sets the media streams=20 > with a=3Drecvonly > > attribute. > >=20 > > a=3Drecvonly could also be in the initial offer. > >=20 > > 9. Persistent Recording > >=20 > > The draft talks about using the direction attribute=20 > a=3Dinactive in earlier > > section. > > That results in RTCP still being sent for a persistent=20 > recording session, when > > there is nothing to record. > > Is there anything to say about RTCP usage in this situation=20 > in more detail? > >=20 >=20 > [Henry] The intention of a persistent recording is that the=20 > media stream is still in sendonly state and not in inactive.=20 As per my response above I believe that the persistent recording would use = "inactive" (at least in case when there is nothing to record yet at the tim= e of establishment) > In any case, RTCP is still sent periodically, and I don't=20 > think we need to have special handling for RTCP.=20 >=20 > >=20 > > 10.1. Procedures at the record-aware user agent > >=20 > >=20 > > A recording-aware UA SHOULD indicate that it can accept=20 > reporting of > > recording indication provided by the SRC. > > At the risk of being ingnorant of previous discussions, why=20 > is this just a > > SHOULD? > > Who would receive this indication? The B2BUA or the peer=20 > SIP UA? Both? >=20 > [Henry] In this section we are talking about the participants=20 > in the call being recorded (the communication session). If=20 > the participant which can be any kind of user agent supports=20 > the extensions described in this section, then the UA should=20 > indicate that it supports them. We don't mandate that a UA=20 > must support these extensions since we need to interoperate=20 > with regular 3261 SIP UA to be recorded. Understood, but a regular 3261 UA would just ignore the option tag in the S= upported header field. Though not a big deal, I'm still wondering about the SHOULD. Is it to make = life easier for automatons? >=20 > >=20 > > A new option tag "record- > > aware" is introduced to indicate such awareness. The=20 > recording-aware > > UA SHOULD include the "record-aware" option tag in the Supported > > header when initiating or establishing a CS. > > Again why just SHOULD? > > Who would receive this indication? >=20 > [Henry] Only an SRC would care about the record-aware=20 > indication since the SRC would be performing the recording.=20 OK, but you don't specify into which message the record-aware UA should put= the option-tag. Should it be in the INVITE request, 200OK?=20 Does it need to be repeated in re-INVITE and its 200OK, UPDATE request and = its 200OK? > >=20 > > 10.1.1. Recording preference > >=20 > >=20 > > A recording-aware UA involved in a CS MAY request the CS to be > > recorded or not recorded. This indication of recording=20 > preference > > can be sent at session establishment time or during the session. > >=20 > > Does the UA request the recording? Or is it the user? >=20 > [Henry] This can be a human user or just the UA requesting=20 > the call to be recorded; the indication is sent by the UA. Ok, please state this in the text. ... and similar to above, MUST the indication be repeated during O/A cycle = during the call? Omission during a later O/A cycle could either mean the preference did not = change or that fallback to the the default occurs. I think that needs to be specified. >=20 > > Who receives this request? Who sends the "indication of=20 > recording preference"? > > I'd like to see some explicitly spelled out procedures here. >=20 > [Henry] Perhaps I can provide an example here to illustrate=20 > how this works, but the procedures of what a recording-aware=20 > UA are already provided in section 10.1. >=20 > >=20 > > A new SDP attribute "recordpref" is introduced. The SDP=20 > attribute > > appears at the media level or session level and can=20 > appear in an SDP > > offer or answer. The recording indication applies to=20 > the specified > > media stream only. > > What does the session level attribute mean? Probably, all=20 > media streams are > > peferred to be recorded. >=20 > [Henry] the session level mean that all media streams have=20 > the attribute applied. You can also set this at the media=20 > stream level to indicate which media stream you wish to be=20 > (or not to be recorded). For example, you only wish your=20 > audio to be recorded but not your video stream, then you can=20 > set the attribute as a=3Drecordpref:on in the audio media=20 > stream and a=3Drecordpref:off in the video media stream. OK, understood. But SDP attributes that can be used at session level and me= dia level need to have a rule that specifies what it means when the attribu= tes are used simultaneously at session and media-level.=20 Usually the media-level attribute overides the session-level value, such th= at=20 a=3Drecordpref:on=20 m=3Daudio 12240 RTP/AVP 0 m=3Daudio 12242 RTP/AVP 0 m=3Dvideo 12244 RTP/AVPF 98 a=3Drecordpref:off means the same as your example (all audio is preferred to be recorded, but = video is not).=20 >=20 > > What are the rules when there are session and media level=20 > attributes? > > Does a media level attribute override the session level? > > Is a preference in an offer achknowledged in the answer? >=20 > [Henry] An SRC is not required to honor such preference due=20 > to its own policies, so we have not modeled this attribute=20 > with any negotiation and this merely indicate what the user=20 > preference is for this media stream or session. The user will=20 > only know whether it is recording or not through the=20 > recording indication, and the SRC is required to provide the=20 > indication via the a=3Drecord attribute.=20 Maybe you could include this in the text. >=20 > > If the attribute was omitted in the offer what does it mean=20 > when it is > > included in the answer? >=20 > [Henry] We have discussion about this before and the=20 > conclusion is that the omission of this attribute is=20 > equivalent to a=3Drecordpref:nopreference. >=20 > >=20 > > recordpref-attr =3D "a=3Drecordpref:" pref > >=20 > > pref =3D "on" / "off" / "pause" / "nopreference" > >=20 > > Do you want to make pref extensible by adding "/ token"?=20 > Just in case ... >=20 > [Henry]=20 > >=20 > > on Request for recording if it has not already been=20 > started. If the > > recording is currently paused, request to resume recording. > > off Request for no recording. If recording has already been > > started, then this preference indicates a request to stop > > recording. > > ... > >=20 > > The section title and ABNF syntax say "preference", but the=20 > explanatory text > > talk about "requests". > > What is it? A preference, an indication, a request, a ocmmand? > > If it is a request, is there a response? >=20 > [Henry] "request" is indeed a bad choice of wording here. As=20 > I mentioned above, this is not a request/response parameter=20 > and I will correct the wording here.=20 Good, that was my major concern with the SDP attributes. >=20 > Revised text: >=20 > on Indicate that the UA wishes to be recorded or resume=20 > recording if the recording is paused. > off Indicate that the UA wishes not to be recorded or=20 > stop the recording if a recording is already in progress. > pause Indicate that the UA wishes the recording to be=20 > paused if the recording is in progress. >=20 > > I haven't followed the SIPREC discussions closely, so=20 > apologies if this was > > already discussed, but > > would SDP be the right protocol for sending requests/commands? > > I would expect pushback from the SDP directorate. > > If this is just an indication of a preference, I also think=20 > it is somewhat > > questionable, if SDP is the right place or if it would be=20 > better at the SIP > > level. As the latter would complicate things, I will sit on=20 > the fence. >=20 > [Henry] We had discussions on this before and the reason we=20 > use SDP attribute is that we want media stream level=20 > indication and preference. Works for me >=20 > >=20 > > 10.2. Procedures at the SRC > >=20 > > When a UA has indicated that it is recording-aware through the > > "record-aware" option tag, the SRC MUST provide=20 > recording indications > > in a new SDP attribute described in the following section. > > I stumbled a little bit over this since the SRC could be=20 > located at the UA or > > at a B2BUA. > > Who would get the recording indication? UA A, UA B, both? >=20 > [Henry] All participants in the communication session must=20 > receive the record-aware indication.=20 Please, state this in the text. >=20 > >=20 > > In the > > absence of the "record-aware" option tag, meaning that=20 > the UA is not > > recording-aware, an SRC MUST provide recording=20 > indications, where SRC > > is required to do so based on policies, through other=20 > means such as > > playing a tone inband. > >=20 > >=20 > >=20 > >=20 > > 10.2.1. Recording indication > > ... > > The 'record' SDP attribute appears at the media level or session > > level in either SDP offer or answer. > >=20 > > Similar as above, what are the rules when there are=20 > session and media level > > attributes? >=20 > [Henry] The SRC can choose to use session level attribute if=20 > all the media streams share the same indication, otherwise=20 > the SRC needs to use the media level attributes. This would be a differnt rule than what is usually done.=20 Whatever you want to specify needs to be explictly stated. >=20 > >=20 > > attribute /=3D record-attr > > ; attribute defined in RFC 4566 > > record-attr =3D "record:" indication > > indication =3D "on" / "off" / "paused" > >=20 > > Do you want to make indication extensible by adding "/=20 > token"? Just in case > > ... >=20 > [Henry] Do we really need a general token? I don't see=20 > another recording state that the SRC can be in. I was just asking and don't have apreference. Sometimes things come up late= r that nobody could imagine at earlier times. >=20 > >=20 > > 10.2.2. Recording preference > >=20 > >=20 > > When the SRC receives the a=3Drecordpref SDP in an SDP=20 > offer or answer, > > the SRC chooses to honor such request to record the=20 > request based on > > ^ session? >=20 > > local policy on the SRC. > > Same issue with preference vs. request as above. > > When the SRC honors the request, the SRC > > MUST also update the recording indication to reflect the current > > state of the recording (on/off/paused). > > ^ by sending to a=3Drecord:XX attribute? >=20 > [Henry] The wording should be preference rather than request.=20 > Thanks for catching that and I will reword as follows: >=20 > When the SRC receives the a=3Drecordpref SDP in an SDP offer=20 > or answer, > the SRC chooses to honor such the recording preference based on > local policy on the SRC. Whatever actions the SRC=20 > chooses, the SRC MUST also=20 > update the recording indication to reflect the current=20 > state of the recording (on/off/paused). OK, could you just explictly mention the "a=3Drecord" attribute? Regards Thomas >=20 > >=20 > >=20 > > Editorial nits > >=20 > > The documents talks regularly about SIP headers (e.g.=20 > Require header) when a > > SIP header field is meant. Although one could accuse me of=20 > nit-picking I would > > prefer the term header field (e.g. Require header field) > > since a SIP message has just a single header, which=20 > consists of multiple > > header fields. > >=20 > > Reference to RFC3311 (UPDATE) is missing >=20 > [Henry] Okay I will fix them. > >=20 > >=20 > > 4.2. Delivering recording metadata > > ... > > This request allows both SRC and SRS to > > restart the states with a new metadata snapshot so that further > > metadata incremental updates will be based on the latest metadata > > snapshot. > >=20 > > Do you mean "synchronize the states" instead of "restart=20 > the states"? >=20 > [Henry] Okay I can change the word here. > =20 > >=20 > > 7.1.1.2. Transcoding Translator > >=20 > >=20 > > When acting as a transcoding translator, an SRC MAY perform > > transcoding (e.g., from one codec to another), and this=20 > may result in > > a different rate of packets between what the SRC=20 > receives and what > > the sends. > > ^ missing word SRC? > >=20 > >=20 > > 7.1.2. SRC acting as an RTP Mixer > > ... > > Optionally an SRC acting as a mixer can perform=20 > transcoding, and can > > even cope with different codings received from different UAs. > > ^ Do you mean codecs? > >=20 > >=20 > > 7.7. Keepalive > >=20 > >=20 > > It is anticipated that media streams in SIPREC may exist=20 > in inactive > > states for extended periods of times for an of a number of valid > > reasons. ^ does not=20 > parse, missing word? > >=20 > >=20 > > 7.8.1. Full Intra Request > >=20 > > A Full Intra Request (FIR) Command, when received by the=20 > designate > > media sender, ... =20 > ^ designated > >=20 > >=20 > >=20 > > 7.8.2. Picture Loss Indicator > >=20 > > ... > >=20 > > FIR SHOULD be used only in situations where not > > sending a decoder refresh point would render the video=20 > usable for the > > users. ^=20 > unusable? > >=20 > > 7.8.3.1. Renegotiation of SDP bandwidth attribute > > ... > > Therefore for SIPREC, implementations are > > RECOMMENDED to use TMMBR for temporary changes, and=20 > renegotiation of > > bandwidth via SDP offer/answer of more permanent changes. > > ^ suggest to replace with=20 > "of changes with a > > longer duration." > >=20 > > 8.2. Procedures at the SRS > > ... > > Certain errors, such syntax errors or ... > > ^ as > >=20 > >=20 > >=20 > > 10.2. Procedures at the SRC > >=20 > >=20 > > In the > > absence of the "record-aware" option tag, meaning that=20 > the UA is not > > recording-aware, an SRC MUST provide recording=20 > indications, where SRC > > is required to do so based on policies, through other=20 > means such as > > playing a tone inband. > >=20 > > Prefer to say > > In the absence of the "record-aware" option tag, meaning=20 > that the UA is not > > recording-aware, an SRC MUST provide recording indications=20 > through other > > means such as playing a tone inband, if the SRC is required=20 > to do so e.g. > > based on policies. >=20 > [Henry] Okay that sounds better. >=20 > >=20 > >=20 > > Figure 8: Recording indication example > >=20 > > Missing (2) for the 200OK, (6) ACK should read (7) ACK >=20 > [Henry] Oh right, thanks. >=20 > > Would the > > (5) re-INVITE (SDP + a=3Drecord:off) > > also include an a=3Dinactive direction attribute? >=20 > [Henry] Stopping the recording does not mean the media stream=20 > in the communication is paused though. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > mit freundlichen Gr=FC=DFen/Kind Regards > >=20 > > Dr.-Ing. Thomas Stach > > Siemens Enterprise Communications Austria > > RPDC P SE > > Dietrichgasse 27 > > A-1030 Vienna > > Tel: +43 57008 4377 > > Fax: +43 570085 4377 > > mailto:thomas.stach@siemens-enterprise.com > >=20 > >=20 > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From eckelcu@cisco.com Mon Jun 4 10:27:21 2012 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 03FE421F8664 for ; Mon, 4 Jun 2012 10:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, 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 5AQ9FoPMvMNm for ; Mon, 4 Jun 2012 10:27:19 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF8E21F866D for ; Mon, 4 Jun 2012 10:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=20958; q=dns/txt; s=iport; t=1338830839; x=1340040439; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=werrmAFg6bRvfZkmkuBOOdPufB+r3+iQbbsRbVfTgqY=; b=K5Zec7jl00y+/SxzO8JWuqX4QnS26gNfhCgqT3PjyqZuJimS8mmLlTad 1Afh9uG/etSfUlbiIlEuIErVfT4CzyZzq6AQgVwLpoEvT6HyWsBuceK9S x9Zxa8A8B9HnK2nS5RHsTSUf9szSWUvPg0tYigOwlEMbSBnH2o3/wtabY o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAErvzE+rRDoJ/2dsb2JhbABEtC6BB4IYAQEBAwEBAQEPARQJOAYXBAIBCBEBAwEBCwYXAQYBJh8DBggBAQQBEggah2QEAQuXJp80BIsRhTBgA4gNM5prgWaDAIE2BR4 X-IronPort-AV: E=Sophos;i="4.75,713,1330905600"; d="scan'208";a="47601597" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 04 Jun 2012 17:27:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q54HRIkW018268; Mon, 4 Jun 2012 17:27:18 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jun 2012 10:27:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jun 2012 10:27:11 -0700 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF74089C9AD9@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comments on draft-ietf-siprec-protocol-04.txt Thread-Index: Ac0/7TIgzKfBodLOQ5uuQGRK/AIn/QAOtySgAJKyvZA= References: <059AF07365DC474393A19A3AF187DF74089C9AD9@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Henry Lum" , "Stach, Thomas" , X-OriginalArrivalTime: 04 Jun 2012 17:27:18.0385 (UTC) FILETIME=[4A9B5E10:01CD4277] Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-04.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, 04 Jun 2012 17:27:21 -0000 Yes, thank you Thomas for your thorough review. Please see additional comments inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > Sent: Friday, June 01, 2012 1:58 PM > To: Stach, Thomas; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-04.txt >=20 > Hi Thomas, thanks for the review. Please see inline. >=20 > I will defer to Charles on the RTP handling sections. >=20 > Henry >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of > > Stach, Thomas > > Sent: June-01-12 7:54 AM > > To: siprec@ietf.org > > Subject: [siprec] Comments on draft-ietf-siprec-protocol-04.txt > > > > Leon, > > > > I read through the draft. > > It is already well progressed, but I also have some questions and > comments. > > > > Regards > > Thomas > > > > > > > > 4. Overview of operations > > > > The architecture document draft-ietf-siprec-architecture-04 = describes > > scenarios where either the SRC or the SRS can establish the = recording > session. > > However, section 4 of the protocol document has the focus on the = case > where > > the SRC initiates the RS and doesn't describe the other option. > Other section > > have similar issues as detailed further down. >=20 > [Henry] Paragraph 1 of section 5.2 mentions that an SRS can establish = a > recording session by sending a new INVITE to SRC. We don't specify = what > calls SRS wants to record in this recording session and how this is > done; it's beyond the scope of this draft. >=20 > > > > > > 5.1. Procedures at the SRC > > ... > > In addition, when an SRC sends a REGISTER request > > to a registrar, the SRC MUST include the '+sip.src' feature tag = to > > indicate the that it is a SRC. > > > > This would only be the case if the SRC is located in a SIP UA. A > B2BUA would > > not register. >=20 > [Henry] Whether a SIP UA registers or not it's entirely up to the UA, = I > don't think we need to qualify which type of UA it is. This statement > here requires that whenever a SRC UA needs to register it must include > the feature tag. >=20 > > Section 5.1 does not specify behaviour of the SRC when it receives > the initial > > INVITE from the SRS. >=20 > [Henry] The SRC recognizes a recording session with the presence of = the > siprec option. How the SRC chooses to accept the request is up to the > SRC, and the SRC must also include the +sip.src feature tag in the > contact. Can you clarify what other behaviour you are looking for that > needs to be specified? >=20 > > How should the SRC behave when the SRS establishes a "permanent" > recording > > session, how when the recording session is established mid-call. > > Is there a difference? >=20 > [Henry] We always qualify a SIP session as a recording session with = the > use of the siprec option. It must be included in the initial INVITE = and > you cannot change that in the mid-call. >=20 > > Should the user get any hint on its UI when the session is recorded? > > I saw some text afterwards in section 10, but that is far away. = Maybe > a hint > > would help? >=20 > [Henry] Note that the recording session is different than the user = call > (communication session) and the recording session purely deals with > transporting recorded media. The recording indication needs to show up > in the communication session so that is why it has a separate section > 10. > > > > 5.2. Procedures at the SRS > > > > Section 5.2 does not specify behaviour of the SRS when it receives > the initial > > INVITE from the SRC. >=20 > [Henry] I have a similar question for the SRC behaviour above. The SRS > identifies a recording session with the option tag and it's up to SRS > to accept the INVITE or not. >=20 > > E.g. is it a failure case when the '+sip.srs' feature tag or the > "siprec" > > option tag is missing in the INVITE from the SRC? Other parts of = the > draft > > talk about SIPREC-unaware UAs, so it's probably not an error? >=20 > [Henry] When the siprec option or +sip.src is missing then it means > that the SIP session is not qualified as a recording session. The > behaviour for handling a regular SIP session is up to the SRS. >=20 > > > > 6. SDP Handling > > > > Although it sounds trivial, should the draft mention that SRC and = SRS > MUST > > support SDP with multiple m-lines? >=20 > [Henry] This is already covered in RFC3264 section 5. It would be > confusing to add normative statements on what is already normative. >=20 > > > > 6.1. Procedures at the SRC > > > > Since the SRC does not expect to receive media from the SRS, the > SRC > > typically sets each media stream of the SDP offer to only send > media, > > by qualifying them with the a=3Dsendonly attribute, according to = the > > procedures in [RFC3264]. > > > > Consider the the SRC sending an SDP answer with the direction > attribute set to > > a=3Dsendonly. >=20 > [Henry] Okay I will add a statement on this. >=20 > > > > 6.2. Procedures at the SRS > > > > The SRS only receives RTP streams from the SRC, the SDP answer > > normally sets each media stream to receive media, by setting them > > with the a=3Drecvonly attribute, according to the procedures of > > [RFC3264]. > > > > The text only talks about SDP answers. If the SRS initiates the > recording > > session it would set the direction attribute to a=3Drecvonly in the = SDP > _offer_ > > of the INVITE. Of course, the SRS could send an offerless INVITE, > which would > > again result in the SRC being the offerer, but this is not detailed > in the > > current text. >=20 > [Henry] Actually the SRS should not be adding media streams since the > SRS is purely receiving media. Even when the SRS is initiating the > recording session, the INVITE should not have an offer and let the SRC > decide what the recorded streams are. >=20 > > > > ... When the SRS is ready to receive recorded streams, the > > SRS sends a new SDP offer and sets the media streams with > a=3Drecvonly > > attribute. > > > > a=3Drecvonly could also be in the initial offer. > > > > 9. Persistent Recording > > > > The draft talks about using the direction attribute a=3Dinactive in > earlier > > section. > > That results in RTCP still being sent for a persistent recording > session, when > > there is nothing to record. > > Is there anything to say about RTCP usage in this situation in more > detail? > > >=20 > [Henry] The intention of a persistent recording is that the media > stream is still in sendonly state and not in inactive. In any case, > RTCP is still sent periodically, and I don't think we need to have > special handling for RTCP. >=20 > > > > 10.1. Procedures at the record-aware user agent > > > > > > A recording-aware UA SHOULD indicate that it can accept reporting > of > > recording indication provided by the SRC. > > At the risk of being ingnorant of previous discussions, why is this > just a > > SHOULD? > > Who would receive this indication? The B2BUA or the peer SIP UA? > Both? >=20 > [Henry] In this section we are talking about the participants in the > call being recorded (the communication session). If the participant > which can be any kind of user agent supports the extensions described > in this section, then the UA should indicate that it supports them. We > don't mandate that a UA must support these extensions since we need to > interoperate with regular 3261 SIP UA to be recorded. Actually, I agree with Thomas's comment here. I believe the reasoning = Henry provides is accurate; however, we decided to specifically call out = and define the roll of a recording-aware UA vs. a legacy UA that may not = be recording-aware. For a recording-aware UA, I think MUST is = appropriate. =20 > > > > A new option tag "record- > > aware" is introduced to indicate such awareness. The recording- > aware > > UA SHOULD include the "record-aware" option tag in the Supported > > header when initiating or establishing a CS. > > Again why just SHOULD? > > Who would receive this indication? >=20 > [Henry] Only an SRC would care about the record-aware indication since > the SRC would be performing the recording. [cue] I think other network elements, such as recording-aware MCU, may be = interested in this capability of a UA as well. For example, if a recording-aware MCU knows that there is an SRC in a = conference, and that SRC is currently recording, the MCU may want to = propagate the recording indication from the SRC to the conference = participants out of band using the mechanism defined in this draft. > > 10.1.1. Recording preference > > > > > > A recording-aware UA involved in a CS MAY request the CS to be > > recorded or not recorded. This indication of recording = preference > > can be sent at session establishment time or during the session. > > > > Does the UA request the recording? Or is it the user? >=20 > [Henry] This can be a human user or just the UA requesting the call to > be recorded; the indication is sent by the UA. >=20 > > Who receives this request? Who sends the "indication of recording > preference"? > > I'd like to see some explicitly spelled out procedures here. >=20 > [Henry] Perhaps I can provide an example here to illustrate how this > works, but the procedures of what a recording-aware UA are already > provided in section 10.1. >=20 > > > > A new SDP attribute "recordpref" is introduced. The SDP = attribute > > appears at the media level or session level and can appear in an > SDP > > offer or answer. The recording indication applies to the > specified > > media stream only. > > What does the session level attribute mean? Probably, all media > streams are > > peferred to be recorded. >=20 > [Henry] the session level mean that all media streams have the > attribute applied. You can also set this at the media stream level to > indicate which media stream you wish to be (or not to be recorded). = For > example, you only wish your audio to be recorded but not your video > stream, then you can set the attribute as a=3Drecordpref:on in the = audio > media stream and a=3Drecordpref:off in the video media stream. >=20 > > What are the rules when there are session and media level = attributes? > > Does a media level attribute override the session level? > > Is a preference in an offer achknowledged in the answer? >=20 > [Henry] An SRC is not required to honor such preference due to its own > policies, so we have not modeled this attribute with any negotiation > and this merely indicate what the user preference is for this media > stream or session. The user will only know whether it is recording or > not through the recording indication, and the SRC is required to > provide the indication via the a=3Drecord attribute. >=20 > > If the attribute was omitted in the offer what does it mean when it > is > > included in the answer? >=20 > [Henry] We have discussion about this before and the conclusion is = that > the omission of this attribute is equivalent to > a=3Drecordpref:nopreference. >=20 > > > > recordpref-attr =3D "a=3Drecordpref:" pref > > > > pref =3D "on" / "off" / "pause" / "nopreference" > > > > Do you want to make pref extensible by adding "/ token"? Just in = case > ... >=20 > [Henry] > > > > on Request for recording if it has not already been started. If > the > > recording is currently paused, request to resume recording. > > off Request for no recording. If recording has already been > > started, then this preference indicates a request to stop > > recording. > > ... > > > > The section title and ABNF syntax say "preference", but the > explanatory text > > talk about "requests". > > What is it? A preference, an indication, a request, a ocmmand? > > If it is a request, is there a response? >=20 > [Henry] "request" is indeed a bad choice of wording here. As I > mentioned above, this is not a request/response parameter and I will > correct the wording here. >=20 > Revised text: >=20 > on Indicate that the UA wishes to be recorded or resume = recording > if the recording is paused. > off Indicate that the UA wishes not to be recorded or stop the > recording if a recording is already in progress. > pause Indicate that the UA wishes the recording to be paused if the > recording is in progress. >=20 > > I haven't followed the SIPREC discussions closely, so apologies if > this was > > already discussed, but > > would SDP be the right protocol for sending requests/commands? > > I would expect pushback from the SDP directorate. > > If this is just an indication of a preference, I also think it is > somewhat > > questionable, if SDP is the right place or if it would be better at > the SIP > > level. As the latter would complicate things, I will sit on the > fence. >=20 > [Henry] We had discussions on this before and the reason we use SDP > attribute is that we want media stream level indication and = preference. >=20 > > > > 10.2. Procedures at the SRC > > > > When a UA has indicated that it is recording-aware through the > > "record-aware" option tag, the SRC MUST provide recording > indications > > in a new SDP attribute described in the following section. > > I stumbled a little bit over this since the SRC could be located at > the UA or > > at a B2BUA. > > Who would get the recording indication? UA A, UA B, both? >=20 > [Henry] All participants in the communication session must receive the > record-aware indication. >=20 > > > > In the > > absence of the "record-aware" option tag, meaning that the UA is > not > > recording-aware, an SRC MUST provide recording indications, where > SRC > > is required to do so based on policies, through other means such > as > > playing a tone inband. > > > > > > > > > > 10.2.1. Recording indication > > ... > > The 'record' SDP attribute appears at the media level or session > > level in either SDP offer or answer. > > > > Similar as above, what are the rules when there are session and > media level > > attributes? >=20 > [Henry] The SRC can choose to use session level attribute if all the > media streams share the same indication, otherwise the SRC needs to = use > the media level attributes. >=20 > > > > attribute /=3D record-attr > > ; attribute defined in RFC 4566 > > record-attr =3D "record:" indication > > indication =3D "on" / "off" / "paused" > > > > Do you want to make indication extensible by adding "/ token"? Just > in case > > ... >=20 > [Henry] Do we really need a general token? I don't see another > recording state that the SRC can be in. >=20 > > > > 10.2.2. Recording preference > > > > > > When the SRC receives the a=3Drecordpref SDP in an SDP offer or > answer, > > the SRC chooses to honor such request to record the request based > on > > ^ session? >=20 > > local policy on the SRC. > > Same issue with preference vs. request as above. > > When the SRC honors the request, the SRC > > MUST also update the recording indication to reflect the current > > state of the recording (on/off/paused). > > ^ by sending to a=3Drecord:XX attribute? >=20 > [Henry] The wording should be preference rather than request. Thanks > for catching that and I will reword as follows: >=20 > When the SRC receives the a=3Drecordpref SDP in an SDP offer or > answer, > the SRC chooses to honor such the recording preference based on > local policy on the SRC. Whatever actions the SRC chooses, the SRC > MUST also > update the recording indication to reflect the current state of the > recording (on/off/paused). >=20 > > > > > > Editorial nits > > > > The documents talks regularly about SIP headers (e.g. Require = header) > when a > > SIP header field is meant. Although one could accuse me of nit- > picking I would > > prefer the term header field (e.g. Require header field) > > since a SIP message has just a single header, which consists of > multiple > > header fields. > > > > Reference to RFC3311 (UPDATE) is missing >=20 > [Henry] Okay I will fix them. > > > > > > 4.2. Delivering recording metadata > > ... > > This request allows both SRC and SRS to > > restart the states with a new metadata snapshot so that further > > metadata incremental updates will be based on the latest metadata > > snapshot. > > > > Do you mean "synchronize the states" instead of "restart the = states"? >=20 > [Henry] Okay I can change the word here. >=20 > > > > 7.1.1.2. Transcoding Translator > > > > > > When acting as a transcoding translator, an SRC MAY perform > > transcoding (e.g., from one codec to another), and this may = result > in > > a different rate of packets between what the SRC receives and = what > > the sends. > > ^ missing word SRC? [cue] Yes, thanks. > > > > > > 7.1.2. SRC acting as an RTP Mixer > > ... > > Optionally an SRC acting as a mixer can perform transcoding, and > can > > even cope with different codings received from different UAs. > > ^ Do you mean codecs? [cue] Different codecs is one example of different codings, but it is = not the only one. For example, the clock rate or some codec parameter(s) = may be different. > > > > > > 7.7. Keepalive > > > > > > It is anticipated that media streams in SIPREC may exist in > inactive > > states for extended periods of times for an of a number of valid > > reasons. ^ does not parse, > missing word? [cue] an -> any. Thanks for catching it. > > > > 7.8.1. Full Intra Request > > > > A Full Intra Request (FIR) Command, when received by the = designate > > media sender, ... ^ > designated > > > > > > > > 7.8.2. Picture Loss Indicator > > > > ... > > > > FIR SHOULD be used only in situations where not > > sending a decoder refresh point would render the video usable for > the > > users. ^ = unusable? [cue] Yes, thanks. > > 7.8.3.1. Renegotiation of SDP bandwidth attribute > > ... > > Therefore for SIPREC, implementations are > > RECOMMENDED to use TMMBR for temporary changes, and renegotiation > of > > bandwidth via SDP offer/answer of more permanent changes. > > ^ suggest to replace with "of > changes with a > > longer duration." [cue] of -> for Cheers, Charles > > > > 8.2. Procedures at the SRS > > ... > > Certain errors, such syntax errors or ... > > ^ as > > > > > > > > 10.2. Procedures at the SRC > > > > > > In the > > absence of the "record-aware" option tag, meaning that the UA is > not > > recording-aware, an SRC MUST provide recording indications, where > SRC > > is required to do so based on policies, through other means such > as > > playing a tone inband. > > > > Prefer to say > > In the absence of the "record-aware" option tag, meaning that the UA > is not > > recording-aware, an SRC MUST provide recording indications through > other > > means such as playing a tone inband, if the SRC is required to do so > e.g. > > based on policies. >=20 > [Henry] Okay that sounds better. >=20 > > > > > > Figure 8: Recording indication example > > > > Missing (2) for the 200OK, (6) ACK should read (7) ACK >=20 > [Henry] Oh right, thanks. >=20 > > Would the > > (5) re-INVITE (SDP + a=3Drecord:off) > > also include an a=3Dinactive direction attribute? >=20 > [Henry] Stopping the recording does not mean the media stream in the > communication is paused though. > > > > > > > > > > > > > > > > mit freundlichen Gr=FC=DFen/Kind Regards > > > > Dr.-Ing. Thomas Stach > > Siemens Enterprise Communications Austria > > RPDC P SE > > Dietrichgasse 27 > > A-1030 Vienna > > Tel: +43 57008 4377 > > Fax: +43 570085 4377 > > mailto:thomas.stach@siemens-enterprise.com > > > > > > > > _______________________________________________ > > 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 pravindran@sonusnet.com Wed Jun 20 18:12:03 2012 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 08CAE21F85F1 for ; Wed, 20 Jun 2012 18:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] 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 a-kzY4JYGGLd for ; Wed, 20 Jun 2012 18:12:00 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1C35E21F85E0 for ; Wed, 20 Jun 2012 18:11:59 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT+J038TOiuySK6AXoGmgEOe5h3xS8UzU@postini.com; Wed, 20 Jun 2012 18:12:00 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 20 Jun 2012 21:12:38 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 21 Jun 2012 06:41:53 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbR///8r+AgAXAYoCAAF0f0IAC2bZggBNHBaCAADQIYIABFw2wgAGkwDCAABa4gIAh2vEw Date: Thu, 21 Jun 2012 01:11:52 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160557A2@inba-mail01.sonusnet.com> References: , <4FAC1EDD.8030800@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C16034636@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C16034E25@inba-mail01.sonusnet.com> <9F33F40F6F2CD847824537F3C4E37DDF012140@MCHP04MSX.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C1603732F@inba-mail01.sonusnet.com> <9F33F40F6F2CD847824537F3C4E37DDF012A04@MCHP04MSX.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C160389A1@inba-mail01.sonusnet.com> <9F33F40F6F2CD847824537F3C4E37DDF013E3F@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013E3F@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. 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, 21 Jun 2012 01:12:03 -0000 Hi Andy, >From SRC perspective, there are two streams towards RS with the same conten= t and each stream has to have different unique id to differentiate with str= eam_id. The stream_id is not directly mapped with individual CS stream as i= t is not possible with mixed streams. The related current text in sec 6.7 o= f metadata draft is "A Media Stream class (and its objects) has the properties of media as seen= by SRC and sent to SRS." Please let me know whether the text has to be updated for more clarity. Als= o, the open item here is "any attribute is required to indicate that two st= ream towards SRS are same" Thanks Partha >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Wednesday, May 30, 2012 5:37 PM >To: Ravindran, Parthasarathi >Cc: siprec@ietf.org; john.2.stafford@bt.com >Subject: RE: [siprec] Proposal for minor changes to metadata to support >mixed stream and duplicated stream recording. > >Hi Partha, > >Ok so why in your example do the two streams contain different >stream_id's if they both are referring to the same stream within the CS? > >Regards >Andy > > > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 30 May 2012 11:49 >> To: Hutton, Andrew; john.2.stafford@bt.com >> Cc: siprec@ietf.org >> Subject: RE: [siprec] Proposal for minor changes to metadata to >> support mixed stream and duplicated stream recording. >> >> Hi Andy, >> >> I think that we are in the same page. Duplication of single CS stream >> into multiple RS stream is one of the usecase mentioned in the below >> mail. Multiple label in "stream" element does not indicate the >> duplication of the CS stream automatically. Apart from this, There is >> a need of explicit grouping mechanism to say that two stream are >> duplicate of each other. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >> >Sent: Tuesday, May 29, 2012 3:27 PM >> >To: Ravindran, Parthasarathi; john.2.stafford@bt.com >> >Cc: siprec@ietf.org >> >Subject: RE: [siprec] Proposal for minor changes to metadata to >> support >> >mixed stream and duplicated stream recording. >> > >> >Hi Partha, >> > >> >Before looking at your reasons in more detail I want to check we are >> on >> >the same page. >> > >> >The case I think we are discussing is recoding the same CS stream (m- >> >line) in multiple m line streams of one RS. (i.e. a single CS stream >> is >> >duplicated in to multiple RS streams). Is this also your >> >understanding >> ? >> > >> > >> >Regards >> >Andy >> > >> > >> >> -----Original Message----- >> >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> >> Sent: 28 May 2012 18:15 >> >> To: Hutton, Andrew; john.2.stafford@bt.com >> >> Cc: siprec@ietf.org >> >> Subject: RE: [siprec] Proposal for minor changes to metadata to >> >> support mixed stream and duplicated stream recording. >> >> >> >> Andy, >> >> >> >> Recording multiple m line in CS has to be represented as follows: >> >> >> >> > >> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >> >> >> > >> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >> >> >> >> >> The reason for this approach in XML is due to the metadata model >> >> constraints and the exact details are as follows: >> >> >> >> 1) Mapping of each individual label (SDP "m" line) to single stream >> by >> >> which participantstream's attributes will explain about the stream >> >> correctly. Say video label attribute is added in the stream element >> >> during mid-dialog whereas the session is established with audio >> label >> >> & stream, here video label association time is different from audio >> >> label association time. >> >> >> >> 2) Partial update for each stream independently provide more >> >> flexibility. (Add & Remove stream without impacting any other >> stream). >> >> >> >> In case of multiple label exists within single stream as shown in >> your >> >> mail, >> >> >> >> 1) It is impossible to deduce the association and disassociation >> time >> >> of the individual label or SDP "m" line >> >> 2) It is possible to have the wrong information like indicate one >> >> of the stream in "recv" association whereas other stream is in >"send" >> >> association (Hypothetical scenario). >> >> >> >> So, stream XML element has to have single label attribute within >> >> itself. >> >> >> >> Thanks >> >> Partha >> >> >> >> >-----Original Message----- >> >> >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >> >> >Sent: Monday, May 28, 2012 7:46 PM >> >> >To: Ravindran, Parthasarathi; john.2.stafford@bt.com >> >> >Cc: siprec@ietf.org >> >> >Subject: RE: [siprec] Proposal for minor changes to metadata to >> >> support >> >> >mixed stream and duplicated stream recording. >> >> > >> >> >Hi All, >> >> > >> >> >I just want to make sure I understand the results of this >> discussion >> >> and >> >> >whether we have consensus. >> >> > >> >> >I am assuming we have consensus to move to using "stream_id" >> >> >rather >> >> than >> >> >"id" as this is what the XML experts are telling us is correct. >> >> > >> >> >Mixed Stream Recording >> >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> >> > >> >> >For the mixed stream scenario in which streams from two CS's are >> >> >mixed in to a single RS stream then the following seems to be what >> we >> >> >have settled on. >> >> > >> >> > > >> > session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> > >> >> > >> >> > > >> > session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> > >> >> > >> >> > >> >> > >> >> >Recoding same CS stream in multiple m line streams of 1 RS >> >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> > >> >> >I am not sure I have it right for this case but I think assuming >> the >> >> >change to use "stream_id" and "session_id" would result in the >> >> >following: >> >> > >> >> > > >> > session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> > >> >> > >> >> > >> >> > >> >> >Do we have any issues with this? >> >> > >> >> >Regards >> >> >Andy (SIPREC Co-Chair). >> >> > >> >> > >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> >> >> On Behalf Of Ravindran, Parthasarathi >> >> >> Sent: 16 May 2012 08:30 >> >> >> To: Ravindran, Parthasarathi; john.2.stafford@bt.com >> >> >> Cc: siprec@ietf.org >> >> >> Subject: Re: [siprec] Proposal for minor changes to metadata to >> >> >> support mixed stream and duplicated stream recording. >> >> >> >> >> >> Hi all, >> >> >> >> >> >> In case there is no objection to the below proposal with >> >> >> explicit id instead of "id" usage till 23rd May (Next >> >> >> Wednesday), I think that >> >> it >> >> >> is better to incorporate in (-07) metadata draft as these >> >> >> changes helps for the progresses of the metadata draft. Please >> >> >> let me >> know >> >> >> your opinion on the same. >> >> >> >> >> >> Thanks >> >> >> Partha >> >> >> >> >> >> >-----Original Message----- >> >> >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >> >> >> Behalf >> >> >> >Of Ravindran, Parthasarathi >> >> >> >Sent: Monday, May 14, 2012 5:40 PM >> >> >> >To: john.2.stafford@bt.com >> >> >> >Cc: siprec@ietf.org >> >> >> >Subject: Re: [siprec] Proposal for minor changes to metadata to >> >> >> support >> >> >> >mixed stream and duplicated stream recording. >> >> >> > >> >> >> >John, >> >> >> > >> >> >> >My example is to show how to represent single stream in two CS >> and >> >> it >> >> >> is >> >> >> >as follows: >> >> >> > >> >> >> > > >> >> > session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D= "> >> >> >> > >> >> >> > >> >> >> > > >> >> > session_id=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> > >> >> >> > >> >> >> > >> >> >> >In the above example, Axzg12XHdhjelfjhdldjf;34jn78=3D=3D is the >> single >> >> >> >stream id which is Used by two CS namely >> >> zzlafnvvjlCHllaHF6mn8kkSS=3D=3D >> >> >> >& zSfPoSvdSDCmU3A3TRDxAw=3D=3D. >> >> >> > >> >> >> >The trouble with multiple label in single stream is that the >> >> handling >> >> >> of >> >> >> >participantstream association for each of the label >> >> >> >individually >> >> >> within >> >> >> >the single stream element. >> >> >> > >> >> >> >Duplicate stream recording has to have separate streams to >> >> >> >distinguish the actual & duplicate stream. >> >> >> > >> >> >> > >> >> >> >Thanks >> >> >> >Partha >> >> >> > >> >> >> >>-----Original Message----- >> >> >> >>From: john.2.stafford@bt.com [mailto:john.2.stafford@bt.com] >> >> >> >>Sent: Monday, May 14, 2012 5:22 PM >> >> >> >>To: Ravindran, Parthasarathi >> >> >> >>Cc: siprec@ietf.org >> >> >> >>Subject: RE: [siprec] Proposal for minor changes to metadata >> >> >> >>to >> >> >> support >> >> >> >>mixed stream and duplicated stream recording. >> >> >> >> >> >> >> >>Partha, >> >> >> >> >> >> >> >>You are suggesting >> >> >> >>>>>> > >> >> >>>>>> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session_id=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> > >> >> >>>>>> session_id=3D" zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>I am confused, what is the example you show supposed to >> >> >> >>respresent >> >> ? >> >> >> >> >> >> >> >> >> >> >> >>To hark back to my original request, what is your objection to >> >> >> >>the following, as it seems simpler to me than what you are >> >suggesting: >> >> >> >> >> >> >> >>>>>> If we have a persistent RS with a single m-line, and a >> >> >> >>>>>> single CS being recorded via a mixed TX/RX stream, then >> the >> >> >> >>>>>> metadata will have a single element, which has a >> >> >> >>>>>> label referencing a >> >> >> RS >> >> >> >>m-line. >> >> >> >> >> >> >> >>>>>> Mixed Stream Recording: >> >> >> >>>>>> >> >> >> >>>>>> Now if we add a 2nd CS to that RS, we will now have >> >> two >> >> >> >>>>>> elements, one for each CS. >> >> >> >>>>>> If they are both being mixed onto the one RS m-line >> stream, >> >> >> >>>>>> both elements will have the same label, ie: >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >> >> >> >> >>>>>> >> >> >> >>>>>> Duplicate Stream Recording If we have a a persistent RS >> >> >> >>>>>> with a two m-line's for >> >> duplicated >> >> >> >>>>>> recording, then the metadata will have a single >> >> >> element, >> >> >> >>>>>> which has a two labels referencing both the RS m-lines. >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>Rgds >> >> >> >>John Stafford | Solution Architect 1 | BT Global Services | >> >> Tel:+44 >> >> >> >>(0)1932 773504 | E: john.2.stafford@bt.com | >> >> >> >>www.bt.com/globalservices >> >> >> >>________________________________________ >> >> >> >>From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On >> Behalf >> >> Of >> >> >> >>Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> >> >>Sent: 10 May 2012 21:02 >> >> >> >>To: Joe Hildebrand >> >> >> >>Cc: siprec@ietf.org >> >> >> >>Subject: Re: [siprec] Proposal for minor changes to metadata >> >> >> >>to >> >> >> support >> >> >> >>mixed stream and duplicated stream recording. >> >> >> >> >> >> >> >>On 5/10/12 11:20 AM, Joe Hildebrand wrote: >> >> >> >>> id is supposed to be unique across the entire document. In >> >> >> >>> some processing software (such as CSS), id has special >> >> >> >>> syntax that takes advantage of that assumption. >> >> >> >> >> >> >> >>OK, I'll take your word for it, since it sounds like otherwise >> it >> >> >> would >> >> >> >>take me down a rat hole that I would rather avoid. >> >> >> >> >> >> >> >> Thanks, >> >> >> >> Paul >> >> >> >> >> >> >> >>> On 5/10/12 7:13 AM, "Ravindran, >> >> >> >>> Parthasarathi" >> >> >> >>> wrote: >> >> >> >>> >> >> >> >>>> Paul, >> >> >> >>>> >> >> >> >>>> XML:id attribute is mentioned in http://www.w3.org/TR/xml- >> id/ >> >> and >> >> >> >>>> each element in XML document has at most one single unique >> >> >> >identifier >> >> >> >>"id". >> >> >> >>>> >> >> >> >>>> Including Joe in this mail thread. >> >> >> >>>> >> >> >> >>>> Thanks >> >> >> >>>> Partha >> >> >> >>>> >> >> >> >>>>> -----Original Message----- >> >> >> >>>>> From: siprec-bounces@ietf.org >> >> >> >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> >> >> >>>>> Sent: Wednesday, May 09, 2012 7:45 PM >> >> >> >>>>> To: siprec@ietf.org >> >> >> >>>>> Subject: Re: [siprec] Proposal for minor changes to >> metadata >> >> to >> >> >> >>>>> support mixed stream and duplicated stream recording. >> >> >> >>>>> >> >> >> >>>>> The new form reads nicely, but it is a bit verbose. >> >> >> >>>>> I'd be interested to hear more about why "id" is *special* >> in >> >> >> XML. >> >> >> >>>>> >> >> >> >>>>> Thanks, >> >> >> >>>>> Paul >> >> >> >>>>> >> >> >> >>>>> On 5/9/12 9:44 AM, Ravindran, Parthasarathi wrote: >> >> >> >>>>>> Hi John, >> >> >> >>>>>> >> >> >> >>>>>> Sorry for the delay reply. In the object model, there is >> >> >> >>>>>> unique- >> >> >> id >> >> >> >>>>>> and association related to the object. In case of XML >> >> >> >>>>>> representation, unique-id of the object is represented as >> >> >> >>>>>> XML attribute "id" and the association of the object is >> >> represented >> >> >> by >> >> >> >>second attribute . >> >> >> >>>>>> >> >> >> >>>>>> While I discussing with XML experts, I understand that >> "id" >> >> has >> >> >> >>>>>> special meaning in XML and it should not be repeated. So, >> >> >> >>>>>> I'm proposing to have object name with id for both >> >> >> >>>>>> attributes and >> >> >> XML >> >> >> >>>>> looks as follows: >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session_id=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> stream_id=3D"EiXGlc+4TruqqoDaNE76ag=3D=3D" >> >> >> >>>>>> session_id=3D" zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Please let me know your opinion on the same. >> >> >> >>>>>> >> >> >> >>>>>> Thanks >> >> >> >>>>>> >> >> >> >>>>>> Partha >> >> >> >>>>>> >> >> >> >>>>>> *From:*john.2.stafford@bt.com >> >> >> >>>>>> [mailto:john.2.stafford@bt.com] >> >> >> >>>>>> *Sent:* Thursday, March 29, 2012 2:35 PM >> >> >> >>>>>> *To:* Ravindran, Parthasarathi; siprec@ietf.org >> >> >> >>>>>> *Subject:* RE: [siprec] Proposal for minor changes to >> >> metadata >> >> >> to >> >> >> >>>>>> support mixed stream and duplicated stream recording. >> >> >> >>>>>> >> >> >> >>>>>> Partha, >> >> >> >>>>>> >> >> >> >>>>>> so you are saying there is no need to allow multiple >> labels >> >> on >> >> >> >>>>>> a stream element, as a stream elemet can be repeated in >> the >> >> >> metadata >> >> >> >>>>> multiple times. >> >> >> >>>>>> >> >> >> >>>>>> I dont see how this matches the object model, a element >> with >> >> a >> >> >> >>>>>> unique id can surely on occur once in the matadata. >> >> >> >>>>>> >> >> >> >>>>>> Rgds >> >> >> >>>>>> >> >> >> >>>>>> John Stafford | Solution Architect 1 | BT Global Services >> | >> >> >> >Tel:+44 >> >> >> >>>>>> (0)1932 773504 | E: john.2.stafford@bt.com >> >> >> >>>>>> | >> >> >> >>>>>> _www.bt.com/globalservices >> >> >> >>>>>> _ >> >> >> >>>>>> >> >> >> >>>>>> --------------------------------------------------------- >> >> >> >>>>>> - >> -- >> >> >> >>>>>> - >> >> -- >> >> >> >>>>>> - >> >> >> -- >> >> >> >- >> >> >> >>>>>> --- >> >> >> >>>>>> -- >> >> >> >>>>>> >> >> >> >>>>>> *From:*Ravindran, Parthasarathi [pravindran@sonusnet.com] >> >> >> >>>>>> *Sent:* 28 March 2012 22:42 >> >> >> >>>>>> *To:* Stafford,J,John,JRJ3X C; siprec@ietf.org >> >> >> >>>>>> >> >> >> >>>>>> *Subject:* RE: [siprec] Proposal for minor changes to >> >> metadata >> >> >> to >> >> >> >>>>>> support mixed stream and duplicated stream recording. >> >> >> >>>>>> >> >> >> >>>>>> John, >> >> >> >>>>>> >> >> >> >>>>>> I'll explain how to form metadata XML element for your >> >> >> >requirement: >> >> >> >>>>>> >> >> >> >>>>>> "Siprec support for recording same CS stream in multiple >> >> >> >>>>>> m >> >> line >> >> >> >>>>>> streams of 1 RS: >> >> >> >>>>>> This is the converse of the above, I propose that >> >> >> >>>>>> multiple >> >> >> labels >> >> >> >>>>>> be allowed in a stream element, the meaning would be that >> >> >> >>>>>> the stream is recorded in all of the referenced recording >> >> >> >>>>>> m-line >> >> >> >>streams." >> >> >> >>>>>> >> >> >> >>>>>> Here, There are two CS's, 2 m'line and 1 RS. For >> >> >> >>>>>> representing as per current XML schema is as follows, >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > >> >> >>>>>> session=3D" zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Could you please explain the issue in the above approach. >> >> >> >>>>>> >> >> >> >>>>>> Thanks >> >> >> >>>>>> >> >> >> >>>>>> Partha >> >> >> >>>>>> >> >> >> >>>>>> *From:*siprec-bounces@ietf.org> >> bounces@ietf.org> >> >> >> >>>>>> [mailto:siprec-bounces@ietf.org] *On Behalf Of >> >> >> >>>>>> *john.2.stafford@bt.com >> >> >> >>>>>> *Sent:* Wednesday, March 28, 2012 8:19 PM >> >> >> >>>>>> *To:* siprec@ietf.org >> >> >> >>>>>> *Subject:* [siprec] Proposal for minor changes to >> >> >> >>>>>> metadata to support mixed stream and duplicated stream >recording. >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> This is as follow up to the threads "How to specify in >> >> metadata >> >> >> >>>>>> that multiple CS's are being recorded in a single mixed >> >> >> >>>>>> RS >> m >> >> >> line >> >> >> >>>>>> stream" >> >> >> >>>>>> http://www.ietf.org/mail- >> >> >> archive/web/siprec/current/msg03126.html >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> "How to specify in metadata that a participants stream is >> >> being >> >> >> >>>>>> recorded in multiple m line streams" >> >> >> >>>>>> http://www.ietf.org/mail- >> >> >> archive/web/siprec/current/msg03107.html >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Siprec support for mixed stream recording: >> >> >> >>>>>> I propose multiple streams would use the same label, >> >> >> >>>>>> >> >> >> >>>>>> indicating that the streams are recorded in the same >> >> recording >> >> >> >>>>>> m-line stream. >> >> >> >>>>>> >> >> >> >>>>>> Siprec support for recording same CS stream in multiple m >> >> line >> >> >> >>>>>> streams of 1 RS: >> >> >> >>>>>> This is the converse of the above, I propose that >> >> >> >>>>>> multiple >> >> >> labels >> >> >> >>>>>> be allowed in a stream element, the meaning would be that >> >> >> >>>>>> the stream is recorded in all of the referenced recording >> >> >> >>>>>> m-line >> >> >> >>streams. >> >> >> >>>>>> >> >> >> >>>>>> Implications for existing metadata specification: >> >> >> >>>>>> This does not change the existing metadata usage of >> streams >> >> and >> >> >> >>>>>> labels, it just adds more flexibility. >> >> >> >>>>>> The only changes required would be that 1. stream's label >> >> >> element >> >> >> >>>>>> maxoccurs=3D"1" restriction would need to be removed 2. >> there >> >> >> would >> >> >> >>>>>> be a 1:n stream:label relationship not 1:1. >> >> >> >>>>>> I can't see anything in draft-ietf-siprec-metadata-06 >> >> >> >>>>>> that >> >> says >> >> >> >>>>>> there is a 1:1 relationship anyway. >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Examples: >> >> >> >>>>>> Mixed Stream Recording: >> >> >> >>>>>> If we have a persistent RS with a single m-line, and a >> >> >> >>>>>> single CS being recorded via a mixed TX/RX stream, then >> the >> >> >> >>>>>> metadata will have a single element, which has a >> >> >> >>>>>> label referencing a >> >> >> RS >> >> >> >>m-line. >> >> >> >>>>>> >> >> >> >>>>>> Now if we add a 2nd CS to that RS, we will now have >> >> two >> >> >> >>>>>> elements, one for each CS. >> >> >> >>>>>> If they are both being mixed onto the one RS m-line >> stream, >> >> >> >>>>>> both elements will have the same label, ie: >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Duplicate Stream Recording If we have a persistent RS >> >> >> >>>>>> with a single m-line, and a single CS being recorded via >> >> >> >>>>>> a mixed TX/RX stream, then >> the >> >> >> >>>>>> metadata will have a single element, which has a >> >> >> >>>>>> label referencing a >> >> >> RS >> >> >> >>m-line. >> >> >> >>>>>> >> >> >> >>>>>> If we have a a persistent RS with a two m-line's for >> >> duplicated >> >> >> >>>>>> recording, then the metadata will have a single >> >> >> element, >> >> >> >>>>>> which has a two labels referencing both the RS m-lines. >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Finally, we could have both the above scenarios together, >> >> where >> >> >> >the >> >> >> >>>>>> mixed two CS recording is duplicated: >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> > >> >> >>>>>> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> So why do I think siprec should support these changes ? >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Requirements for mixed stream recording: >> >> >> >>>>>> >> >> >> >>>>>> RFC6341 refers to mixed recording in use cases 3 and 11 >> and >> >> in >> >> >> REQ >> >> >> >>9:: >> >> >> >>>>>> >> >> >> >>>>>> In Use Case 3: >> >> >> >>>>>> In some cases, more than one concurrent Communication >> >> >> >>>>>> Session >> >> >> (on >> >> >> >a >> >> >> >>>>>> single end-user apparatus, e.g., trading-floor turret) is >> >> mixed >> >> >> >>>>>> into one Recording Session: >> >> >> >>>>>> >> >> >> >>>>>> |-------- CS 1 -------| >> >> >> >>>>>> |-------- CS 2 -------| >> >> >> >>>>>> |-------- CS 3 -------| >> >> >> >>>>>> >> >> >> >>>>>> RS |----------- Recording Session --------------| >> >> >> >>>>>> t---> >> >> >> >>>>>> >> >> >> >>>>>> In Use case 11: >> >> >> >>>>>> In trading-floor environments, in order to minimize >> storage >> >> and >> >> >> >>>>>> recording system resources, it may be preferable to mix >> >> >> >>>>>> multiple concurrent calls (Communication Sessions) on >> >> different >> >> >> >>>>>> handsets/ speakers on the same turret into a single >> >> >> >>>>>> recording >> >> >session. >> >> >> >>>>>> >> >> >> >>>>>> REQ-009: The mechanism MUST support the ability for an >> >> >> >>>>>> SRC to deliver mixed audio streams from different parties >> >> >> >>>>>> of a given Communication Session to an SRS. >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> To me this implies multiple CS's in one mixed recorder >> >> stream, >> >> >> >>>>>> since the requirement specifically >> >> >> >>>>>> >> >> >> >>>>>> says "mix", and "to minimise storage". >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Requirements for Duplicated stream recording: >> >> >> >>>>>> RFC6341 does not specifically mention duplicated >> >> >> >>>>>> recording >> >> But >> >> >> >>>>>> I don't think allowing it would complicate the metadata, >> and >> >> it >> >> >> will >> >> >> >>>>>> be down to the recorder >> >> >> >>>>>> >> >> >> >>>>>> implementation how it handles the duplicated CS >recording. >> >> >> >>>>>> >> >> >> >>>>>> Rgds >> >> >> >>>>>> >> >> >> >>>>>> John Stafford | Solution Architect 1 | BT Global Services >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> _______________________________________________ >> >> >> >>>>>> 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 internet-drafts@ietf.org Wed Jun 27 13:08:59 2012 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 2BEBD21F8661; Wed, 27 Jun 2012 13:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ro2WBI1wDFSy; Wed, 27 Jun 2012 13:08:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C201321F864F; Wed, 27 Jun 2012 13:08:50 -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.21p1 Message-ID: <20120627200850.8489.22945.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 13:08:50 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-05.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:08:59 -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 Recording Protocol Author(s) : Leon Portman Henry Lum Charles Eckel Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-05.txt Pages : 37 Date : 2012-06-27 Abstract: This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-protocol-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Henry.Lum@genesyslab.com Wed Jun 27 13:12:36 2012 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 7EF3C21F8673; Wed, 27 Jun 2012 13:12:36 -0700 (PDT) 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 LSxfnuvBGuCJ; Wed, 27 Jun 2012 13:12:35 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id CFDC911E8089; Wed, 27 Jun 2012 13:12:35 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q5RKCYDx021432; Wed, 27 Jun 2012 13:12:34 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 13:12:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2012 13:12:33 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7408B81E8C@NAHALD.us.int.genesyslab.com> In-Reply-To: <20120627200850.8489.22945.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-05.txt Thread-Index: Ac1UoLKNJW6NGeH5QWuGOQCpcgzHrQAAApSQ References: <20120627200850.8489.22945.idtracker@ietfa.amsl.com> From: "Henry Lum" To: , X-OriginalArrivalTime: 27 Jun 2012 20:12:34.0805 (UTC) FILETIME=[30C13A50:01CD54A1] Cc: siprec@ietf.org Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-05.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:12:36 -0000 Hi, I made quite a few fixes and clarification to the draft to address the comments from the previous IETF meeting, and from Thomas, Andy, and Charles.=20 Regards, Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: June-27-12 4:09 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP Recording Working Group of the IETF. >=20 > Title : Session Recording Protocol > Author(s) : Leon Portman > Henry Lum > Charles Eckel > Alan Johnston > Andrew Hutton > Filename : draft-ietf-siprec-protocol-05.txt > Pages : 37 > Date : 2012-06-27 >=20 > Abstract: > This document specifies the use of the Session Initiation Protocol > (SIP), the Session Description Protocol (SDP), and the Real Time > Protocol (RTP) for delivering real-time media and metadata from a > Communication Session (CS) to a recording device. The Session > Recording Protocol specifies the use of SIP, SDP, and RTP to > establish a Recording Session (RS) between the Session Recording > Client (SRC), which is on the path of the CS, and a Session Recording > Server (SRS) at the recording device. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-siprec-protocol-05 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Wed Jun 27 22:04:15 2012 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 017E621F848F for ; Wed, 27 Jun 2012 22:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 4KnPcHCvL6ba for ; Wed, 27 Jun 2012 22:04:14 -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 52EB711E8087 for ; Wed, 27 Jun 2012 16:00:01 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 842C61EB858B for ; Thu, 28 Jun 2012 00:59:59 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Thu, 28 Jun 2012 00:59:59 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Status of draft-ietf-siprec-architecture Thread-Index: Ac1UuJJJgjyEeWXcT9qC5JANgJDWQg== Date: Wed, 27 Jun 2012 22:59:57 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF03083B@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.251.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Status of draft-ietf-siprec-architecture 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, 28 Jun 2012 05:04:15 -0000 Hi All, Following the previous WGLC and the resulting update to draft-ietf-siprec-a= rchitecture I believe that only one issue has been raised on the list. This was raised by Partha and related to the text in section 3.2.2 which pr= ovides an overview of the procedures relating to SRS initiated recording. O= ne of the bullets currently states: "Identify the session that is to be recorded. The actual mechanism of the = identification depends on SRC policy". As I understand it the issue with this is that it appears to close the door= to any future protocol extensions for identifying the communication sessio= n to be recorded in this SRS initiated case. I think Partha would prefer w= ording that leaves open the possibility of creating a new SIPREC related dr= aft that defines such a mechanism. Any comments, views or suggested text? Regards Andy (SIPREC Co-Chair). From Leon.Portman@nice.com Wed Jun 27 23:15:33 2012 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 825ED11E8097 for ; Wed, 27 Jun 2012 23:15:33 -0700 (PDT) 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 9TDTlpPw45zY for ; Wed, 27 Jun 2012 23:15:32 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3A011E8085 for ; Wed, 27 Jun 2012 23:15:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,489,1336338000"; d="scan'208";a="3262287" Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 28 Jun 2012 09:15:26 +0300 From: Leon Portman To: "Hutton, Andrew" , "siprec@ietf.org" Date: Thu, 28 Jun 2012 09:15:18 +0300 Thread-Topic: Status of draft-ietf-siprec-architecture Thread-Index: Ac1UuJJJgjyEeWXcT9qC5JANgJDWQgAPH8tg Message-ID: <07465C1D981ABC41A344374066AE1A2C3A8CF73E40@TLVMBX01.nice.com> References: <9F33F40F6F2CD847824537F3C4E37DDF03083B@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF03083B@MCHP04MSX.global-ad.net> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Status of draft-ietf-siprec-architecture 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, 28 Jun 2012 06:15:33 -0000 May be something like this: " Identify the session that is to be recorded. The actual mechanism of the= identification can be dependent on SRC policy or be defined by future SIPR= EC extensions" Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Thursday, June 28, 2012 2:00 AM To: siprec@ietf.org Subject: [siprec] Status of draft-ietf-siprec-architecture Hi All, Following the previous WGLC and the resulting update to draft-ietf-siprec-a= rchitecture I believe that only one issue has been raised on the list. This was raised by Partha and related to the text in section 3.2.2 which pr= ovides an overview of the procedures relating to SRS initiated recording. O= ne of the bullets currently states: "Identify the session that is to be recorded. The actual mechanism of the = identification depends on SRC policy". As I understand it the issue with this is that it appears to close the door= to any future protocol extensions for identifying the communication sessio= n to be recorded in this SRS initiated case. I think Partha would prefer w= ording that leaves open the possibility of creating a new SIPREC related dr= aft that defines such a mechanism. Any comments, views or suggested text? Regards Andy (SIPREC Co-Chair). _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Thu Jun 28 01:16:03 2012 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 00A6F21F8905 for ; Thu, 28 Jun 2012 01:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tWw0N8g78pBt for ; Thu, 28 Jun 2012 01:16:02 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id B719721F890E for ; Thu, 28 Jun 2012 01:16:01 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKT+wSwXahpqWIyeZypvTVQpi6MtS0ZD11@postini.com; Thu, 28 Jun 2012 01:16:01 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 28 Jun 2012 04:16:45 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 28 Jun 2012 13:45:55 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman , "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: Status of draft-ietf-siprec-architecture Thread-Index: Ac1UuJJJgjyEeWXcT9qC5JANgJDWQgAPH8tgAARF4lA= Date: Thu, 28 Jun 2012 08:15:53 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1605BBC2@inba-mail01.sonusnet.com> References: <9F33F40F6F2CD847824537F3C4E37DDF03083B@MCHP04MSX.global-ad.net> <07465C1D981ABC41A344374066AE1A2C3A8CF73E40@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C3A8CF73E40@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Status of draft-ietf-siprec-architecture 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, 28 Jun 2012 08:16:03 -0000 Andy/Leon, I agree with the proposed text. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Leon Portman >Sent: Thursday, June 28, 2012 11:45 AM >To: Hutton, Andrew; siprec@ietf.org >Subject: Re: [siprec] Status of draft-ietf-siprec-architecture > >May be something like this: > >" Identify the session that is to be recorded. The actual mechanism of >the identification can be dependent on SRC policy or be defined by >future SIPREC extensions" > >Leon > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Thursday, June 28, 2012 2:00 AM >To: siprec@ietf.org >Subject: [siprec] Status of draft-ietf-siprec-architecture > >Hi All, > >Following the previous WGLC and the resulting update to draft-ietf- >siprec-architecture I believe that only one issue has been raised on the >list. > >This was raised by Partha and related to the text in section 3.2.2 which >provides an overview of the procedures relating to SRS initiated >recording. One of the bullets currently states: > >"Identify the session that is to be recorded. The actual mechanism of >the identification depends on SRC policy". > >As I understand it the issue with this is that it appears to close the >door to any future protocol extensions for identifying the communication >session to be recorded in this SRS initiated case. I think Partha would >prefer wording that leaves open the possibility of creating a new SIPREC >related draft that defines such a mechanism. > >Any comments, views or suggested text? > >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 rmohanr@cisco.com Thu Jun 28 02:28:38 2012 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 6E3A721F89E0 for ; Thu, 28 Jun 2012 02:28:38 -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 xdEU5LORmsws for ; Thu, 28 Jun 2012 02:28:36 -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 D3F4221F897D for ; Thu, 28 Jun 2012 02:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1984; q=dns/txt; s=iport; t=1340875717; x=1342085317; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NaDZKx1Np+2s7S7CaRBSefIuJTwT7hIMwCrtbJiq9Lg=; b=ZBL5aQD+p+5+Gyh0wWvi5AtwZ278T83p5KieCNee6iqw0RzmRetyBfyI FJjWGyDVCJEn1SaOd2aCUWCt+VJnQTy4yeyXjxefRZrmEK77nOCIsVB4p 7Ax7NexvpBaUzoFAPouxjq8sIiQUC2y8QipF+G0MhMZuBsZhRpVcEludv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMMi7E+tJV2Y/2dsb2JhbAA7CrY1gQeCGAEBAQMBAQEBDwEnNBAHBgEIEQEDAQEfCS4LFAMGCAIEARIih2QFC5hMoFkEizcQhXoDlTKOHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="93805810" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jun 2012 09:28:36 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5S9Sa7d002691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Jun 2012 09:28:36 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 04:28:35 -0500 From: "Ram Mohan R (rmohanr)" To: Leon Portman , "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] Status of draft-ietf-siprec-architecture Thread-Index: AQHNVRBkbJ7HLGucNU20/JojjJApZw== Date: Thu, 28 Jun 2012 09:28:35 +0000 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C3A8CF73E40@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.68.75] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19002.004 x-tm-as-result: No--35.286100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7C6EC42294C6594AA02E3B218126A102@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Status of draft-ietf-siprec-architecture 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, 28 Jun 2012 09:28:38 -0000 My take on this is to say simply that the mechanism to identify a session is outside the scope of current work. If we start to include text on some methods to identify a session and leave out other means it would lead to confusion. Regards, Ram > On 28/06/12 11:45 AM, "Leon Portman" wrote: >May be something like this: > >" Identify the session that is to be recorded. The actual mechanism of >the identification can be dependent on SRC policy or be defined by future >SIPREC extensions" > >Leon > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Thursday, June 28, 2012 2:00 AM >To: siprec@ietf.org >Subject: [siprec] Status of draft-ietf-siprec-architecture > >Hi All, > >Following the previous WGLC and the resulting update to >draft-ietf-siprec-architecture I believe that only one issue has been >raised on the list. > >This was raised by Partha and related to the text in section 3.2.2 which >provides an overview of the procedures relating to SRS initiated >recording. One of the bullets currently states: > >"Identify the session that is to be recorded. The actual mechanism of >the identification depends on SRC policy". > >As I understand it the issue with this is that it appears to close the >door to any future protocol extensions for identifying the communication >session to be recorded in this SRS initiated case. I think Partha would >prefer wording that leaves open the possibility of creating a new SIPREC >related draft that defines such a mechanism. > >Any comments, views or suggested text? > >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 Leon.Portman@nice.com Thu Jun 28 03:10:58 2012 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 CF4E221F843C for ; Thu, 28 Jun 2012 03:10:56 -0700 (PDT) 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 J2yDXw909WL7 for ; Thu, 28 Jun 2012 03:10:55 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 84DD021F8455 for ; Thu, 28 Jun 2012 03:03:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,490,1336338000"; d="scan'208";a="3266045" Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 28 Jun 2012 13:03:34 +0300 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "Hutton, Andrew" , "siprec@ietf.org" Date: Thu, 28 Jun 2012 13:03:32 +0300 Thread-Topic: [siprec] Status of draft-ietf-siprec-architecture Thread-Index: AQHNVRBkbJ7HLGucNU20/JojjJApZ5cPgGJw Message-ID: <07465C1D981ABC41A344374066AE1A2C3A8CF73FCE@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C3A8CF73E40@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Status of draft-ietf-siprec-architecture 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, 28 Jun 2012 10:10:59 -0000 Also good option -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Thursday, June 28, 2012 12:29 PM To: Leon Portman; Hutton, Andrew; siprec@ietf.org Subject: Re: [siprec] Status of draft-ietf-siprec-architecture My take on this is to say simply that the mechanism to identify a session i= s outside the scope of current work. If we start to include text on some me= thods to identify a session and leave out other means it would lead to conf= usion. Regards, Ram > On 28/06/12 11:45 AM, "Leon Portman" wrote: >May be something like this: > >" Identify the session that is to be recorded. The actual mechanism of=20 >the identification can be dependent on SRC policy or be defined by=20 >future SIPREC extensions" > >Leon > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >Behalf Of Hutton, Andrew >Sent: Thursday, June 28, 2012 2:00 AM >To: siprec@ietf.org >Subject: [siprec] Status of draft-ietf-siprec-architecture > >Hi All, > >Following the previous WGLC and the resulting update to=20 >draft-ietf-siprec-architecture I believe that only one issue has been=20 >raised on the list. > >This was raised by Partha and related to the text in section 3.2.2=20 >which provides an overview of the procedures relating to SRS initiated=20 >recording. One of the bullets currently states: > >"Identify the session that is to be recorded. The actual mechanism of=20 >the identification depends on SRC policy". > >As I understand it the issue with this is that it appears to close the=20 >door to any future protocol extensions for identifying the=20 >communication session to be recorded in this SRS initiated case. I=20 >think Partha would prefer wording that leaves open the possibility of=20 >creating a new SIPREC related draft that defines such a mechanism. > >Any comments, views or suggested text? > >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 rbarnes@bbn.com Thu Jun 28 08:58:18 2012 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 B121821F85A4 for ; Thu, 28 Jun 2012 08:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 lQA-lqZVp1j9 for ; Thu, 28 Jun 2012 08:58:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABFA21F85A8 for ; Thu, 28 Jun 2012 08:58:18 -0700 (PDT) Received: from dhcp-192-1-255-151.col.bbn.com ([192.1.255.151]:52028) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkH6n-000AIN-27 for siprec@ietf.org; Thu, 28 Jun 2012 11:58:17 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2012 11:58:16 -0400 Message-Id: <657A3659-61DB-433A-97F4-593ECD31DB1B@bbn.com> To: siprec@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Thu, 28 Jun 2012 09:23:01 -0700 Subject: [siprec] Security review of draft-ietf-siprec-protocol-05 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, 28 Jun 2012 15:58:18 -0000 Dear SIPREC, At the SIPREC meeting at the last IETF, I volunteered to do a security = review of the SIPREC protocol document. Thanks to the chairs = increasingly persistent reminders, I've finally gotten around to doing = it :) At one level, my basic question is: How is this better than just doing a = PCAP? I can see the efficiency gains in terms of RTP handling, but I'm = concerned that (1) the security requirements need to be more tightly = specified, and (2) there seems to be quite a bit of information loss. Starting with the most obvious part: The Security Considerations needs = to be tightened up. This document benefits from the fact that the SRC = and the SRS are logically within the same administrative domain, so it = should be feasible to establish credentials that they use to = authenticate one another. So the document should REQUIRE that the SRC = and the SRS mutually authenticate to one another, either using SIP = authentication or using TLS authentication beneath SIPS. At the media level, is there a reason that you don't specify a keying = mechanism? Why would you not just specify DTLS-SRTP? It may also be = worth noting that because this protocol will tend to be used within an = administrative domain, the need for confidentiality is lower than in the = general Internet; however, there is still a strong need for = authentication. So this document should REQUIRE that implementations = support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND = support for others. Speaking of SRTP, it's not clear whether there's a requirement for the = SRC/SRS to have access to the keys used to protect secure media, in the = case where the SRC is a middlebox, not terminating media. To support = this case, you would need (1) a way to get the key from the endpoint to = the SRC, and (2) a way to get the key from the SRC ot the SRS. I would = suggest looking at EKT / KTR for both of these = [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section-4][http://too= ls.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-03]. Finally, it seems like a gap that the SIP signaling information for the = recorded session doesn't get passed off to the SRC. Section 8 of the = current document describes how to pass "metadata", but doesn't really = define what the metadata is.=20 Hope this helps, --Richard From andrew.hutton@siemens-enterprise.com Thu Jun 28 10:34:47 2012 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 45E2821F8504 for ; Thu, 28 Jun 2012 10:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 KsgNXbPwbrLo for ; Thu, 28 Jun 2012 10:34:46 -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 F208621F8458 for ; Thu, 28 Jun 2012 10:34:45 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id D5A041EB85B9; Thu, 28 Jun 2012 19:34:44 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Thu, 28 Jun 2012 19:34:44 +0200 From: "Hutton, Andrew" To: Leon Portman , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] Status of draft-ietf-siprec-architecture Thread-Index: Ac1UuJJJgjyEeWXcT9qC5JANgJDWQgAPH8tgAAKjw4AAATh6AAATi9Hw Date: Thu, 28 Jun 2012 17:34:44 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF03161D@MCHP04MSX.global-ad.net> References: <07465C1D981ABC41A344374066AE1A2C3A8CF73E40@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C3A8CF73FCE@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C3A8CF73FCE@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.251.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Status of draft-ietf-siprec-architecture 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, 28 Jun 2012 17:34:47 -0000 Hi, Personally I think I would prefer Leon's text as I don't believe that speci= fying such a mechanism is really out of scope of the charter it is just tha= t we decided not to do it present.=20 We don't really want to have to update the architecture draft again at some= later date if such a mechanism is defined do we? Regards Andy > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 28 June 2012 06:04 > To: Ram Mohan R (rmohanr); Hutton, Andrew; siprec@ietf.org > Subject: RE: [siprec] Status of draft-ietf-siprec-architecture >=20 > Also good option >=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Thursday, June 28, 2012 12:29 PM > To: Leon Portman; Hutton, Andrew; siprec@ietf.org > Subject: Re: [siprec] Status of draft-ietf-siprec-architecture >=20 > My take on this is to say simply that the mechanism to identify a > session is outside the scope of current work. If we start to include > text on some methods to identify a session and leave out other means it > would lead to confusion. >=20 > Regards, > Ram >=20 > > On 28/06/12 11:45 AM, "Leon Portman" wrote: >=20 > >May be something like this: > > > >" Identify the session that is to be recorded. The actual mechanism > of > >the identification can be dependent on SRC policy or be defined by > >future SIPREC extensions" > > > >Leon > > > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >Behalf Of Hutton, Andrew > >Sent: Thursday, June 28, 2012 2:00 AM > >To: siprec@ietf.org > >Subject: [siprec] Status of draft-ietf-siprec-architecture > > > >Hi All, > > > >Following the previous WGLC and the resulting update to > >draft-ietf-siprec-architecture I believe that only one issue has been > >raised on the list. > > > >This was raised by Partha and related to the text in section 3.2.2 > >which provides an overview of the procedures relating to SRS initiated > >recording. One of the bullets currently states: > > > >"Identify the session that is to be recorded. The actual mechanism of > >the identification depends on SRC policy". > > > >As I understand it the issue with this is that it appears to close the > >door to any future protocol extensions for identifying the > >communication session to be recorded in this SRS initiated case. I > >think Partha would prefer wording that leaves open the possibility of > >creating a new SIPREC related draft that defines such a mechanism. > > > >Any comments, views or suggested text? > > > >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 > > >=20 From rmohanr@cisco.com Thu Jun 28 19:55:50 2012 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 4889E11E8116 for ; Thu, 28 Jun 2012 19:55:50 -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 vSZg1Qvo30d7 for ; Thu, 28 Jun 2012 19:55:49 -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 11FC911E8085 for ; Thu, 28 Jun 2012 19:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3202; q=dns/txt; s=iport; t=1340938549; x=1342148149; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=47+HtjruvcaLSIZk9if7SKTf8oQm5jVIcDIOZtTuQZY=; b=NzsJwynG4HY6RIWT7G86jSI11SnkznMnSeDwgcqkRV8AVsxbwkMTlNA/ /jyem0swYlkF+3ictmpYHdbv2MwVhChcKs8iEFws7m4QEhqPiH5An8SnL H4bihxe4YncMhT35BrlW8dnoemYwrsDGybgpIl/pca3KnnYCPrIxE6zpy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAIZ7U+tJXG+/2dsb2JhbAA7CrZBgQeCGAEBAQQBAQEPASc0FwYBCBEBAwEBAR4JLgsUAwYIAgQBEiKHaQuYNqBXBIs3EIV6A5Uyjh2BZoJf X-IronPort-AV: E=Sophos;i="4.77,495,1336348800"; d="scan'208";a="97130631" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jun 2012 02:55:46 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5T2tj44019857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Jun 2012 02:55:45 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 21:55:45 -0500 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , Leon Portman , "siprec@ietf.org" Thread-Topic: [siprec] Status of draft-ietf-siprec-architecture Thread-Index: AQHNVaKtfIfsNoUcpk2IpuJVDXOJgA== Date: Fri, 29 Jun 2012 02:55:44 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF03161D@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: [173.39.68.75] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19004.001 x-tm-as-result: No--43.174900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Status of draft-ietf-siprec-architecture 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, 29 Jun 2012 02:55:50 -0000 Sounds fine to me Andy. Ram > On 28/06/12 11:04 PM, "Hutton, Andrew" > wrote: >Hi, > >Personally I think I would prefer Leon's text as I don't believe that >specifying such a mechanism is really out of scope of the charter it is >just that we decided not to do it present. > >We don't really want to have to update the architecture draft again at >some later date if such a mechanism is defined do we? > >Regards >Andy > > >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> Sent: 28 June 2012 06:04 >> To: Ram Mohan R (rmohanr); Hutton, Andrew; siprec@ietf.org >> Subject: RE: [siprec] Status of draft-ietf-siprec-architecture >>=20 >> Also good option >>=20 >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: Thursday, June 28, 2012 12:29 PM >> To: Leon Portman; Hutton, Andrew; siprec@ietf.org >> Subject: Re: [siprec] Status of draft-ietf-siprec-architecture >>=20 >> My take on this is to say simply that the mechanism to identify a >> session is outside the scope of current work. If we start to include >> text on some methods to identify a session and leave out other means it >> would lead to confusion. >>=20 >> Regards, >> Ram >>=20 >> > On 28/06/12 11:45 AM, "Leon Portman" wrote: >>=20 >> >May be something like this: >> > >> >" Identify the session that is to be recorded. The actual mechanism >> of >> >the identification can be dependent on SRC policy or be defined by >> >future SIPREC extensions" >> > >> >Leon >> > >> >-----Original Message----- >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >Behalf Of Hutton, Andrew >> >Sent: Thursday, June 28, 2012 2:00 AM >> >To: siprec@ietf.org >> >Subject: [siprec] Status of draft-ietf-siprec-architecture >> > >> >Hi All, >> > >> >Following the previous WGLC and the resulting update to >> >draft-ietf-siprec-architecture I believe that only one issue has been >> >raised on the list. >> > >> >This was raised by Partha and related to the text in section 3.2.2 >> >which provides an overview of the procedures relating to SRS initiated >> >recording. One of the bullets currently states: >> > >> >"Identify the session that is to be recorded. The actual mechanism of >> >the identification depends on SRC policy". >> > >> >As I understand it the issue with this is that it appears to close the >> >door to any future protocol extensions for identifying the >> >communication session to be recorded in this SRS initiated case. I >> >think Partha would prefer wording that leaves open the possibility of >> >creating a new SIPREC related draft that defines such a mechanism. >> > >> >Any comments, views or suggested text? >> > >> >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 >> > >>=20 > >