From henry.lum@genesyslab.com Wed Apr 17 21:15:15 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE97A21E80B4 for ; Wed, 17 Apr 2013 21:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEYNk-WsahjD for ; Wed, 17 Apr 2013 21:15:13 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id BAB0C21E809B for ; Wed, 17 Apr 2013 21:15:10 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service107-us.mimecast.com; Thu, 18 Apr 2013 00:15:09 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 21:15:06 -0700 From: Henry Lum To: "siprec@ietf.org" Thread-Topic: CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUQ== Date: Thu, 18 Apr 2013 04:15:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.212.200.234] Content-ID: <53429D1E89236F4D8781311F6D600294@genesyslab.com> MIME-Version: 1.0 X-MC-Unique: 113041800150900301 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: [siprec] CS hold/resume clarification in protocol draft 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, 18 Apr 2013 04:15:15 -0000 Following up on the clarification in the protocol draft, I propose to re-wo= rd the last paragraph in section 7.1.1.1. I removed mentions on the word mu= te/unmute: The SRC can temporarily discontinue streaming and collection of recorded media from the SRC to the SRS for reason such as masking the recording. In this case, the SRC sends a new SDP offer and sets the media stream to inactive (a=3Dinactive) for each recorded stream to be paused, as per the procedures in [RFC3264]. To resume streaming and collection of recorded media, the SRC sends a new SDP offer and sets the media streams with a=3Dsendonly attribute. Note that a CS itself may change the media stream direction by updating the SDP, for example, by setting a=3Dinactive for SDP hold. Media stream direction changes in CS are conveyed in the metadata by the SRC. The SRC SHOULD NOT modify the media stream in the RS to convey media stream direction changes in the CS, as media stream direction changes in the RS are reserved for pausing and resuming the recorded media. Thanks Henry From MSmith@dss-corp.com Fri Apr 19 14:32:58 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AA521F9530 for ; Fri, 19 Apr 2013 14:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOJmcFV+c0hz for ; Fri, 19 Apr 2013 14:32:58 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 445F221F92C0 for ; Fri, 19 Apr 2013 14:32:58 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id he6sls0171sn for ; Fri, 19 Apr 2013 17:38:34 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Fri, 19 Apr 2013 17:38:34 -0400 Received: from EXC01.dss.lan ([fe80::6540:2e8d:f781:8389]) by exc01.dss.lan ([fe80::6540:2e8d:f781:8389%16]) with mapi; Fri, 19 Apr 2013 17:32:54 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: Does siprec support recording of MSRP sessions? Thread-Index: Ac49RWChiVXD93mWQx6Y06HT8bQkfA== Date: Fri, 19 Apr 2013 21:32:22 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880DC02F6D68@exc01.dss.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_05D56509F27CCE4DAF8136C02386880DC02F6D68exc01dsslan_" MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201304192138340061312 Subject: [siprec] Does siprec support recording of MSRP sessions? 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, 19 Apr 2013 21:32:59 -0000 --_000_05D56509F27CCE4DAF8136C02386880DC02F6D68exc01dsslan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NENA is planning an interoperability testing event in the fall that will in= clude testing of siprec recording. We may have MSRP sessions that we want t= o record. Is there any reason we couldn't use the siprec protocol to record= these? If so, what would the issue(s) be? Michael Smith NENA ICE 8 Planning Committee chair --_000_05D56509F27CCE4DAF8136C02386880DC02F6D68exc01dsslan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

NENA is planning= an interoperability testing event in the fall that will include testing of= siprec recording. We may have MSRP sessions that we want to record. Is the= re any reason we couldn’t use the siprec protocol to record these? If= so, what would the issue(s) be?

&n= bsp;

Michael Smith

NENA ICE 8 Planning Committee chair<= o:p>

 

= --_000_05D56509F27CCE4DAF8136C02386880DC02F6D68exc01dsslan_-- From partha@parthasarathi.co.in Sun Apr 21 11:39:37 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539F421F8512 for ; Sun, 21 Apr 2013 11:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VACkZL-vxmLp for ; Sun, 21 Apr 2013 11:39:35 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.236]) by ietfa.amsl.com (Postfix) with ESMTP id 75EA321F84F6 for ; Sun, 21 Apr 2013 11:39:35 -0700 (PDT) Received: from userPC (unknown [122.179.32.166]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 49DE53E2568; Sun, 21 Apr 2013 18:39:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1366569574; bh=V/LblJfJUKvM/t4pGfFRXejt9zf2Rp1D6Pc7/bbu174=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=L2s9SPiftIU2vEEBUWqAn/8XhKzlyeeamuk6Wid3RQY2jC+ynjInEJZo7D1tnxnKm FM0u9rohGANrCPJhlpaHGf3RdHJ9CF0+EukusfVTX+TmEeKSI7+MNa8kPqtOU5UwO7 QMtUaI/yAtS84MkmxT5Rl7lLF4/txQlcsBHBQDHM= From: "Parthasarathi R" To: "'Michael Smith'" , References: <05D56509F27CCE4DAF8136C02386880DC02F6D68@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880DC02F6D68@exc01.dss.lan> Date: Mon, 22 Apr 2013 00:09:29 +0530 Message-ID: <000a01ce3ebf$9114d3e0$b33e7ba0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CE3EED.AACD0FE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac49RWChiVXD93mWQx6Y06HT8bQkfABeUlng Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0202.51743266.00E9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Subject: Re: [siprec] Does siprec support recording of MSRP sessions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 18:39:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000B_01CE3EED.AACD0FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael, SIP recording mechanism works for any media type as long as media is negotiated between SRC & SRS. As MSRP is negotiated using SDP offer/answer, the SIPREC framework supports. The separate metadata Stream element will be created for MSRP "m" line. MSRP communication occurs between SRC and SRS which has all the information about CS MSRP communication. I'm not very sure about MSRP message side effects if any. There is a need of more discussion like whether SRC shall act like MSRP relay. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Michael Smith Sent: Saturday, April 20, 2013 3:02 AM To: siprec@ietf.org Subject: [siprec] Does siprec support recording of MSRP sessions? NENA is planning an interoperability testing event in the fall that will include testing of siprec recording. We may have MSRP sessions that we want to record. Is there any reason we couldn't use the siprec protocol to record these? If so, what would the issue(s) be? Michael Smith NENA ICE 8 Planning Committee chair ------=_NextPart_000_000B_01CE3EED.AACD0FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

 

SIP recording = mechanism works for any media type as long as media is negotiated between SRC & SRS. = As MSRP is negotiated using SDP offer/answer, the SIPREC framework = supports. The separate metadata Stream element will be created for MSRP = “m” line.  

 

MSRP communication = occurs between SRC and SRS which has all the information about CS MSRP = communication. I’m not very sure about MSRP message side effects if any. There is a need of = more discussion like whether SRC shall act like MSRP relay.

 

Thanks

Partha =

 

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Michael Smith
Sent: Saturday, April 20, 2013 3:02 AM
To: siprec@ietf.org
Subject: [siprec] Does siprec support recording of MSRP = sessions?

 

NENA is planning an interoperability testing event = in the fall that will include testing of siprec recording. We may have MSRP = sessions that we want to record. Is there any reason we couldn’t use the = siprec protocol to record these? If so, what would the issue(s) = be?

 

Michael Smith

NENA ICE 8 Planning Committee chair

 

------=_NextPart_000_000B_01CE3EED.AACD0FE0-- From andrew.hutton@siemens-enterprise.com Mon Apr 22 01:57:50 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F78C21F8EFC for ; Mon, 22 Apr 2013 01:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUeOkGhsqSgE for ; Mon, 22 Apr 2013 01:57:49 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B1C2321F8F02 for ; Mon, 22 Apr 2013 01:57:48 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id AE58323F041C; Mon, 22 Apr 2013 10:57:47 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Mon, 22 Apr 2013 10:57:47 +0200 From: "Hutton, Andrew" To: Parthasarathi R , 'Michael Smith' , "siprec@ietf.org" Thread-Topic: [siprec] Does siprec support recording of MSRP sessions? Thread-Index: Ac49RWChiVXD93mWQx6Y06HT8bQkfABeUlngAB364cA= Date: Mon, 22 Apr 2013 08:57:46 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0E6BA6F1@MCHP04MSX.global-ad.net> References: <05D56509F27CCE4DAF8136C02386880DC02F6D68@exc01.dss.lan> <000a01ce3ebf$9114d3e0$b33e7ba0$@co.in> In-Reply-To: <000a01ce3ebf$9114d3e0$b33e7ba0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF0E6BA6F1MCHP04MSXglobal_" MIME-Version: 1.0 Subject: Re: [siprec] Does siprec support recording of MSRP sessions? 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, 22 Apr 2013 08:57:50 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF0E6BA6F1MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Although I can see that it might not be hard to add MSRP to SIPREC the curr= ent SIPREC work relates only to RTP based media as stated in the requiremen= ts http://tools.ietf.org/html/rfc6341. There has been so far no real discussion on how MSRP recording would work w= ithin the contact of SIPREC so I agree that more discussion would be needed= as to whether MSRP is within scope of the current SIPREC work and if so on= the technical details and how to document a solution. Regards Andy From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R Sent: 21 April 2013 19:39 To: 'Michael Smith'; siprec@ietf.org Subject: Re: [siprec] Does siprec support recording of MSRP sessions? Michael, SIP recording mechanism works for any media type as long as media is negoti= ated between SRC & SRS. As MSRP is negotiated using SDP offer/answer, the S= IPREC framework supports. The separate metadata Stream element will be crea= ted for MSRP "m" line. MSRP communication occurs between SRC and SRS which has all the information= about CS MSRP communication. I'm not very sure about MSRP message side eff= ects if any. There is a need of more discussion like whether SRC shall act = like MSRP relay. Thanks Partha From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of Michael Smith Sent: Saturday, April 20, 2013 3:02 AM To: siprec@ietf.org Subject: [siprec] Does siprec support recording of MSRP sessions? NENA is planning an interoperability testing event in the fall that will in= clude testing of siprec recording. We may have MSRP sessions that we want t= o record. Is there any reason we couldn't use the siprec protocol to record= these? If so, what would the issue(s) be? Michael Smith NENA ICE 8 Planning Committee chair --_000_9F33F40F6F2CD847824537F3C4E37DDF0E6BA6F1MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Although I can see tha= t it might not be hard to add MSRP to SIPREC the current SIPREC work relate= s only to RTP based media as stated in the requirements http://tools.ietf.org= /html/rfc6341.

 

There has been so far = no real discussion on how MSRP recording would work within the contact of S= IPREC so I agree that more discussion would be needed as to whether MSRP is= within scope of the current SIPREC work and if so on the technical details and how to document a solution.

 

Regards

Andy=

 

 

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R
Sent: 21 April 2013 19:39
To: 'Michael Smith'; siprec@ietf.org
Subject: Re: [siprec] Does siprec support recording of MSRP sessions= ?

 

Michael,

 

SIP recording mechanis= m works for any media type as long as media is negotiated between SRC &= SRS. As MSRP is negotiated using SDP offer/answer, the SIPREC framework su= pports. The separate metadata Stream element will be created for MSRP “m” line.  

 

MSRP communication occ= urs between SRC and SRS which has all the information about CS MSRP communi= cation. I’m not very sure about MSRP message side effects if any. The= re is a need of more discussion like whether SRC shall act like MSRP relay.

 

Thanks

Partha

 

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Michael Smith
Sent: Saturday, April 20, 2013 3:02 AM
To: siprec@ietf.org
Subject: [siprec] Does siprec support recording of MSRP sessions?

 

NENA is planning an interoperability testing event i= n the fall that will include testing of siprec recording. We may have MSRP = sessions that we want to record. Is there any reason we couldn’t use = the siprec protocol to record these? If so, what would the issue(s) be?

 

Michael Smith

NENA ICE 8 Planning Committee chair

 

--_000_9F33F40F6F2CD847824537F3C4E37DDF0E6BA6F1MCHP04MSXglobal_-- From pkyzivat@alum.mit.edu Mon Apr 22 07:49:59 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3269721E8082 for ; Mon, 22 Apr 2013 07:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzByAh2r5LWP for ; Mon, 22 Apr 2013 07:49:58 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4F121E8056 for ; Mon, 22 Apr 2013 07:49:57 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id T0aE1l00E1HzFnQ532pxSq; Mon, 22 Apr 2013 14:49:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id T2pw1l01f3ZTu2S3a2pxTZ; Mon, 22 Apr 2013 14:49:57 +0000 Message-ID: <51754E18.7060205@alum.mit.edu> Date: Mon, 22 Apr 2013 10:50:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: siprec@ietf.org References: <05D56509F27CCE4DAF8136C02386880DC02F6D68@exc01.dss.lan> <000a01ce3ebf$9114d3e0$b33e7ba0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF0E6BA6F1@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0E6BA6F1@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366642197; bh=UUVKPlE4Fps+VDAVNDd34QnfKKqDnlqH4bk2dv4eCo8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k9g/U2ETEgWnPlOajWPEH25mlmr1puTbpPLkUWUByJh8JfkG7CyamP8GCCNyOgAIe olqb5CtwUvNPqRqDtwKCKi7h9eoTQhKhzoSEnOG/TzangLcxLdiymTXDFWpiU9ebS0 Ug6qiUZ/yjnzp/gQJ9bVnjwiPb7ClrWsF5JctFpRAcPCAOhoAF9GJQdvXrgVAp1fTt 05OTdMGdCpVoZM+YxKVmvjIDuP00QJb+BTN73/DhYVog4vVbhq83JCZVbi78pxNeaR ypibgVbZ3dV6JKjByy+gWYpvb0heSDs2SzoCEEw3G+Bj2n2/BnV4QxBz2O1cugWYt6 9AFvbrQvAmOCg== Subject: Re: [siprec] Does siprec support recording of MSRP sessions? 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, 22 Apr 2013 14:49:59 -0000 Andrew beat me to it - I was about to say the same: By analogy it is pretty easy to see how to handle msrp with siprec, but the existing specs don't really include it in scope. Were we to start trying to formally extend siprec to include that, issues would likely arise where there are alternative ways of handling things so that some decisions and clarifications would be required to ensure interoperable implementations. I think it would be reasonable for implementations to experiment with this. Just understand that such experimentation is proprietary until we actually do the work to incorporate it. Thanks, Paul On 4/22/13 4:57 AM, Hutton, Andrew wrote: > Hi, > > Although I can see that it might not be hard to add MSRP to SIPREC the > current SIPREC work relates only to RTP based media as stated in the > requirements http://tools.ietf.org/html/rfc6341. > > There has been so far no real discussion on how MSRP recording would > work within the contact of SIPREC so I agree that more discussion would > be needed as to whether MSRP is within scope of the current SIPREC work > and if so on the technical details and how to document a solution. > > Regards > > Andy > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Parthasarathi R > *Sent:* 21 April 2013 19:39 > *To:* 'Michael Smith'; siprec@ietf.org > *Subject:* Re: [siprec] Does siprec support recording of MSRP sessions? > > Michael, > > SIP recording mechanism works for any media type as long as media is > negotiated between SRC & SRS. As MSRP is negotiated using SDP > offer/answer, the SIPREC framework supports. The separate metadata > Stream element will be created for MSRP “m” line. > > MSRP communication occurs between SRC and SRS which has all the > information about CS MSRP communication. I’m not very sure about MSRP > message side effects if any. There is a need of more discussion like > whether SRC shall act like MSRP relay. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] *On Behalf Of *Michael Smith > *Sent:* Saturday, April 20, 2013 3:02 AM > *To:* siprec@ietf.org > *Subject:* [siprec] Does siprec support recording of MSRP sessions? > > NENA is planning an interoperability testing event in the fall that will > include testing of siprec recording. We may have MSRP sessions that we > want to record. Is there any reason we couldn’t use the siprec protocol > to record these? If so, what would the issue(s) be? > > Michael Smith > > NENA ICE 8 Planning Committee chair > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From henry.lum@genesyslab.com Tue Apr 23 07:55:03 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76E921F8B49 for ; Tue, 23 Apr 2013 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LW3lfxA8IFZ for ; Tue, 23 Apr 2013 07:55:03 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 2157A21F8D8E for ; Tue, 23 Apr 2013 07:55:01 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Tue, 23 Apr 2013 10:54:54 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Tue, 23 Apr 2013 07:54:51 -0700 From: Henry Lum To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Does siprec support recording of MSRP sessions? Thread-Index: Ac49RWChiVXD93mWQx6Y06HT8bQkfABeUlngAB364cAAGzAvAAAjcx2w Date: Tue, 23 Apr 2013 14:54:50 +0000 Message-ID: References: <05D56509F27CCE4DAF8136C02386880DC02F6D68@exc01.dss.lan> <000a01ce3ebf$9114d3e0$b33e7ba0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF0E6BA6F1@MCHP04MSX.global-ad.net> <51754E18.7060205@alum.mit.edu> In-Reply-To: <51754E18.7060205@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.58] MIME-Version: 1.0 X-MC-Unique: 113042310545408701 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [siprec] Does siprec support recording of MSRP sessions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 14:55:04 -0000 I was going to say the same thing too. When RFC6341 was drafted this was pu= rposely left out of scope so that we can focus on RTP media at this point. = It looks like there needs to be an additional draft on top of the protocol = draft to explain additional details for handling MSRP. Similar to MSRP, there is MRCPv2 and mediactrl that negotiates a separate c= hannel using SDP. The difference is that they are control channels, and I w= onder whether SIPREC can apply to control channels. Regards, Henry -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: April-22-13 10:50 AM To: siprec@ietf.org Subject: Re: [siprec] Does siprec support recording of MSRP sessions? Andrew beat me to it - I was about to say the same: By analogy it is pretty easy to see how to handle msrp with siprec, but=20 the existing specs don't really include it in scope. Were we to start=20 trying to formally extend siprec to include that, issues would likely=20 arise where there are alternative ways of handling things so that some=20 decisions and clarifications would be required to ensure interoperable=20 implementations. I think it would be reasonable for implementations to experiment with=20 this. Just understand that such experimentation is proprietary until we=20 actually do the work to incorporate it. =09Thanks, =09Paul On 4/22/13 4:57 AM, Hutton, Andrew wrote: > Hi, > > Although I can see that it might not be hard to add MSRP to SIPREC the > current SIPREC work relates only to RTP based media as stated in the > requirements http://tools.ietf.org/html/rfc6341. > > There has been so far no real discussion on how MSRP recording would > work within the contact of SIPREC so I agree that more discussion would > be needed as to whether MSRP is within scope of the current SIPREC work > and if so on the technical details and how to document a solution. > > Regards > > Andy > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Parthasarathi R > *Sent:* 21 April 2013 19:39 > *To:* 'Michael Smith'; siprec@ietf.org > *Subject:* Re: [siprec] Does siprec support recording of MSRP sessions? > > Michael, > > SIP recording mechanism works for any media type as long as media is > negotiated between SRC & SRS. As MSRP is negotiated using SDP > offer/answer, the SIPREC framework supports. The separate metadata > Stream element will be created for MSRP "m" line. > > MSRP communication occurs between SRC and SRS which has all the > information about CS MSRP communication. I'm not very sure about MSRP > message side effects if any. There is a need of more discussion like > whether SRC shall act like MSRP relay. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] *On Behalf Of *Michael Smith > *Sent:* Saturday, April 20, 2013 3:02 AM > *To:* siprec@ietf.org > *Subject:* [siprec] Does siprec support recording of MSRP sessions? > > NENA is planning an interoperability testing event in the fall that will > include testing of siprec recording. We may have MSRP sessions that we > want to record. Is there any reason we couldn't use the siprec protocol > to record these? If so, what would the issue(s) be? > > Michael Smith > > NENA ICE 8 Planning Committee 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 hammondjohnson@hushmail.com Sat Apr 27 14:57:59 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8510F21F9921 for ; Sat, 27 Apr 2013 14:57:59 -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 ytUNLipKCFqU for ; Sat, 27 Apr 2013 14:57:59 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id E384621F9917 for ; Sat, 27 Apr 2013 14:57:58 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id C8DFC31078 for ; Sat, 27 Apr 2013 17:49:12 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:49:12 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 83105E6739; Sat, 27 Apr 2013 17:49:12 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:49:12 -0400 To: siprec@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174912.83105E6739@smtp.hushmail.com> Subject: [siprec] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 21:57:59 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From andrew.hutton@siemens-enterprise.com Tue Apr 30 06:19:16 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF0F21F9C02 for ; Tue, 30 Apr 2013 06:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRIny5jHT+IF for ; Tue, 30 Apr 2013 06:19:12 -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 EAF9D21F9BFC for ; Tue, 30 Apr 2013 06:19:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E960F1EB85EF; Tue, 30 Apr 2013 15:19:09 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.165]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Tue, 30 Apr 2013 15:19:09 +0200 From: "Hutton, Andrew" To: Henry Lum , "siprec@ietf.org" Thread-Topic: CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdA Date: Tue, 30 Apr 2013 13:19:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0E6D475C@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] CS hold/resume clarification in protocol draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 13:19:16 -0000 Hi Henry, Only question I have is whether the "SHOULD NOT" in the following text coul= d be a "MUST NOT" "The SRC SHOULD NOT modify the media stream in the RS to convey media strea= m direction changes in the CS" What does everybody think? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > Sent: 18 April 2013 05:15 > To: siprec@ietf.org > Subject: [siprec] CS hold/resume clarification in protocol draft >=20 > Following up on the clarification in the protocol draft, I propose to > re-word the last paragraph in section 7.1.1.1. I removed mentions on > the word mute/unmute: >=20 >=20 >=20 > The SRC can temporarily discontinue streaming and collection of > recorded media from the SRC to the SRS for reason such as masking > the > recording. In this case, the SRC sends a new SDP offer and sets the >=20 > media stream to inactive (a=3Dinactive) for each recorded stream to be > paused, as per the procedures in > [RFC3264]. To resume streaming and > collection of recorded media, the SRC sends a new SDP offer and sets > the media streams with a=3Dsendonly attribute. >=20 >=20 > Note that a CS itself may change the media stream direction by > updating >=20 > the SDP, for example, by setting a=3Dinactive for SDP hold. Media > stream >=20 > direction changes in CS are conveyed in the metadata by the SRC. The > SRC >=20 > SHOULD NOT modify the media stream in the RS to convey media stream >=20 > direction changes in the CS, as media stream direction changes in > the RS >=20 > are reserved for pausing and resuming the recorded media. >=20 >=20 >=20 > Thanks >=20 > Henry >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From alan.b.johnston@gmail.com Tue Apr 30 08:00:16 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3D021F9BE7 for ; Tue, 30 Apr 2013 08:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, MIME_QP_LONG_LINE=1.396, 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 QEUs5EPSKy1n for ; Tue, 30 Apr 2013 08:00:16 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0093D21F9BC5 for ; Tue, 30 Apr 2013 08:00:15 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id 9so719824iec.22 for ; Tue, 30 Apr 2013 08:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:x-mailer:from:subject:date :to; bh=BJ4IJuu/NrJwRL2iwrhIHG0MKs5ZTmMVcqBJ3XVFuWc=; b=g9q+qfdFwImkfUAFlcQArposY41Y45dPYTMe4LkTDgVB1I2mKRUZ7iWynQhQhJQDn5 RdK9zt26u6k6QM4TSvHZWMaZsRrdb/qgST6Sc/f1uHcydcIMuQBstH82q/va746XOg0q rPMBvnh64vC6NY28JD7485nbTOXAdu6Zw/V14ebOYgulWlnTPRE/ABZhQzFOJmQMbULt /216fBaxKp8RMr05KnvIkl19tfQUnYhiQ9HG72s+wKg31MNGKX0tjTRpS5nIl6D/XguG /PVZMaeT3socSs6dwt1/6p7DHzf1ldges8XokCDl4XwyW3VYsEI+TmYQ9OQfaQHKcaNC dxuw== X-Received: by 10.50.103.102 with SMTP id fv6mr10418707igb.6.1367334015592; Tue, 30 Apr 2013 08:00:15 -0700 (PDT) Received: from [10.157.37.217] ([166.147.97.238]) by mx.google.com with ESMTPSA id wn10sm22900009igb.2.2013.04.30.08.00.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Apr 2013 08:00:14 -0700 (PDT) References: <9F33F40F6F2CD847824537F3C4E37DDF0E6D475C@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0E6D475C@MCHP04MSX.global-ad.net> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <7A9C5F04-61EA-425E-B908-40116B29107A@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Alan Johnston Date: Tue, 30 Apr 2013 10:00:11 -0500 To: "Hutton, Andrew" Cc: "siprec@ietf.org" Subject: Re: [siprec] CS hold/resume clarification in protocol draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 15:00:16 -0000 We definitely want to discourage this behavior, but MUSTs relate to interop f= ailures. Is that what we are trying to avoid? Another thought - If an implementer used 1 RS for each CS, would this hold/r= esume behavior be wrong? - Alan - On Apr 30, 2013, at 8:19 AM, "Hutton, Andrew" wrote: > Hi Henry, >=20 > Only question I have is whether the "SHOULD NOT" in the following text cou= ld be a "MUST NOT" >=20 > "The SRC SHOULD NOT modify the media stream in the RS to convey media stre= am direction changes in the CS" >=20 > What does everybody think? >=20 > Regards > Andy >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Henry Lum >> Sent: 18 April 2013 05:15 >> To: siprec@ietf.org >> Subject: [siprec] CS hold/resume clarification in protocol draft >>=20 >> Following up on the clarification in the protocol draft, I propose to >> re-word the last paragraph in section 7.1.1.1. I removed mentions on >> the word mute/unmute: >>=20 >>=20 >>=20 >> The SRC can temporarily discontinue streaming and collection of >> recorded media from the SRC to the SRS for reason such as masking >> the >> recording. In this case, the SRC sends a new SDP offer and sets the >>=20 >> media stream to inactive (a=3Dinactive) for each recorded stream to be >> paused, as per the procedures in >> [RFC3264]. To resume streaming and >> collection of recorded media, the SRC sends a new SDP offer and sets >> the media streams with a=3Dsendonly attribute. >>=20 >>=20 >> Note that a CS itself may change the media stream direction by >> updating >>=20 >> the SDP, for example, by setting a=3Dinactive for SDP hold. Media >> stream >>=20 >> direction changes in CS are conveyed in the metadata by the SRC. The >> SRC >>=20 >> SHOULD NOT modify the media stream in the RS to convey media stream >>=20 >> direction changes in the CS, as media stream direction changes in >> the RS >>=20 >> are reserved for pausing and resuming the recorded media. >>=20 >>=20 >>=20 >> Thanks >>=20 >> Henry >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Apr 30 09:51:34 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A2221F99A2 for ; Tue, 30 Apr 2013 09:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.12 X-Spam-Level: X-Spam-Status: No, score=0.12 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyRcs5AhEuAd for ; Tue, 30 Apr 2013 09:51:29 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 00DF921F99D1 for ; Tue, 30 Apr 2013 09:51:28 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta02.westchester.pa.mail.comcast.net with comcast id WAVz1l0050ldTLk51GrQ4a; Tue, 30 Apr 2013 16:51:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id WGrQ1l00D3ZTu2S3QGrQPv; Tue, 30 Apr 2013 16:51:24 +0000 Message-ID: <517FF68B.6090808@alum.mit.edu> Date: Tue, 30 Apr 2013 12:51:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF0E6D475C@MCHP04MSX.global-ad.net> <7A9C5F04-61EA-425E-B908-40116B29107A@gmail.com> In-Reply-To: <7A9C5F04-61EA-425E-B908-40116B29107A@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367340684; bh=f8y6+27tghIU6lm/SuFfGWHFAMTwDISs4YIhgi22dNQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Vf/vFgE+ifU6F46ksdZngpYIU0gI9dhsKV7tI0VfL0IkRT3QN9SeaJvpPNSYUlMeW S+tdJ4f+cvRGkgjLlU722UFDZ4aVSEdVHW/7iuVIpp1W+RlwBSLuKQZ2Q6fbSC5WUd HgHF/YDT6GIV50VhyUj43X9n4z7rGX4JsZGCyRFju4gpJ/2S91V3j6gqbOP41a4MYT 9qBa6yzMDLE2ZHCxZjgtaVi8HKS/EyaPuC3dioalnp32cYK4z6LZ+75xd50D696UPw yLbNY8P2p0TTA6ydezo/l/yWqI7ldTbA0xX4dX5AVXd6dKY9KwmSnb5BR4tSIViVnE w88S4PWk+sbkA== Subject: Re: [siprec] CS hold/resume clarification in protocol draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 16:51:34 -0000 On 4/30/13 11:00 AM, Alan Johnston wrote: > We definitely want to discourage this behavior, but MUSTs relate to interop failures. Is that what we are trying to avoid? > > Another thought - If an implementer used 1 RS for each CS, would this hold/resume behavior be wrong? Clearly this won't cause an interop failure between the SRC and the SRS. But it can result in the SRS misunderstanding the state - believing that recording has been stopped when it has not. That could lead to problems (maybe legal problems) analyzing recordings. I prefer MUST. This still doesn't prevent the SRC from doing it. But it means that the SRC is deciding that recording should stop when the CS goes on hold. That reflects a different SRC policy. Thanks, Paul > - Alan - > > > > On Apr 30, 2013, at 8:19 AM, "Hutton, Andrew" wrote: > >> Hi Henry, >> >> Only question I have is whether the "SHOULD NOT" in the following text could be a "MUST NOT" >> >> "The SRC SHOULD NOT modify the media stream in the RS to convey media stream direction changes in the CS" >> >> What does everybody think? >> >> Regards >> Andy >> >> >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Henry Lum >>> Sent: 18 April 2013 05:15 >>> To: siprec@ietf.org >>> Subject: [siprec] CS hold/resume clarification in protocol draft >>> >>> Following up on the clarification in the protocol draft, I propose to >>> re-word the last paragraph in section 7.1.1.1. I removed mentions on >>> the word mute/unmute: >>> >>> >>> >>> The SRC can temporarily discontinue streaming and collection of >>> recorded media from the SRC to the SRS for reason such as masking >>> the >>> recording. In this case, the SRC sends a new SDP offer and sets the >>> >>> media stream to inactive (a=inactive) for each recorded stream to be >>> paused, as per the procedures in >>> [RFC3264]. To resume streaming and >>> collection of recorded media, the SRC sends a new SDP offer and sets >>> the media streams with a=sendonly attribute. >>> >>> >>> Note that a CS itself may change the media stream direction by >>> updating >>> >>> the SDP, for example, by setting a=inactive for SDP hold. Media >>> stream >>> >>> direction changes in CS are conveyed in the metadata by the SRC. The >>> SRC >>> >>> SHOULD NOT modify the media stream in the RS to convey media stream >>> >>> direction changes in the CS, as media stream direction changes in >>> the RS >>> >>> are reserved for pausing and resuming the recorded media. >>> >>> >>> >>> Thanks >>> >>> Henry >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From henry.lum@genesyslab.com Tue Apr 30 21:39:59 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C59921F86B9 for ; Tue, 30 Apr 2013 21:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5117KsnWQBGP for ; Tue, 30 Apr 2013 21:39:31 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 315D521F86B8 for ; Tue, 30 Apr 2013 21:39:17 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service108-us.mimecast.com; Wed, 01 May 2013 00:39:12 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Tue, 30 Apr 2013 21:39:09 -0700 From: Henry Lum To: Alan Johnston , "Hutton, Andrew" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgACS/YCAAG94YQ== Date: Wed, 1 May 2013 04:39:08 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF0E6D475C@MCHP04MSX.global-ad.net>, <7A9C5F04-61EA-425E-B908-40116B29107A@gmail.com> In-Reply-To: <7A9C5F04-61EA-425E-B908-40116B29107A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-MC-Unique: 113050100391300102 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "siprec@ietf.org" Subject: Re: [siprec] CS hold/resume clarification in protocol draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Henry Lum List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 04:39:59 -0000 The only interop issue this can cause is an SRS would mistaken a hold as pa= use/resume. Would there be any harm done in this case? It's undesirable but= I dont think it's broken as there should be corresponding metadata to note= the media stream change. Henry -------- Original message -------- From: Alan Johnston Date: 04-30-2013 11:00 AM (GMT-05:00) To: "Hutton, Andrew" Cc: Henry Lum ,siprec@ietf.org Subject: Re: [siprec] CS hold/resume clarification in protocol draft We definitely want to discourage this behavior, but MUSTs relate to interop= failures. Is that what we are trying to avoid? Another thought - If an implementer used 1 RS for each CS, would this hold/= resume behavior be wrong? - Alan - On Apr 30, 2013, at 8:19 AM, "Hutton, Andrew" wrote: > Hi Henry, > > Only question I have is whether the "SHOULD NOT" in the following text co= uld be a "MUST NOT" > > "The SRC SHOULD NOT modify the media stream in the RS to convey media str= eam direction changes in the CS" > > What does everybody think? > > Regards > Andy > > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Henry Lum >> Sent: 18 April 2013 05:15 >> To: siprec@ietf.org >> Subject: [siprec] CS hold/resume clarification in protocol draft >> >> Following up on the clarification in the protocol draft, I propose to >> re-word the last paragraph in section 7.1.1.1. I removed mentions on >> the word mute/unmute: >> >> >> >> The SRC can temporarily discontinue streaming and collection of >> recorded media from the SRC to the SRS for reason such as masking >> the >> recording. In this case, the SRC sends a new SDP offer and sets the >> >> media stream to inactive (a=3Dinactive) for each recorded stream to be >> paused, as per the procedures in >> [RFC3264]. To resume streaming and >> collection of recorded media, the SRC sends a new SDP offer and sets >> the media streams with a=3Dsendonly attribute. >> >> >> Note that a CS itself may change the media stream direction by >> updating >> >> the SDP, for example, by setting a=3Dinactive for SDP hold. Media >> stream >> >> direction changes in CS are conveyed in the metadata by the SRC. The >> SRC >> >> SHOULD NOT modify the media stream in the RS to convey media stream >> >> direction changes in the CS, as media stream direction changes in >> the RS >> >> are reserved for pausing and resuming the recorded media. >> >> >> >> Thanks >> >> Henry >> >> _______________________________________________ >> 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