From andrew.hutton@siemens-enterprise.com Wed May 1 00:40:19 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF5D21F8E4B for ; Wed, 1 May 2013 00:40:19 -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 7i3-qRvAgBi1 for ; Wed, 1 May 2013 00:40:15 -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 3391121F8E46 for ; Wed, 1 May 2013 00:40:15 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A309A1EB85BA; Wed, 1 May 2013 09:40:13 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.165]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Wed, 1 May 2013 09:40:13 +0200 From: "Hutton, Andrew" To: Henry Lum , Alan Johnston Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgACS/YCAAG94YYAAMcNQ Date: Wed, 1 May 2013 07:40:11 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0E6D5B5E@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF0E6D475C@MCHP04MSX.global-ad.net>, <7A9C5F04-61EA-425E-B908-40116B29107A@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] 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: Wed, 01 May 2013 07:40:19 -0000 My view is that this is enough of an issue to make it a MUST as you say the= fact that this would result in a misunderstanding and therefore probably a= trouble ticket being raised against the implementation is reason enough. Andy > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@genesyslab.com] > Sent: 01 May 2013 05:39 > To: Alan Johnston; Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] CS hold/resume clarification in protocol draft >=20 > The only interop issue this can cause is an SRS would mistaken a hold > as pause/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. >=20 > Henry >=20 >=20 > -------- 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 >=20 >=20 > We definitely want to discourage this behavior, but MUSTs relate to > interop failures. Is that what we are trying to avoid? >=20 > Another thought - If an implementer used 1 RS for each CS, would this > hold/resume behavior be wrong? >=20 > - Alan - >=20 >=20 >=20 > On Apr 30, 2013, at 8:19 AM, "Hutton, Andrew" enterprise.com> wrote: >=20 > > 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=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 From rmohanr@cisco.com Wed May 1 20:21:12 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176BA21F9A68 for ; Wed, 1 May 2013 20:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQmwW2NS09rb for ; Wed, 1 May 2013 20:21:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2E91C21F9A43 for ; Wed, 1 May 2013 20:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5212; q=dns/txt; s=iport; t=1367464863; x=1368674463; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=jqeM9/DBoiTw29DkYfCgm3+vJRSMGsqereAdG5Q2nI4=; b=MGewVHVrHEsSpX7LXHJ1b/vSbRh5qmiO5wm+lnizBHi7tsvSUBbrEluY ATOZOvR4HbiYS/ae1vV00zhfeNHQasKzunZAz1s/YnpG2+SuIZK6qVePm cTWwacF7vrPK6/Zr2i+bpwnbT4li34GFObFtpCM6L8CRHZjNBX6Upjm23 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsGAFvagVGtJV2b/2dsb2JhbABSgwc3vyOBARZtB4IfAQEBAwEBAQE3NBAHBgEIEQMBAQEBChQJKAYLFAkIAgQTCIdyAwkGDKAKlyUNh3SMS4EvdwYyBoJrYQOVRYMKimqFIYMNgWkkGg X-IronPort-AV: E=Sophos;i="4.87,593,1363132800"; d="scan'208";a="205453199" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 02 May 2013 03:21:02 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r423L2aU004153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 May 2013 03:21:02 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.179]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 1 May 2013 22:21:02 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHORuQSvGbPo5f/lEekek4xx6fzmA== Date: Thu, 2 May 2013 03:21:01 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0E6D5B5E@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.3.2.130206 x-originating-ip: [72.163.212.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DF7D1B6B6A3B84EB26E59C75328F97F@emea.cisco.com> 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: Thu, 02 May 2013 03:21:12 -0000 A question here: In the current metadata draft to indicate CS hold/resume from SRC to SRS we re-use the SIP/SDP semantics and indicate the same with a=3Dinactive/a=3Dsendonly respectively. In the below discussion, I see we want to give a special meaning for a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS hold / resume cannot be indicated using SDP semantics from SRC to SRS as the SRS cannot differentiate between CS hold/resume and Recording stop/resume if we use the same semantics for both. The current metadata XML draft does not have any means to indicate CS hold/resume in XML. The general approach followed in the metadata (as a result of past feedback received) is to re-use SIP/SDP semantics wherever possible to represent metadata attributes and have XML representation for only those attributes that does not have a semantics in SIP/SDP to represent. And hence the current draft re-uses SDP semantics to represent CS HOLD/RESUME. I want to hear feedback on - if the WG wants CSC hold/resume to be represented in XML ? =20 Ram > On 01/05/13 1:10 PM, "Hutton, Andrew" > wrote: >My view is that this is enough of an issue to make it a MUST as you say >the fact that this would result in a misunderstanding and therefore >probably a trouble ticket being raised against the implementation is >reason enough. > >Andy > > > >> -----Original Message----- >> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] >> Sent: 01 May 2013 05:39 >> To: Alan Johnston; Hutton, Andrew >> Cc: siprec@ietf.org >> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>=20 >> The only interop issue this can cause is an SRS would mistaken a hold >> as pause/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. >>=20 >> Henry >>=20 >>=20 >> -------- 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 >>=20 >>=20 >> We definitely want to discourage this behavior, but MUSTs relate to >> interop failures. Is that what we are trying to avoid? >>=20 >> Another thought - If an implementer used 1 RS for each CS, would this >> hold/resume behavior be wrong? >>=20 >> - Alan - >>=20 >>=20 >>=20 >> On Apr 30, 2013, at 8:19 AM, "Hutton, Andrew" > enterprise.com> wrote: >>=20 >> > 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=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 > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From DAVE.HIGTON@nice.com Thu May 2 00:17:05 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F7521F993F for ; Thu, 2 May 2013 00:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 M738FwWPrc1J for ; Thu, 2 May 2013 00:17:01 -0700 (PDT) Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0350021F993C for ; Thu, 2 May 2013 00:17:00 -0700 (PDT) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Thu, 2 May 2013 08:16:58 +0100 Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 May 2013 08:16:58 +0100 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Thu, 2 May 2013 08:16:57 +0100 From: "Dave Higton" Content-Transfer-Encoding: 7bit To: Date: Thu, 2 May 2013 08:16:56 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Topic: Bad news on the patents front Thread-Index: Ac5HBQSVbekAqgtuTQKhv3IOXUFheA== Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B6940561E790E3@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9B0B6FB9606F4D4AB133C5E9A203B6940561E790E3SOUEXC01eunic_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 May 2013 07:16:58.0309 (UTC) FILETIME=[087C3750:01CE4705] Subject: [siprec] Bad news on the patents front 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, 02 May 2013 07:17:05 -0000 This is a multi-part message in MIME format. --_000_9B0B6FB9606F4D4AB133C5E9A203B6940561E790E3SOUEXC01eunic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Widely reported: http://yro.slashdot.org/story/13/05/01/1353231/british-telecom-claims-pat= ents-on-voip-session-initiation-protocol http://www.theregister.co.uk/2013/04/30/bt_trolling_sip_in_battle_with_go= ogle/ Dave NICE Systems UK Limited ("NICE") is registered in England under company = number, 3403044. The registered office of NICE is at Tollbar Way, Hedge = End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for = the above-named persons only and may be confidential and/or legally = privileged. Any opinions expressed in this communication are not = necessarily those of NICE. If this communication has come to you in = error you must take no action based on it, nor must you copy or show it = to anyone; please delete/destroy and inform the sender by e-mail = immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail = and attachments are free from any virus, we advise that in keeping with = good computing practice the recipient should ensure they are actually = virus free. --_000_9B0B6FB9606F4D4AB133C5E9A203B6940561E790E3SOUEXC01eunic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Widely reported:

 

http://yro.slashdot.org/story/13/05/01/1353231/british-= telecom-claims-patents-on-voip-session-initiation-protocol

=

http://www.theregister.co.uk/2013/04/30/bt_trolling_sip= _in_battle_with_google/

 

Dave

 



NICE Systems UK Limited ("NICE") is = registered in England under company number, 3403044. The registered = office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 = 2ZP.

Confidentiality: This communication and any = attachments are intended for the above-named persons only and may be = confidential and/or legally privileged. Any opinions expressed in this = communication are not necessarily those of NICE. If this communication = has come to you in error you must take no action based on it, nor must = you copy or show it to anyone; please delete/destroy and inform the = sender by e-mail immediately.

Monitoring: NICE may monitor = incoming and outgoing e-mails.
Viruses: Although we have taken steps = toward ensuring that this e-mail and attachments are free from any = virus, we advise that in keeping with good computing practice the = recipient should ensure they are actually virus = free. 

 --_000_9B0B6FB9606F4D4AB133C5E9A203B6940561E790E3SOUEXC01eunic_-- From rmohanr@cisco.com Thu May 2 01:03:09 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 AFA9E21F8E5D for ; Thu, 2 May 2013 01:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGO1IKNycQWf for ; Thu, 2 May 2013 01:02:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 636A321F859D for ; Thu, 2 May 2013 01:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=369; q=dns/txt; s=iport; t=1367481769; x=1368691369; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Op8I7OswzAxDCpDIZtek0yFUnCuuGo4p/mRPdC8u7kY=; b=mNfKXVs5RvTiDUgUYqM9pfTUqppeFg0PGijQV5DtXuvDs7eIDVPj2cb7 EAW2vXa53FaU+ICcl50M8M0HctPzVEqp52W7jZzHJYFuxU8arnrTyiWmV Nhk4CLIN+rFM2aFW6jT1EGpippQFNp/cexCx1KjSy66V1QwcS7lmCR2E9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOMcglGtJV2Z/2dsb2JhbABSgwc3vyWBAxZ0gh8BAQEDAToaKg0BCCIUQiUCBAESCBKHbAYMv0COcTiCcWEDqFqDDYIn X-IronPort-AV: E=Sophos;i="4.87,595,1363132800"; d="scan'208";a="205527704" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 02 May 2013 08:02:49 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4282mYK021211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 08:02:48 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.179]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 2 May 2013 03:02:48 -0500 From: "Ram Mohan R (rmohanr)" To: Dave Higton , "siprec@ietf.org" Thread-Topic: [siprec] Bad news on the patents front Thread-Index: AQHORwtvKMwvF0ZYkEmQsvWc65NTMg== Date: Thu, 2 May 2013 08:02:47 +0000 Message-ID: In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940561E790E3@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.212.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <181AEAFA3959B44D8B5E74F77D2A6EF2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Bad news on the patents front 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, 02 May 2013 08:03:10 -0000 > On 02/05/13 12:46 PM, "Dave Higton" wrote: >Widely reported: >=20 >http://yro.slashdot.org/story/13/05/01/1353231/british-telecom-claims-pate >nts-on-voip-session-initiation-protocol >http://www.theregister.co.uk/2013/04/30/bt_trolling_sip_in_battle_with_goo >gle/ >=20 >Dave Strange after so many years of SIP deployment. Ram From pkyzivat@alum.mit.edu Thu May 2 07:31:49 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC63821F8B13 for ; Thu, 2 May 2013 07:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=0.185, 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 J-IFzKtYx6xE for ; Thu, 2 May 2013 07:31:45 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6B121F8A0C for ; Thu, 2 May 2013 07:31:45 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id Wz3r1l0071ap0As552Xg7c; Thu, 02 May 2013 14:31:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id X2Xg1l00C3ZTu2S3i2Xgej; Thu, 02 May 2013 14:31:40 +0000 Message-ID: <518278CB.70507@alum.mit.edu> Date: Thu, 02 May 2013 10:31:39 -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: <9B0B6FB9606F4D4AB133C5E9A203B6940561E790E3@SOUEXC01.eu.nice.com> In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940561E790E3@SOUEXC01.eu.nice.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=1367505100; bh=e0+X1/w3x6iA8HvySowCrrVDF53CZ/QqjiBzBdusodc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XV7U4JYArP3gp7bW/ZtNnxQRpnDR/uGkHMckWuoP4GJP/tOISixxY5Ztz2Wa3IC0a PsHlhiy2/Vwpxm6kV0UaRV2Z8YlSOI8GSEgkQFBtyrWMKH6YGGkFRBxQTQbKtdcx2h q0JqX2HXW+pLvTTltQyREqcsH5/ACYVbyGAPs1ks60CwCjSsDvsMoI7SUom6H7T63D r/q8ubg9DkgPDSd4YCRzYYKbqBjGDmQIp2kHTMSR3OrCkj2KKiTvlZ7ayc2C9j8TOc zeNiYQy2z/p/QyOPujxT4LLlnnPvI/pPKm8rFzIAeARdSma6ncHyPtA58koUT9KyG4 /RS5sJhrlc0QQ== Subject: Re: [siprec] Bad news on the patents front 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, 02 May 2013 14:31:50 -0000 I don't know much about this, but AFAIK this isn't specifically about siprec - it is broader. So its not something we should be worrying about in siprec. Thanks, Paul On 5/2/13 3:16 AM, Dave Higton wrote: > Widely reported: > > http://yro.slashdot.org/story/13/05/01/1353231/british-telecom-claims-patents-on-voip-session-initiation-protocol > > http://www.theregister.co.uk/2013/04/30/bt_trolling_sip_in_battle_with_google/ > > Dave > > > > NICE Systems UK Limited ("NICE") is registered in England under company > number, 3403044. The registered office of NICE is at Tollbar Way, Hedge > End, Southampton, Hampshire SO30 2ZP. > > Confidentiality: This communication and any attachments are intended for > the above-named persons only and may be confidential and/or legally > privileged. Any opinions expressed in this communication are not > necessarily those of NICE. If this communication has come to you in > error you must take no action based on it, nor must you copy or show it > to anyone; please delete/destroy and inform the sender by e-mail > immediately. > > Monitoring: NICE may monitor incoming and outgoing e-mails. > Viruses: Although we have taken steps toward ensuring that this e-mail > and attachments are free from any virus, we advise that in keeping with > good computing practice the recipient should ensure they are actually > virus free. > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Thu May 2 07:34:16 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FAA21F8BBC for ; Thu, 2 May 2013 07:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.171, 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 tftzLH8rGsvb for ; Thu, 2 May 2013 07:34:12 -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 EAFC421F8B8F for ; Thu, 2 May 2013 07:34:11 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta02.westchester.pa.mail.comcast.net with comcast id X09k1l00B0cZkys512aBLn; Thu, 02 May 2013 14:34:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id X2aB1l00B3ZTu2S3W2aBS6; Thu, 02 May 2013 14:34:11 +0000 Message-ID: <51827963.3030904@alum.mit.edu> Date: Thu, 02 May 2013 10:34:11 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367505251; bh=Go5HijPaB4gJNtpmEY2ehA52ZltN3/V0BSp4ue0QURE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Rv1RliknebhYNVkL8kjwyaeTAtugI6fwu+xnCehyJBVRZwIo6BzdLRfrMDGD0ajt2 Cu3zhyMCsg77eaAu+uyB0V9R5qenWSzIoVyYEG6tMzYlqiq0XlAxSi6/NLgIilBF9N dBzwqCuWAv9OVjQS3tcokJwvq+qG7YsyvDUA3Nr8rqQm6iG9iO4McSQeijWrCHl6vY LoXWpwofJYYXMqyT+yJ95RSvvICKndkkM7gQ60/Elfpmd8YiXcIj5wNihyRqOr3ckI U6mAdvGDmEJILTxKnGx9M+XuOg52LEnCH9tWOwK/XXe3R67MKJZKLOFHySpmH42zGM gtEByY+H4xexw== Subject: Re: [siprec] Bad news on the patents front 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, 02 May 2013 14:34:16 -0000 Just because somebody is trying to assert patents doesn't mean they are valid. We need to leave this to the lawyers. Thanks, Paul On 5/2/13 4:02 AM, Ram Mohan R (rmohanr) wrote: >> On 02/05/13 12:46 PM, "Dave Higton" wrote: > >> Widely reported: >> >> http://yro.slashdot.org/story/13/05/01/1353231/british-telecom-claims-pate >> nts-on-voip-session-initiation-protocol >> http://www.theregister.co.uk/2013/04/30/bt_trolling_sip_in_battle_with_goo >> gle/ >> >> Dave > > Strange after so many years of SIP deployment. > > Ram > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From mary.ietf.barnes@gmail.com Thu May 2 08:07: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 5F24221F8EC1 for ; Thu, 2 May 2013 08:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBCv8wW93UFF for ; Thu, 2 May 2013 08:07:57 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id A037421F8EBF for ; Thu, 2 May 2013 08:07:57 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id hg5so353922qab.11 for ; Thu, 02 May 2013 08:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ecilaLUoKxK5x9O4LzEpnZOcN2crztU0Z4iDEJ95PdA=; b=Ordr1xOxQXYxq8asBfdUFnMXhtk/3/KkaR6FYXeeCiPACrSFGM2qAuE5efrZKgSKmb POvoGGY/wr2ZvaMuQF3MK34HiZp9qnaq5miK8eklK+W1mo5UCKRf4164CsnVFKYij/Lc NFlOkQ9oFxJ/fzgrrWA6Ab55AVp51I8trMGlU9EZ0mINMfQr25nEVHhMWtqBghnUq7gz MwZ/7SPIeFYQOf+AAnKT0icwxlQq0p/SweprwLn/cIMXw8tvdgnnKEJGTSZqRPe9uwM4 QRTgy51TArxW4DiqwI4l4TVyH7MgvBph0F0wAUbDlG1xatJ3vA9LIwxscvKZoVGZz+sa BGpg== MIME-Version: 1.0 X-Received: by 10.224.147.83 with SMTP id k19mr8342030qav.72.1367507277033; Thu, 02 May 2013 08:07:57 -0700 (PDT) Received: by 10.49.117.163 with HTTP; Thu, 2 May 2013 08:07:56 -0700 (PDT) In-Reply-To: <51827963.3030904@alum.mit.edu> References: <51827963.3030904@alum.mit.edu> Date: Thu, 2 May 2013 10:07:56 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: "siprec@ietf.org" Subject: Re: [siprec] Bad news on the patents front 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, 02 May 2013 15:07:58 -0000 On Thu, May 2, 2013 at 9:34 AM, Paul Kyzivat wrote: > Just because somebody is trying to assert patents doesn't mean they are > valid. We need to leave this to the lawyers. [MB] Exactly. I do find it curious that while BT folks have been involved on the SIP related mailing lists in the past that there have been no declarations made with regards to any of this - at least that I could find in the IETF IPR database. [/MB] > > Thanks, > Paul > > > On 5/2/13 4:02 AM, Ram Mohan R (rmohanr) wrote: >>> >>> On 02/05/13 12:46 PM, "Dave Higton" wrote: >> >> >>> Widely reported: >>> >>> >>> http://yro.slashdot.org/story/13/05/01/1353231/british-telecom-claims-pate >>> nts-on-voip-session-initiation-protocol >>> >>> http://www.theregister.co.uk/2013/04/30/bt_trolling_sip_in_battle_with_goo >>> gle/ >>> >>> Dave >> >> >> Strange after so many years of SIP deployment. >> >> Ram >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Thu May 2 10:07:55 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF04421F8F67 for ; Thu, 2 May 2013 10:07:55 -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 MACa8qm4wr53 for ; Thu, 2 May 2013 10:07:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2E30D21F8F0F for ; Thu, 2 May 2013 10:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1358; q=dns/txt; s=iport; t=1367514470; x=1368724070; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=r4FJJ1so906SgahoVNt5wApfwR6UPRGAcAYkZbRZDIQ=; b=Q/V1vRj1fWwX+fFhS5bNjGTyANkPYQx9KeDeWWn0Fzg3pCnrxvZOZgq3 n6QDvlFk1I65KSdEnNdirvXjKBAGQ9ydFfUJA+ojgNi2GZ6raiVYb6dxF 9v9t82y/hH80G0HqW+m+41aPh10e1n2fwCVN20yDKkJmQOgins5AGoAJt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYHAG2cglGtJXG8/2dsb2JhbABSgwe+WIEHfxZtB4IhAQQ6UQEqFEInBBuIBKFnn06OdYMqYQOoXYMNgic X-IronPort-AV: E=Sophos;i="4.87,597,1363132800"; d="scan'208";a="205734757" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 02 May 2013 17:07:49 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r42H7nHm002134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 May 2013 17:07:49 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.179]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 2 May 2013 12:07:49 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: Reason header representation in XML and its schema Thread-Index: AQHOR1eSNWLa/5s06kGNfaMDzHLEFw== Date: Thu, 2 May 2013 17:07:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.65.70.106] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Reason header representation in XML and its schema 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, 02 May 2013 17:07:55 -0000 Hi all, In IETF86 we agreed on the following for Reason header. 1) support SIP reason header format and have equivalent to SIP Reason header in XML. We should also provide a way to carry over multiple reason header(s) since a CS can have more than one SIP dialog. Towards that the following is the change to XML schema. In the ver 11 of the metadata, maxOccurs for reason XML element is not mentioned(defaulted to 1). Now we have to modify the same to say unbounded to allow multiple reason header XML elements and also to have the attributes cause and protocol. Hence the XML element has to changed from simpleElement to ComplexElement Modified XML schema definition for reason header element is: Example of how it would look is (already discussed in the mailer): Call completed elsewhere Busy Everywhere A question here: Do we really need the attribute protocol=3D"SIP" here since SIPREC is going to have only SIP always ? Regards, Ram From rmohanr@cisco.com Thu May 2 10:30:08 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 C73BA21F900C for ; Thu, 2 May 2013 10:30:08 -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 3ik9zcpx4OHw for ; Thu, 2 May 2013 10:30:04 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F0DB021F8FF0 for ; Thu, 2 May 2013 10:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2202; q=dns/txt; s=iport; t=1367515804; x=1368725404; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=RMh62t4VizUJWRzpGf+DGoJwlUShO3uYZwKFCDJZOuI=; b=enpHc/pQSl9EUQKADXH7Y/oS8fitc202PC+jSJHCg/zcAYhIydbgqomO K0KVhGbHGDvUk7lkVBBtBbmlLmQ6SAmWNa21Sja/s/fJkoqQgWZQnQG2t UW/TAbE/mQbfrRuCViPKEHIbMmXlCKCycQDchnAe0iTZMyuSMN4gN7EZA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoHAPihglGtJXHA/2dsb2JhbABSgwc3viGBB38WbQeCHwEBAQMBAQEBNzQQDQEIIhQ3CyUCBBMIh34GDKFkn0cEjnMCOIJyYQOoXYMNgWskGA X-IronPort-AV: E=Sophos;i="4.87,597,1363132800"; d="scan'208";a="205540927" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 02 May 2013 17:30:03 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r42HU203027794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 May 2013 17:30:03 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.179]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 2 May 2013 12:30:02 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] Reason header representation in XML and its schema Thread-Index: AQHOR1qs51Om26InTUOYBQ56kgTaGQ== Date: Thu, 2 May 2013 17:30:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.65.70.106] Content-Type: text/plain; charset="us-ascii" Content-ID: <7081AB7BBAFF4A45879CF1917E155347@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Reason header representation in XML and its schema 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, 02 May 2013 17:30:08 -0000 > On 02/05/13 10:37 PM, "Ram Mohan R (rmohanr)" wrote: >Hi all, > >In IETF86 we agreed on the following for Reason header. >1) support SIP reason header format and have equivalent to SIP Reason >header in XML. We should also provide a way to carry over multiple reason >header(s) since a CS can have more than one SIP dialog. > > >Towards that the following is the change to XML schema. In the ver 11 of >the metadata, maxOccurs for reason XML element is not mentioned(defaulted >to 1). Now we have to modify the same to say unbounded to allow multiple >reason header XML elements and also to have the attributes cause and >protocol. Hence the XML element has to changed from simpleElement to >ComplexElement > > >Modified XML schema definition for reason header element is: > >maxOccurs=3D"unbounded"> > use=3D"required"/> > > A small correction here. The above representation of schema gives some warning when I validated with XSD tool. Instead the below representation should be used Regards, Ram > > > > >Example of how it would look is (already discussed in the mailer): > >Call completed elsewhere >Busy Everywhere > > > >A question here: >Do we really need the attribute protocol=3D"SIP" here since SIPREC is goin= g >to have only SIP always ? > >Regards, >Ram > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Thu May 2 10:42:24 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F6321F919A for ; Thu, 2 May 2013 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.296 X-Spam-Level: X-Spam-Status: No, score=-0.296 tagged_above=-999 required=5 tests=[AWL=0.141, 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 jogOcQYABxzm for ; Thu, 2 May 2013 10:42:19 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id EE4B621F9173 for ; Thu, 2 May 2013 10:42:18 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta15.westchester.pa.mail.comcast.net with comcast id X18l1l0080SCNGk5F5iJDR; Thu, 02 May 2013 17:42:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id X5iJ1l00E3ZTu2S3V5iJcr; Thu, 02 May 2013 17:42:18 +0000 Message-ID: <5182A578.7020007@alum.mit.edu> Date: Thu, 02 May 2013 13:42:16 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367516538; bh=zhX0Mul3Thi1AzYHvTGREfRCJUOLRts9u+KtpXqQKd4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NN/Xaw8UawvcdnZURViEVF8A7mPkJmyEZy8H2uD0sC4V1xrkUA3P6Z2of0qtERKXP maM4nEPe2Rj9/RIUmPbvrjhiiQHITwCWKZ4HIFp2KlXn/j95eaS4ktBN8l6qS6uDTF nUyICP8J6JtrAp3S04dV4U9gGUDBW5m6SM/oPcoaI53evZWgoSeTFaBkOYOpgItBUC M/Umrq5ZCKQOLmip67I7qaTotkyyLiauJkTOCoJ2b6cVp4gi8ODkwrAoADeZ6YAbNW N8MqVYFpesiJeGGfSdF/yKMheqaDUre4tQVP+J6miRoeDJQ1im+dmx4kIHX5adEn7v 0sZUTt/cZ9kAA== Subject: Re: [siprec] Reason header representation in XML and its schema 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, 02 May 2013 17:42:25 -0000 On 5/2/13 1:07 PM, Ram Mohan R (rmohanr) wrote: > Hi all, > > In IETF86 we agreed on the following for Reason header. > 1) support SIP reason header format and have equivalent to SIP Reason > header in XML. We should also provide a way to carry over multiple reason > header(s) since a CS can have more than one SIP dialog. > > Towards that the following is the change to XML schema. In the ver 11 of > the metadata, maxOccurs for reason XML element is not mentioned(defaulted > to 1). Now we have to modify the same to say unbounded to allow multiple > reason header XML elements and also to have the attributes cause and > protocol. Hence the XML element has to changed from simpleElement to > ComplexElement > > Modified XML schema definition for reason header element is: > > maxOccurs="unbounded"> > > > > > Example of how it would look is (already discussed in the mailer): > > Call completed elsewhere > Busy Everywhere > > A question here: > Do we really need the attribute protocol="SIP" here since SIPREC is going > to have only SIP always ? Yes. The reason is (at least may) being carried over from an actual Reason header in the CS. And the Reason header in the CS can have other protocols. (E.g., Q.850.) Thanks, Paul From rmohanr@cisco.com Thu May 2 10:45:43 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8394C21F90B1 for ; Thu, 2 May 2013 10:45:43 -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 KddlVsbpBcgp for ; Thu, 2 May 2013 10:45:38 -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 8ADE421F919D for ; Thu, 2 May 2013 10:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2015; q=dns/txt; s=iport; t=1367516738; x=1368726338; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=tEe7CzEDx5rguhkknR27uZFkPFdxQrhIISMJ3qVltqY=; b=Umr0cp7zCA1HD9ZXOOLzf7rU2G0vgSBN8JETj/scZiK8uZQhd5NvC5rc zx45h7dxhHWCywBlM6UOmqaxo2d3e1VhJvXHgdUdH0eWvAYt5m0b9vWhM qV071SyysnLwQUzgvC2RwzcG5404cNXy9xywteWDIpIJnyC1eW00xhIYh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAE6lglGtJXHA/2dsb2JhbABSDoJ5N74hgQd/FnSCHwEBAQMBAQEBNy0HEA0BCA4KChQ3CyUCBAESCId+BgzBOgSOdTiCcmEDqF2CTj+CJw X-IronPort-AV: E=Sophos;i="4.87,597,1363132800"; d="scan'208";a="202770358" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 02 May 2013 17:45:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r42Hjc0D016119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 17:45:38 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.179]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 2 May 2013 12:45:37 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Reason header representation in XML and its schema Thread-Index: AQHOR1zaQ3Eq4dan0USO3YrqZlsFKQ== Date: Thu, 2 May 2013 17:45:37 +0000 Message-ID: In-Reply-To: <5182A578.7020007@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.65.70.106] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Reason header representation in XML and its schema 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, 02 May 2013 17:45:43 -0000 > On 02/05/13 11:12 PM, "Paul Kyzivat" wrote: >On 5/2/13 1:07 PM, Ram Mohan R (rmohanr) wrote: >> Hi all, >> >> In IETF86 we agreed on the following for Reason header. >> 1) support SIP reason header format and have equivalent to SIP Reason >> header in XML. We should also provide a way to carry over multiple >>reason >> header(s) since a CS can have more than one SIP dialog. >> >> Towards that the following is the change to XML schema. In the ver 11 of >> the metadata, maxOccurs for reason XML element is not >>mentioned(defaulted >> to 1). Now we have to modify the same to say unbounded to allow multiple >> reason header XML elements and also to have the attributes cause and >> protocol. Hence the XML element has to changed from simpleElement to >> ComplexElement >> >> Modified XML schema definition for reason header element is: >> >> > maxOccurs=3D"unbounded"> >> >use=3D"required"/> >> >> >> >> Example of how it would look is (already discussed in the mailer): >> >> Call completed elsewhere >> Busy Everywhere >> >> A question here: >> Do we really need the attribute protocol=3D"SIP" here since SIPREC is >>going >> to have only SIP always ? > >Yes. The reason is (at least may) being carried over from an actual >Reason header in the CS. And the Reason header in the CS can have other >protocols. (E.g., Q.850.) Ok. This is possible. In that case I would have to change the schema to have the attribute take either SIP or Q.850. Ram > > Thanks, > Paul > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Thu May 2 10:50:13 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7697921F91BB for ; Thu, 2 May 2013 10:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=0.133, 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 nn9oqwz2o7zH for ; Thu, 2 May 2013 10:50:05 -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 C3B2A21F9128 for ; Thu, 2 May 2013 10:50:04 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id Wy2H1l00717dt5G535q4ST; Thu, 02 May 2013 17:50:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id X5q31l01K3ZTu2S3Z5q3Vp; Thu, 02 May 2013 17:50:04 +0000 Message-ID: <5182A74A.2040504@alum.mit.edu> Date: Thu, 02 May 2013 13:50:02 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367517004; bh=uDgi1omXF18sKkuGWJsnoiZC1iolL+uzYp4Pxu0KKc0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kNyA8zGBff3dXIbjK3zmJoYfzTIPYp3U9rsb63big7vuKO77mddISxolSuR1EQDEb Voq6NiZe8himqTz4A9jNTs+kGlo1+PgVd8lXpRG+LMgo0baraYtrH6LPMkyzAQ9uyy XKgQAQvenxqPAPrNGC2JJAlbp/zuFMe5bgvKgxjcIhRwWO+luVnqNe2BjynvmhI3l1 S10uGd2Ka2OoOSJ0Sx5f1Un59IhIxT7cnrmofIlCBhHupbNXFf0RUQ06uLzLoz9hyV aRL03FF3WmGD/vi4iyUa9sasme1af8c3s9qrQMN0fwM8Se/1fj4OR0+qcRgfib4Ekc gb7fhbHG8xmWg== Subject: Re: [siprec] Reason header representation in XML and its schema 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, 02 May 2013 17:50:13 -0000 one comment inline On 5/2/13 1:30 PM, Ram Mohan R (rmohanr) wrote: >> On 02/05/13 10:37 PM, "Ram Mohan R (rmohanr)" wrote: > >> Hi all, >> >> In IETF86 we agreed on the following for Reason header. >> 1) support SIP reason header format and have equivalent to SIP Reason >> header in XML. We should also provide a way to carry over multiple reason >> header(s) since a CS can have more than one SIP dialog. >> >> >> Towards that the following is the change to XML schema. In the ver 11 of >> the metadata, maxOccurs for reason XML element is not mentioned(defaulted >> to 1). Now we have to modify the same to say unbounded to allow multiple >> reason header XML elements and also to have the attributes cause and >> protocol. Hence the XML element has to changed from simpleElement to >> ComplexElement >> >> >> Modified XML schema definition for reason header element is: >> >> > maxOccurs="unbounded"> >> > use="required"/> >> >> > > A small correction here. The above representation of schema gives some > warning when I validated with XSD tool. > Instead the below representation should be used > > > > > > > I think the above should say 'default' rather than 'fixed'. > > > > > > > Regards, > Ram From pkyzivat@alum.mit.edu Thu May 2 10:56:18 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4F121F8E76 for ; Thu, 2 May 2013 10:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=0.135, 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 cpAJ9edagEEN for ; Thu, 2 May 2013 10:56:12 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id D29F421F8F4D for ; Thu, 2 May 2013 10:56:11 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta12.westchester.pa.mail.comcast.net with comcast id X2PP1l0041YDfWL5C5w6oP; Thu, 02 May 2013 17:56:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id X5w61l0063ZTu2S3g5w64E; Thu, 02 May 2013 17:56:06 +0000 Message-ID: <5182A8B6.9090707@alum.mit.edu> Date: Thu, 02 May 2013 13:56:06 -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: "Ram Mohan R (rmohanr)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367517366; bh=CPbtdQ1dg79CI5gEUOkfYn4msRgO2g7sxkEzzXCjKdU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZTEIKvRH8H/lomyb4leaMIz3MmUltVIiJJyqm55L461lcqm5rsDvwYVfLNQ1OEYwD s7q8ee5cRpap/NQS4JCspbM9eFHnShlk2SyHSGlwuWctwEYh2cZI3PTY+v2xi4eoj6 tpEHa9F6gYf6qBjClH1UcLkV84F3d0GrqZMT2dDsDreUQjCZ4eft3wh+cOu2Gm9eCI D+oa5AgCRBJIA982daNXzTKS0rZiytJulGKL2dZlzU7Tn8OR3oTFGIlh7buePI0dTD VQ7gz8A48zQA7jyr+CtksqUQsZ06qG1x1YburBjWHRH5BakbudtfbPcFfRftt1gO70 ogH5moUUHEjYw== Cc: "siprec@ietf.org" Subject: Re: [siprec] Reason header representation in XML and its schema 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, 02 May 2013 17:56:18 -0000 On 5/2/13 1:45 PM, Ram Mohan R (rmohanr) wrote: >> On 02/05/13 11:12 PM, "Paul Kyzivat" wrote: > >> On 5/2/13 1:07 PM, Ram Mohan R (rmohanr) wrote: >>> Hi all, >>> >>> In IETF86 we agreed on the following for Reason header. >>> 1) support SIP reason header format and have equivalent to SIP Reason >>> header in XML. We should also provide a way to carry over multiple >>> reason >>> header(s) since a CS can have more than one SIP dialog. >>> >>> Towards that the following is the change to XML schema. In the ver 11 of >>> the metadata, maxOccurs for reason XML element is not >>> mentioned(defaulted >>> to 1). Now we have to modify the same to say unbounded to allow multiple >>> reason header XML elements and also to have the attributes cause and >>> protocol. Hence the XML element has to changed from simpleElement to >>> ComplexElement >>> >>> Modified XML schema definition for reason header element is: >>> >>> >> maxOccurs="unbounded"> >>> >> use="required"/> >>> >>> >>> >>> Example of how it would look is (already discussed in the mailer): >>> >>> Call completed elsewhere >>> Busy Everywhere >>> >>> A question here: >>> Do we really need the attribute protocol="SIP" here since SIPREC is >>> going >>> to have only SIP always ? >> >> Yes. The reason is (at least may) being carried over from an actual >> Reason header in the CS. And the Reason header in the CS can have other >> protocols. (E.g., Q.850.) > > Ok. This is possible. In that case I would have to change the schema to > have the attribute take either SIP or Q.850. I just replied on that. I think you should make the default SIP, but allow any string. That way it won't need to change as new reason protocols are defined. Thanks, Paul From rmohanr@cisco.com Thu May 2 20:07:12 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A367C21F8FB6 for ; Thu, 2 May 2013 20:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s073hxVHcwVi for ; Thu, 2 May 2013 20:07:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C740A21F9027 for ; Thu, 2 May 2013 20:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2323; q=dns/txt; s=iport; t=1367550426; x=1368760026; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=WTeruzPcv1sWuaQWoFgpV5vZiGda3IPenECEW8MMaqs=; b=UpQ7peTkT/ZJlIr1ANWegXYuR9DOkSPUgWkVKlB/QuvZrveMFAuvAz8C ldU8DiqRF7T5Q9MN1NBxoZ5RFdUg50/ZUH8j8Xi7flRHvKOWVf0IkeN3l g22vS3GkrPrCsTuorLkLCAR4o2BplBC4cB05anGBVeeJ/dnz0IaZmZHco 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAC8pg1GtJV2d/2dsb2JhbABQDoJ5vl2BB4EAFnSCHwEBAQMBOi0XDQEIDgoKFEIlAgQBEgiHfgbBJ450AjiCcmEDqF2CTj+CJw X-IronPort-AV: E=Sophos;i="4.87,600,1363132800"; d="scan'208";a="205708041" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 03 May 2013 03:07:06 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r433761A028366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 03:07:06 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.179]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 2 May 2013 22:07:05 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Reason header representation in XML and its schema Thread-Index: AQHOR6tK+hzS09miXU2UcCZZGLnABw== Date: Fri, 3 May 2013 03:07:04 +0000 Message-ID: In-Reply-To: <5182A8B6.9090707@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.212.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Reason header representation in XML and its schema 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, 03 May 2013 03:07:12 -0000 > On 02/05/13 11:26 PM, "Paul Kyzivat" wrote: >On 5/2/13 1:45 PM, Ram Mohan R (rmohanr) wrote: >>> On 02/05/13 11:12 PM, "Paul Kyzivat" wrote: >> >>> On 5/2/13 1:07 PM, Ram Mohan R (rmohanr) wrote: >>>> Hi all, >>>> >>>> In IETF86 we agreed on the following for Reason header. >>>> 1) support SIP reason header format and have equivalent to SIP Reason >>>> header in XML. We should also provide a way to carry over multiple >>>> reason >>>> header(s) since a CS can have more than one SIP dialog. >>>> >>>> Towards that the following is the change to XML schema. In the ver 11 >>>>of >>>> the metadata, maxOccurs for reason XML element is not >>>> mentioned(defaulted >>>> to 1). Now we have to modify the same to say unbounded to allow >>>>multiple >>>> reason header XML elements and also to have the attributes cause and >>>> protocol. Hence the XML element has to changed from simpleElement to >>>> ComplexElement >>>> >>>> Modified XML schema definition for reason header element is: >>>> >>>> >>> maxOccurs=3D"unbounded"> >>>> >>> use=3D"required"/> >>>> >>>> >>>> >>>> Example of how it would look is (already discussed in the mailer): >>>> >>>> Call completed elsewhere >>>> Busy Everywhere >>>> >>>> A question here: >>>> Do we really need the attribute protocol=3D"SIP" here since SIPREC is >>>> going >>>> to have only SIP always ? >>> >>> Yes. The reason is (at least may) being carried over from an actual >>> Reason header in the CS. And the Reason header in the CS can have other >>> protocols. (E.g., Q.850.) >> >> Ok. This is possible. In that case I would have to change the schema to >> have the attribute take either SIP or Q.850. > >I just replied on that. I think you should make the default SIP, but >allow any string. That way it won't need to change as new reason >protocols are defined. Ok. Will make this change. Thanks, Ram > > Thanks, > Paul > > From rmohanr@cisco.com Fri May 3 05:55:12 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1821521F9633 for ; Fri, 3 May 2013 05:55:12 -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 IC2BumYJxIMI for ; Fri, 3 May 2013 05:55:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2289D21F963A for ; Fri, 3 May 2013 05:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3450; q=dns/txt; s=iport; t=1367585707; x=1368795307; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=j9KUopG7Yl1VeJLFBI39V48FiBqg5rulmJSnsGGClrY=; b=l7JOh9buYatH+hcmjxRU2nwHLH13ix801hw652meYTLu7fgb8fEKtr/a gC4Pth8AJgwZCuyNdfcKU93YHGra9+guF0p0qQQZm+uIpz2JBR8SoaxQ8 TB2sYjQQwp1avV6Y8lq+HMQ4Oa8bV1f+aw43Z/xhbBBo9FvFjMYVeuNFY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisGAIGxg1GtJV2a/2dsb2JhbABQgwc3viiBB3kWbQeCHwEBAQMBAQEBNy0HEA0BCBgKFDcLJQIEEwiHfgYMoVefaASOdAI4gnJhA6hdgw2CJw X-IronPort-AV: E=Sophos;i="4.87,604,1363132800"; d="scan'208";a="206070530" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 03 May 2013 12:55:05 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r43Ct4ND024096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 3 May 2013 12:55:04 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.179]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 3 May 2013 07:55:04 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] Reason header representation in XML and its schema Thread-Index: AQHOR/1tFV0CzuRe502RfJAhfBLZyQ== Date: Fri, 3 May 2013 12:55:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.65.67.159] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B32BF3259908C4A9B86652AD32BD057@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Reason header representation in XML and its schema 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, 03 May 2013 12:55:12 -0000 Modified XML Schema incorporating the change suggested by Paul. Examples would look like Call completed elsewhere Busy Everywhere Terminated Let me know if any one has concerns with this approach before 10/5. Otherwise we will incorporate this in the next revision. Thanks, Ram > On 03/05/13 8:37 AM, "Ram Mohan R (rmohanr)" wrote: >> On 02/05/13 11:26 PM, "Paul Kyzivat" wrote: > >>On 5/2/13 1:45 PM, Ram Mohan R (rmohanr) wrote: >>>> On 02/05/13 11:12 PM, "Paul Kyzivat" wrote: >>> >>>> On 5/2/13 1:07 PM, Ram Mohan R (rmohanr) wrote: >>>>> Hi all, >>>>> >>>>> In IETF86 we agreed on the following for Reason header. >>>>> 1) support SIP reason header format and have equivalent to SIP >>>>>Reason >>>>> header in XML. We should also provide a way to carry over multiple >>>>> reason >>>>> header(s) since a CS can have more than one SIP dialog. >>>>> >>>>> Towards that the following is the change to XML schema. In the ver 11 >>>>>of >>>>> the metadata, maxOccurs for reason XML element is not >>>>> mentioned(defaulted >>>>> to 1). Now we have to modify the same to say unbounded to allow >>>>>multiple >>>>> reason header XML elements and also to have the attributes cause and >>>>> protocol. Hence the XML element has to changed from simpleElement to >>>>> ComplexElement >>>>> >>>>> Modified XML schema definition for reason header element is: >>>>> >>>>> >>>> maxOccurs=3D"unbounded"> >>>>> >>>> use=3D"required"/> >>>>> >>>>> >>>>> >>>>> Example of how it would look is (already discussed in the mailer): >>>>> >>>>> Call completed elsewhere >>>>> Busy Everywhere >>>>> >>>>> A question here: >>>>> Do we really need the attribute protocol=3D"SIP" here since SIPREC is >>>>> going >>>>> to have only SIP always ? >>>> >>>> Yes. The reason is (at least may) being carried over from an actual >>>> Reason header in the CS. And the Reason header in the CS can have >>>>other >>>> protocols. (E.g., Q.850.) >>> >>> Ok. This is possible. In that case I would have to change the schema to >>> have the attribute take either SIP or Q.850. >> >>I just replied on that. I think you should make the default SIP, but >>allow any string. That way it won't need to change as new reason >>protocols are defined. > >Ok. Will make this change. > >Thanks, >Ram > >> >> Thanks, >> Paul >> >> > > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Fri May 3 08:50:11 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DB821F97C1 for ; Fri, 3 May 2013 08:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=0.117, 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 iYGCecAtm7U6 for ; Fri, 3 May 2013 08:50:04 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAE221F963F for ; Fri, 3 May 2013 08:05:39 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id XQaq1l0021c6gX851T5fTC; Fri, 03 May 2013 15:05:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id XT5f1l00H3ZTu2S3jT5fSU; Fri, 03 May 2013 15:05:39 +0000 Message-ID: <5183D242.5070008@alum.mit.edu> Date: Fri, 03 May 2013 11:05:38 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367593539; bh=mBG+zjXk1cH6vnNeNjYo0JyoX5/hUxLNakIit12TpN0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=P8UVwe1Y9ETZbfUNjXKTTertPr/QphuksXp9sSyLGaFqvH3GLlzmWOA1DdS+f381w tjY4sTnKSKiW3CyLfkY78JUwqHhvF8hFzKyJ1G7j+ZoLbwi0C3BAk/u6krRdKSkWKR Jk23Tz0owr0u0kdezqThLBRSeB383CZm0Arp6Ha0D7cI9eLmDicVPwfwJBKj63ypSj rLaaCZCPBopL1vOzfqufKGMo7w/6k0Bu1M2Llv+EVWcRjdPnCncarbCfrnUWvPCwJo 3Oq0abk5SvUpXdvXf2stoBJR1WYxQZ2TP0tBLw7dCUu9auUWe7KzoufjcX5ODxmkOB cXnv4xg3peh6g== Subject: Re: [siprec] Reason header representation in XML and its schema 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, 03 May 2013 15:50:11 -0000 On 5/3/13 8:55 AM, Ram Mohan R (rmohanr) wrote: > Modified XML Schema incorporating the change suggested by Paul. > > > > > > > > > > > > > > Examples would look like > > Call completed elsewhere > Busy Everywhere Of course, because of the default, the above could be simplified to: Call completed elsewhere Busy Everywhere > Terminated > > > Let me know if any one has concerns with this approach before 10/5. > Otherwise we will incorporate this in the next revision. Thanks, Paul From eckelcu@cisco.com Fri May 3 21:40:07 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB321F8FE3 for ; Fri, 3 May 2013 21:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUGMFYSqrVnq for ; Fri, 3 May 2013 21:40:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 53A9D21F8FA4 for ; Fri, 3 May 2013 21:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7101; q=dns/txt; s=iport; t=1367642401; x=1368852001; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Z8ugJzjWyBf5bGDMBWOBp7jLJxvMG1RnWMS+Y2SbYYM=; b=Z7yL/0cJkzO7bPXK3FEgKMqQLO6XOsAyxurmTHGU7qsSnaMbzW/11+iS rR7qdJ0wS3y1aTXdhmCsFHxBY9n8bCmGpWmI41anqsuNiAyY2UJR5yLgY acW0eGs/teloltNHIL0h1bMKJml7tcRhzJ0RTQtnRenCLLv4bPzxqySlQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAECQhFGtJXG9/2dsb2JhbABQgwc3vzV8FnSCHwEBAQQBAQE3LgYXBAIBCBEDAQEBAQoUCQchBgsUCQgCBAESCIdyAw8MuUwNiAiMW4EudwYyBoJsYQOVSIMKimuFIYMNgWkkGg X-IronPort-AV: E=Sophos;i="4.87,609,1363132800"; d="scan'208";a="206305978" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 04 May 2013 04:40:00 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r444e0KV025577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 4 May 2013 04:40:00 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.28]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 3 May 2013 23:40:00 -0500 From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgABxdoCAAOTQAIAAMpaAgAFJ7ICAAja1gA== Date: Sat, 4 May 2013 04:39:59 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280481E5EA@xmb-aln-x08.cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF0E6D5B5E@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.131] 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: Sat, 04 May 2013 04:40:07 -0000 Hi Ram, My thinking on this is that we should use changing of the direction of medi= a descriptions in the RS from sendonly to inactive and vice versa to indica= te stopping/starting the recording of the associated media stream as a whol= e. This does not imply anything about the state of the media in the CS. A h= old/resume of the CS could result in the SRC deciding to stop the recording= , but this is not necessarily the case. The SRC could let the recording con= tinue, and indicate in XML which participants in the CS are actively contri= buting media. As an example, if the CS is a two party call, a hold of the CS might result= in the SRC stopping/pausing the recording. If it is a conference call, one= party going on hold would have might have no effect on the direction of th= e media descriptions in the RS, but may result in the generation of some XM= L indicating that a specific participant is no longer contributing any medi= a. I thought the existing XML allowed for this, but perhaps I am mistaken a= bout that? Cheers, Charles=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Wednesday, May 01, 2013 8:21 PM > To: siprec@ietf.org > Subject: Re: [siprec] CS hold/resume clarification in protocol draft >=20 > A question here: >=20 > In the current metadata draft to indicate CS hold/resume from SRC to > SRS > we re-use the SIP/SDP semantics and indicate the same with > a=3Dinactive/a=3Dsendonly respectively. > In the below discussion, I see we want to give a special meaning for > a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS > hold / > resume cannot be indicated using SDP semantics from SRC to SRS as > the SRS > cannot differentiate between CS hold/resume and Recording > stop/resume if > we use the same semantics for both. >=20 > The current metadata XML draft does not have any means to indicate > CS > hold/resume in XML. The general approach followed in the metadata > (as a > result of past feedback received) is to re-use SIP/SDP semantics > wherever > possible to represent metadata attributes and have XML > representation for > only those attributes that does not have a semantics in SIP/SDP to > represent. And hence the current draft re-uses SDP semantics to > represent > CS HOLD/RESUME. >=20 > I want to hear feedback on - if the WG wants CSC hold/resume to be > represented in XML ? >=20 > Ram >=20 >=20 > > On 01/05/13 1:10 PM, "Hutton, Andrew" > > wrote: >=20 > >My view is that this is enough of an issue to make it a MUST as you > say > >the fact that this would result in a misunderstanding and therefore > >probably a trouble ticket being raised against the implementation > is > >reason enough. > > > >Andy > > > > > > > >> -----Original Message----- > >> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] > >> Sent: 01 May 2013 05:39 > >> To: Alan Johnston; Hutton, Andrew > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] CS hold/resume clarification in protocol draft > >> > >> The only interop issue this can cause is an SRS would mistaken a > hold > >> as pause/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" > >> enterprise.com> 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=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 > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partha@parthasarathi.co.in Sun May 5 08:08:02 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 5319521F92EC for ; Sun, 5 May 2013 08:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, 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 Hjw5Yv3Dfg1Q for ; Sun, 5 May 2013 08:07:58 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id 34FB721F92EF for ; Sun, 5 May 2013 08:07:57 -0700 (PDT) Received: from userPC (unknown [122.179.43.175]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 4D003638CED; Sun, 5 May 2013 15:07:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1367766477; bh=yqFKR1Nl6nBTEcXU9YNjROFFZ8Whzj5Lo1rsthL9Mco=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ry0Hnl16HIOaJ98+/S69vr0FRKl/CHm67hErY/Vdd6RhvAxJyGWb7xer3uFp1+GYo A6NZHU12coLkPdgT3r94YgIwpkzVE7mf677HeTNeYn+45hjJLnsrklgAzk0u63KNOZ pkvy+R3XnVaef+srcQJy5Zr8k4QxRbMRVtolQ/OM= From: "Parthasarathi R" To: "'Charles Eckel \(eckelcu\)'" , "'Ram Mohan R \(rmohanr\)'" , References: <9F33F40F6F2CD847824537F3C4E37DDF0E6D5B5E@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280481E5EA@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280481E5EA@xmb-aln-x08.cisco.com> Date: Sun, 5 May 2013 20:37:49 +0530 Message-ID: <000401ce49a2$52e43460$f8ac9d20$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgABxdoCAAOTQAIAAMpaAgAFJ7ICAAja1gIAC71+w Content-Language: en-us X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 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: Sun, 05 May 2013 15:08:02 -0000 Hi Charles, As per SIPREC requirement RFC, pause & resume of RS media are the only operation defined and the definition is as follows: Pause: The action of temporarily discontinuing the transmission and collection of RS media. Resume: The action of recommencing the transmission and collection of RS media. >From Metadata in RS SDP, it will be clear whether the media is paused or not using the direction attributes. In case of mixed stream, the media is not paused but one of the participant media is not mixed and so, it will not fall under Pause. As of now, metadata does not consider CS hold as the multiple types of CS hold are possible which are as follows: 1) Music on hold (Participant put the remote participant to listen (recvonly) instead of senvrecv. 2) Hold by direction attribute (Both participant are not sending media and indicated by inactive SDP direction attribute) 3) Hold by setting m-line port as 0 4) Hold by setting c-line IP as invalid (0.0.0.0) or :: 5) One of the participant in the conference is put in hold (Your usecase). 6) Not sending media without any signaling exchange (Bad implementation but exists in the deployment) Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Saturday, May 04, 2013 10:10 AM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] CS hold/resume clarification in protocol draft > > Hi Ram, > > My thinking on this is that we should use changing of the direction of > media descriptions in the RS from sendonly to inactive and vice versa > to indicate stopping/starting the recording of the associated media > stream as a whole. This does not imply anything about the state of the > media in the CS. A hold/resume of the CS could result in the SRC > deciding to stop the recording, but this is not necessarily the case. > The SRC could let the recording continue, and indicate in XML which > participants in the CS are actively contributing media. > As an example, if the CS is a two party call, a hold of the CS might > result in the SRC stopping/pausing the recording. If it is a conference > call, one party going on hold would have might have no effect on the > direction of the media descriptions in the RS, but may result in the > generation of some XML indicating that a specific participant is no > longer contributing any media. I thought the existing XML allowed for > this, but perhaps I am mistaken about that? > > Cheers, > Charles > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: Wednesday, May 01, 2013 8:21 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] CS hold/resume clarification in protocol draft > > > > A question here: > > > > In the current metadata draft to indicate CS hold/resume from SRC to > > SRS > > we re-use the SIP/SDP semantics and indicate the same with > > a=inactive/a=sendonly respectively. > > In the below discussion, I see we want to give a special meaning for > > a=inactive/a=sendonly sent from SRC to SRS. This would mean CS > > hold / > > resume cannot be indicated using SDP semantics from SRC to SRS as > > the SRS > > cannot differentiate between CS hold/resume and Recording > > stop/resume if > > we use the same semantics for both. > > > > The current metadata XML draft does not have any means to indicate > > CS > > hold/resume in XML. The general approach followed in the metadata > > (as a > > result of past feedback received) is to re-use SIP/SDP semantics > > wherever > > possible to represent metadata attributes and have XML > > representation for > > only those attributes that does not have a semantics in SIP/SDP to > > represent. And hence the current draft re-uses SDP semantics to > > represent > > CS HOLD/RESUME. > > > > I want to hear feedback on - if the WG wants CSC hold/resume to be > > represented in XML ? > > > > Ram > > > > > > > On 01/05/13 1:10 PM, "Hutton, Andrew" > > > wrote: > > > > >My view is that this is enough of an issue to make it a MUST as you > > say > > >the fact that this would result in a misunderstanding and therefore > > >probably a trouble ticket being raised against the implementation > > is > > >reason enough. > > > > > >Andy > > > > > > > > > > > >> -----Original Message----- > > >> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] > > >> Sent: 01 May 2013 05:39 > > >> To: Alan Johnston; Hutton, Andrew > > >> Cc: siprec@ietf.org > > >> Subject: Re: [siprec] CS hold/resume clarification in protocol > draft > > >> > > >> The only interop issue this can cause is an SRS would mistaken a > > hold > > >> as pause/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" > > > >> enterprise.com> 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 > > > > > > > > > _______________________________________________ > > 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 Sun May 5 20:17:38 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 4ABDE21F866E for ; Sun, 5 May 2013 20:17:38 -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 iuhijt3Ufu69 for ; Sun, 5 May 2013 20:17:33 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29921F8653 for ; Sun, 5 May 2013 20:17:31 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Sun, 05 May 2013 23:17:28 -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; Sun, 5 May 2013 20:17:24 -0700 From: Henry Lum To: "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgACS/YCAAG94YYAAMcNQgAHAF4CAAzq6gIACyoWA Date: Mon, 6 May 2013 03:17:24 +0000 Message-ID: In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280481E5EA@xmb-aln-x08.cisco.com> 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: <60F377F04716204E82A5284688316033@genesyslab.com> MIME-Version: 1.0 X-MC-Unique: 113050523172805202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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: Mon, 06 May 2013 03:17:38 -0000 I agree that an SRC may choose to pause the RS media if the CS is happened to be placed on hold. What the protocol draft is stating that SRC must use a=3Dinactive to state that it is pausing media while the metadata is conveying the information about the CS is being placed on hold. The way I understand the last sentence of section 6.7 is that the media stream object can provide this information on media stream direction change. If this is not correct then we should consider adding this into the metadata draft. Henry On 2013-05-04 12:39 AM, "Charles Eckel (eckelcu)" wrote: >Hi Ram, > >My thinking on this is that we should use changing of the direction of >media descriptions in the RS from sendonly to inactive and vice versa to >indicate stopping/starting the recording of the associated media stream >as a whole. This does not imply anything about the state of the media in >the CS. A hold/resume of the CS could result in the SRC deciding to stop >the recording, but this is not necessarily the case. The SRC could let >the recording continue, and indicate in XML which participants in the CS >are actively contributing media. >As an example, if the CS is a two party call, a hold of the CS might >result in the SRC stopping/pausing the recording. If it is a conference >call, one party going on hold would have might have no effect on the >direction of the media descriptions in the RS, but may result in the >generation of some XML indicating that a specific participant is no >longer contributing any media. I thought the existing XML allowed for >this, but perhaps I am mistaken about that? > >Cheers, >Charles=20 > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ram Mohan R (rmohanr) >> Sent: Wednesday, May 01, 2013 8:21 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>=20 >> A question here: >>=20 >> In the current metadata draft to indicate CS hold/resume from SRC to >> SRS >> we re-use the SIP/SDP semantics and indicate the same with >> a=3Dinactive/a=3Dsendonly respectively. >> In the below discussion, I see we want to give a special meaning for >> a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS >> hold / >> resume cannot be indicated using SDP semantics from SRC to SRS as >> the SRS >> cannot differentiate between CS hold/resume and Recording >> stop/resume if >> we use the same semantics for both. >>=20 >> The current metadata XML draft does not have any means to indicate >> CS >> hold/resume in XML. The general approach followed in the metadata >> (as a >> result of past feedback received) is to re-use SIP/SDP semantics >> wherever >> possible to represent metadata attributes and have XML >> representation for >> only those attributes that does not have a semantics in SIP/SDP to >> represent. And hence the current draft re-uses SDP semantics to >> represent >> CS HOLD/RESUME. >>=20 >> I want to hear feedback on - if the WG wants CSC hold/resume to be >> represented in XML ? >>=20 >> Ram >>=20 >>=20 >> > On 01/05/13 1:10 PM, "Hutton, Andrew" >> > wrote: >>=20 >> >My view is that this is enough of an issue to make it a MUST as you >> say >> >the fact that this would result in a misunderstanding and therefore >> >probably a trouble ticket being raised against the implementation >> is >> >reason enough. >> > >> >Andy >> > >> > >> > >> >> -----Original Message----- >> >> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] >> >> Sent: 01 May 2013 05:39 >> >> To: Alan Johnston; Hutton, Andrew >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >> >> >> >> The only interop issue this can cause is an SRS would mistaken a >> hold >> >> as pause/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" >> > >> enterprise.com> 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=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. Medi= a >> >> >> 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 >> > >>=20 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Wed May 8 23:30:11 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AD121F9184 for ; Wed, 8 May 2013 23:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=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 FANdf7UR9S3M for ; Wed, 8 May 2013 23:30:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCB821F9104 for ; Wed, 8 May 2013 23:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13994; q=dns/txt; s=iport; t=1368081006; x=1369290606; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NgeX2i6wSWaiwHI4DfdVGoRRkcBqjdhfZKuzhyA5CKE=; b=b4IRAB2kBhWO8HRJ3920DtUMl/Qz1+sfUFRyJkzGvRR8Dbu6Mo1eHEzk RATT0UYZWwqjhtF9AZbw5zF5FBGy/iCtCmkXR7EB9Zoct5abLIVnwSt44 a+qB1+ukf49PW7NXu7oZREq06ivjNFBuElt/oHSRCpZcDCRi0TWQJmISk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGRBi1GtJV2Z/2dsb2JhbABSgwc3vz99FnSCHwEBAQMBAQEBJBMuBhAHBgEIEQMBAQEBChQJKAYLFAkIAgQBEgiHcgMJBgy4Ug2IJ4xSgS51AgYyAgSCbmEDlUiDCopthSKDD4FpBh4a X-IronPort-AV: E=Sophos;i="4.87,639,1363132800"; d="scan'208";a="208288588" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 09 May 2013 06:30:05 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r496U4is013681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 May 2013 06:30:04 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.52]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 9 May 2013 01:30:03 -0500 From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOTH6iPtHmHWUOa06wJvFVkD981g== Date: Thu, 9 May 2013 06:30:02 +0000 Message-ID: In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280481E5EA@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.212.115] Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Thu, 09 May 2013 06:30:11 -0000 Hi Charles, Sorry for delay. Please see inline > On 04/05/13 10:09 AM, "Charles Eckel (eckelcu)" >wrote: >Hi Ram, > >My thinking on this is that we should use changing of the direction of >media descriptions in the RS from sendonly to inactive and vice versa to >indicate stopping/starting the recording of the associated media stream >as a whole. This does not imply anything about the state of the media in >the CS. I gave some thought about this and I tend to agree with you that we could use the SDP direction attribute of RS to indicate stop/re-start the recording of media represented by that m-line. Now how an SRC decides to start/stop should be left outside the scope of SIPREC and may be dictated by a policy. > A hold/resume of the CS could result in the SRC deciding to stop the >recording, but this is not necessarily the case. The SRC could let the >recording continue, and indicate in XML which participants in the CS are >actively contributing media. To represent hold/resume or any other change in CS media, we could still do with the existing metadata XML. We could use the and XML elements of a to indicate whether a participant is sending media/not sending a particular media stream whose properties are represented by element. Note with this we only convey if a participant is sending/not sending media but an SRC still cannot convey why a CS participant is not sending media(like hold e.t.c). I don't think an SRC can really know this, all it can leo is by looking at CS signaling SDP and learn the direction attributes of media and send a snapshot metadata which has the information on participant sending/not sending a particular media stream. For example, in your below case for a two party call if one participant Alice puts the call on hold by sending a SDP with a=3Dsendonly and Bob responds with a=3Drecvonly then a snapshot of metadata at that instance fro= m SRC to SRS would look as below. Assume here a snapshot was sent initially with both participants having to the two streams: Snapshot sent from SRC to SRS after initial RS setup. F1 INVITE SRC --------------> SRS Content-Type: application/SDP ... m=3Daudio 49170 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 a=3Dlabel:96 a=3Dsendonly ... m=3Daudio 51372 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 a=3Dlabel:97 a=3Dsendonly =20 .... complete 2010-12-16T23:41:07Z Alice 2013-05-09T23:41:07Z i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D Bob 2013-05-09T23:42:07Z 8zc6e0lYTlWIINA6GR+3ag=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D Partial metadata Snapshot sent when Alice puts Bob on hold: F2 INVITE SRC --------------> SRS Content-Type: application/SDP ... m=3Daudio 49170 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 a=3Dlabel:96 a=3Dsendonly ... m=3Daudio 51372 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 a=3Dlabel:97 a=3Dsendonly Partial Snapshot after Alice resumes with Bob partial i1Pz3to5hGk8fuXl+PbwCw=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D Here in the above snapshot the absence of for participant_id srfBElmCRp2QB23b7Mpk0w=3D=3D (Alice) could be used to indicate that Alice i= s only sending media and not receiving any thing. Same way for Bob. Partial metadata Snapshot sent when Alice resumes call with Bob: F3 INVITE SRC --------------> SRS Content-Type: application/SDP ... m=3Daudio 49170 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 a=3Dlabel:96 a=3Dsendonly ... m=3Daudio 51372 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 a=3Dlabel:97 a=3Dsendonly partial i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D Here in the above snapshot both Alice and Bob send and recv streams. Note the above approach would work for all cases (stream mixed from SRC to SRS or one of the endpoint is Focus in which case SRC received mixed streams e.t.c). In all the flows the presence /absence of and tags could be used to indicate whether a participant is contributing to a stream or not and whether it is receiving a stream or not. Let me know if this approach is fine and if this works for every one in the WG. Regards, Ram >As an example, if the CS is a two party call, a hold of the CS might >result in the SRC stopping/pausing the recording. If it is a conference >call, one party going on hold would have might have no effect on the >direction of the media descriptions in the RS, but may result in the >generation of some XML indicating that a specific participant is no >longer contributing any media. I thought the existing XML allowed for >this, but perhaps I am mistaken about that? > >Cheers, >Charles=20 > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ram Mohan R (rmohanr) >> Sent: Wednesday, May 01, 2013 8:21 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>=20 >> A question here: >>=20 >> In the current metadata draft to indicate CS hold/resume from SRC to >> SRS >> we re-use the SIP/SDP semantics and indicate the same with >> a=3Dinactive/a=3Dsendonly respectively. >> In the below discussion, I see we want to give a special meaning for >> a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS >> hold / >> resume cannot be indicated using SDP semantics from SRC to SRS as >> the SRS >> cannot differentiate between CS hold/resume and Recording >> stop/resume if >> we use the same semantics for both. >>=20 >> The current metadata XML draft does not have any means to indicate >> CS >> hold/resume in XML. The general approach followed in the metadata >> (as a >> result of past feedback received) is to re-use SIP/SDP semantics >> wherever >> possible to represent metadata attributes and have XML >> representation for >> only those attributes that does not have a semantics in SIP/SDP to >> represent. And hence the current draft re-uses SDP semantics to >> represent >> CS HOLD/RESUME. >>=20 >> I want to hear feedback on - if the WG wants CSC hold/resume to be >> represented in XML ? >>=20 >> Ram >>=20 >>=20 >> > On 01/05/13 1:10 PM, "Hutton, Andrew" >> > wrote: >>=20 >> >My view is that this is enough of an issue to make it a MUST as you >> say >> >the fact that this would result in a misunderstanding and therefore >> >probably a trouble ticket being raised against the implementation >> is >> >reason enough. >> > >> >Andy >> > >> > >> > >> >> -----Original Message----- >> >> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] >> >> Sent: 01 May 2013 05:39 >> >> To: Alan Johnston; Hutton, Andrew >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >> >> >> >> The only interop issue this can cause is an SRS would mistaken a >> hold >> >> as pause/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" >> > >> enterprise.com> 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=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. Medi= a >> >> >> 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 >> > >>=20 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Wed May 8 23:37:44 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 41B9F21F8D00 for ; Wed, 8 May 2013 23:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGA5j7SnV-gy for ; Wed, 8 May 2013 23:37:39 -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 1688021F8CEC for ; Wed, 8 May 2013 23:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10395; q=dns/txt; s=iport; t=1368081459; x=1369291059; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=nrTBashiUP18E2StbHunNhaXbvRGw9wKAEIlywMt/M8=; b=e7mXYv7YjIOFz9nbDWlhdXOqyf7BD2ULO78CnRh8y1AS+oIPIO5FE7Ay Fu3mzqR6lmjyJ5IdicDgfiKzrv6OB6EONhBLJPFd82dxJxnCFOJTMWkkz tIMxA+zLgydz53Y/UIP1lCbqJKgzSdrjDZP8Hz6LnZkHJmA3vxifjZa5e U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAORDi1GtJXHB/2dsb2JhbABSgwc3v0B9FnSCHwEBAQMBAQEBZQYQBwYBCBEDAQEBAQodKAYLFAkIAgQBEgiHcgMJBgy4WQ2IJ4xSgS53BjICBIJuYQOIYoxmgwqKbYUigw+BaQYeGg X-IronPort-AV: E=Sophos;i="4.87,639,1363132800"; d="scan'208";a="205229599" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 09 May 2013 06:37:38 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r496bbLv020183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 06:37:38 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.52]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 9 May 2013 01:37:37 -0500 From: "Ram Mohan R (rmohanr)" To: Parthasarathi R , "Charles Eckel (eckelcu)" , "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOTH+xkN+nr1NQFEO3Ir6BWx+Q2Q== Date: Thu, 9 May 2013 06:37:36 +0000 Message-ID: In-Reply-To: <000401ce49a2$52e43460$f8ac9d20$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.212.115] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6FF933B195983C4E92BE80FA5F84FCF2@emea.cisco.com> 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: Thu, 09 May 2013 06:37:44 -0000 Please see inline > On 05/05/13 8:37 PM, "Parthasarathi R" >wrote: >Hi Charles, > >As per SIPREC requirement RFC, pause & resume of RS media are the only >operation defined and the definition is as follows: > > Pause: The action of temporarily discontinuing the transmission > and collection of RS media. > Resume: The action of recommencing the transmission and collection > of RS media. > >From Metadata in RS SDP, it will be clear whether the media is paused or >not using the direction attributes. In case of mixed stream, the media is >not paused but one of the participant media is not mixed and so, it will >not >fall under Pause. Pause is an operation from SRC to SRS. This has nothing to do participant contribution to media stream or a participant receiving a media stream. A participant contribution to a media stream can be indicated by the presence/absence of tag which points to a stream element. Similarly for receive as well. This would work for mixed stream cases as well where we will have multiple participants having tag point to the same mixed stream. > >As of now, metadata does not consider CS hold as the multiple types of CS >hold are possible which are as follows: > >1) Music on hold (Participant put the remote participant to listen >(recvonly) instead of senvrecv. >2) Hold by direction attribute (Both participant are not sending media and >indicated by inactive SDP direction attribute) >3) Hold by setting m-line port as 0 >4) Hold by setting c-line IP as invalid (0.0.0.0) or :: >5) One of the participant in the conference is put in hold (Your usecase). >6) Not sending media without any signaling exchange (Bad implementation >but >exists in the deployment) I don=B9t think there is a discussion / requirement to indicate the above level of information in metadata. What we need is the information if a participant is sending a stream or not and receiving a stream or not which is already possible. A participant may stop sending a media stream due to any one of the actions above when it gets negotiated in CS SDP. Ram > >Thanks >Partha > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Charles Eckel (eckelcu) >> Sent: Saturday, May 04, 2013 10:10 AM >> To: Ram Mohan R (rmohanr); siprec@ietf.org >> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>=20 >> Hi Ram, >>=20 >> My thinking on this is that we should use changing of the direction of >> media descriptions in the RS from sendonly to inactive and vice versa >> to indicate stopping/starting the recording of the associated media >> stream as a whole. This does not imply anything about the state of the >> media in the CS. A hold/resume of the CS could result in the SRC >> deciding to stop the recording, but this is not necessarily the case. >> The SRC could let the recording continue, and indicate in XML which >> participants in the CS are actively contributing media. >> As an example, if the CS is a two party call, a hold of the CS might >> result in the SRC stopping/pausing the recording. If it is a conference >> call, one party going on hold would have might have no effect on the >> direction of the media descriptions in the RS, but may result in the >> generation of some XML indicating that a specific participant is no >> longer contributing any media. I thought the existing XML allowed for >> this, but perhaps I am mistaken about that? >>=20 >> Cheers, >> Charles >>=20 >> > -----Original Message----- >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > Behalf Of Ram Mohan R (rmohanr) >> > Sent: Wednesday, May 01, 2013 8:21 PM >> > To: siprec@ietf.org >> > Subject: Re: [siprec] CS hold/resume clarification in protocol draft >> > >> > A question here: >> > >> > In the current metadata draft to indicate CS hold/resume from SRC to >> > SRS >> > we re-use the SIP/SDP semantics and indicate the same with >> > a=3Dinactive/a=3Dsendonly respectively. >> > In the below discussion, I see we want to give a special meaning for >> > a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS >> > hold / >> > resume cannot be indicated using SDP semantics from SRC to SRS as >> > the SRS >> > cannot differentiate between CS hold/resume and Recording >> > stop/resume if >> > we use the same semantics for both. >> > >> > The current metadata XML draft does not have any means to indicate >> > CS >> > hold/resume in XML. The general approach followed in the metadata >> > (as a >> > result of past feedback received) is to re-use SIP/SDP semantics >> > wherever >> > possible to represent metadata attributes and have XML >> > representation for >> > only those attributes that does not have a semantics in SIP/SDP to >> > represent. And hence the current draft re-uses SDP semantics to >> > represent >> > CS HOLD/RESUME. >> > >> > I want to hear feedback on - if the WG wants CSC hold/resume to be >> > represented in XML ? >> > >> > Ram >> > >> > >> > > On 01/05/13 1:10 PM, "Hutton, Andrew" >> > > wrote: >> > >> > >My view is that this is enough of an issue to make it a MUST as you >> > say >> > >the fact that this would result in a misunderstanding and therefore >> > >probably a trouble ticket being raised against the implementation >> > is >> > >reason enough. >> > > >> > >Andy >> > > >> > > >> > > >> > >> -----Original Message----- >> > >> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] >> > >> Sent: 01 May 2013 05:39 >> > >> To: Alan Johnston; Hutton, Andrew >> > >> Cc: siprec@ietf.org >> > >> Subject: Re: [siprec] CS hold/resume clarification in protocol >> draft >> > >> >> > >> The only interop issue this can cause is an SRS would mistaken a >> > hold >> > >> as pause/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" >> > > > >> enterprise.com> 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=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 >> > > >> > >_______________________________________________ >> > >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 trac+siprec@trac.tools.ietf.org Thu May 9 06:01:35 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE44821F8E84 for ; Thu, 9 May 2013 06:01:35 -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 RF6mtNrIDePO for ; Thu, 9 May 2013 06:01:35 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 06F8F21F8AD5 for ; Thu, 9 May 2013 06:01:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:53268 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UaQTV-0002iN-Qb; Thu, 09 May 2013 15:01:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "siprec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rmohanr@cisco.com X-Trac-Project: siprec Date: Thu, 09 May 2013 13:01:33 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/siprec/trac/ticket/75#comment:1 Message-ID: <073.a94647e14fcf1ebb4f7dcc539e431ddb@trac.tools.ietf.org> References: <058.9bb1ff33d33c7ebe8f44842c8fc32d71@trac.tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <058.9bb1ff33d33c7ebe8f44842c8fc32d71@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #75: How to represent recording callee capabilities in metadata XML ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 13:01:35 -0000 #75: How to represent recording callee capabilities in metadata XML ? Changes (by rmohanr@cisco.com): * status: new => closed * resolution: => fixed Comment: This is resolved in ver 09 of metadata -- --------------------------------+-------------------------------- Reporter: rmohanr@cisco.com | Owner: rmohanr@cisco.com Type: enhancement | Status: closed Priority: minor | Milestone: Component: metadata | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+-------------------------------- Ticket URL: siprec From pkyzivat@alum.mit.edu Thu May 9 19:37:13 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF9621F8FDF for ; Thu, 9 May 2013 19:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.834 X-Spam-Level: X-Spam-Status: No, score=0.834 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=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 yh07W5FeEQmy for ; Thu, 9 May 2013 19:37:09 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 1253621F85E8 for ; Thu, 9 May 2013 19:37:08 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id a00w1l00J1c6gX85E2d7AZ; Fri, 10 May 2013 02:37:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id a2d71l0053ZTu2S3j2d7Aq; Fri, 10 May 2013 02:37:07 +0000 Message-ID: <518C5D53.30101@alum.mit.edu> Date: Thu, 09 May 2013 22:37:07 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368153427; bh=tPLwVvq1ir/6vw+O2sXYhpOjyOH5hsUQrZu0Kzvor5E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lK1QbPvE2Hy/GWks7n7jdIcqg0P6hqPR4xTbKL3gQzZb8QFjZ0chWNwwckql9hfV/ O0F4hoi/Dd7y0cxHO/DfDq/wPGPIkYjsb9MXFuomTaD0hyeh0In/CG1DpRv5jXLTr8 Mi0yHN6m+w1qcpBV6YQewMPDSBwealCSd83rw53rXAev7PJYsUy9rBKcdHeRbRVx/p sOlnCvCOoW8rLgm1iuSGzXL3XS276L/FLfo0ksqVYr13y36bx4Xk5UTGf/ROuLLCXd PMMJ1okB+VkaFUzstfEx7sd5r5MdHOdifOnAtgDSYLLtseQKW9PvVgRuG4/dVpOur+ sfdc05rhN/0Nw== 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: Fri, 10 May 2013 02:37:14 -0000 WFM On 5/9/13 2:30 AM, Ram Mohan R (rmohanr) wrote: > Hi Charles, > > Sorry for delay. Please see inline > >> On 04/05/13 10:09 AM, "Charles Eckel (eckelcu)" >> wrote: > >> Hi Ram, >> >> My thinking on this is that we should use changing of the direction of >> media descriptions in the RS from sendonly to inactive and vice versa to >> indicate stopping/starting the recording of the associated media stream >> as a whole. This does not imply anything about the state of the media in >> the CS. > > I gave some thought about this and I tend to agree with you that we could > use the SDP direction attribute of RS to indicate stop/re-start the > recording of media represented by that m-line. Now how an SRC decides to > start/stop should be left outside the scope of SIPREC and may be dictated > by a policy. > >> A hold/resume of the CS could result in the SRC deciding to stop the >> recording, but this is not necessarily the case. The SRC could let the >> recording continue, and indicate in XML which participants in the CS are >> actively contributing media. > > To represent hold/resume or any other change in CS media, we could still > do with the existing metadata XML. We could use the and XML > elements of a to indicate whether a participant is sending > media/not sending a particular media stream whose properties are > represented by element. Note with this we only convey if a > participant is sending/not sending media but an SRC still cannot convey > why a CS participant is not sending media(like hold e.t.c). I don't think > an SRC can really know this, all it can leo is by looking at CS signaling > SDP and learn the direction attributes of media and send a snapshot > metadata which has the information on participant sending/not sending a > particular media stream. > > For example, in your below case for a two party call if one participant > Alice puts the call on hold by sending a SDP with a=sendonly and Bob > responds with a=recvonly then a snapshot of metadata at that instance from > SRC to SRS would look as below. Assume here a snapshot was sent initially > with both participants having to the two streams: > > Snapshot sent from SRC to SRS after initial RS setup. > > F1 INVITE SRC --------------> SRS > > Content-Type: application/SDP > ... > m=audio 49170 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=label:96 > a=sendonly > ... > > m=audio 51372 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=label:97 > a=sendonly > > .... > > > complete > > 2010-12-16T23:41:07Z > > participant_id="srfBElmCRp2QB23b7Mpk0w=="> > > Alice > > > participant_id="srfBElmCRp2QB23b7Mpk0w==" > session_id="hVpd7YQgRW2nD22h7q60JQ=="> > 2013-05-09T23:41:07Z > > participant_id="srfBElmCRp2QB23b7Mpk0w=="> > i1Pz3to5hGk8fuXl+PbwCw== > 8zc6e0lYTlWIINA6GR+3ag== > > participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> > > Bob > > > participant="zSfPoSvdSDCmU3A3TRDxAw==" > session_id="hVpd7YQgRW2nD22h7q60JQ=="> > 2013-05-09T23:42:07Z > > participant="zSfPoSvdSDCmU3A3TRDxAw=="> > 8zc6e0lYTlWIINA6GR+3ag== > i1Pz3to5hGk8fuXl+PbwCw== > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > session="zSfPoSvdSDCmU3A3TRDxAw=="> > > > > > > > Partial metadata Snapshot sent when Alice puts Bob on hold: > > F2 INVITE SRC --------------> SRS > > Content-Type: application/SDP > ... > m=audio 49170 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=label:96 > a=sendonly > ... > > m=audio 51372 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=label:97 > a=sendonly > > > > Partial Snapshot after Alice resumes with Bob > > > partial > participant_id="srfBElmCRp2QB23b7Mpk0w=="> > i1Pz3to5hGk8fuXl+PbwCw== > > participant="zSfPoSvdSDCmU3A3TRDxAw=="> > i1Pz3to5hGk8fuXl+PbwCw== > > > > Here in the above snapshot the absence of for participant_id > srfBElmCRp2QB23b7Mpk0w== (Alice) could be used to indicate that Alice is > only sending media and not receiving any thing. Same way for Bob. > > Partial metadata Snapshot sent when Alice resumes call with Bob: > > F3 INVITE SRC --------------> SRS > > Content-Type: application/SDP > ... > m=audio 49170 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=label:96 > a=sendonly > ... > > m=audio 51372 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=label:97 > a=sendonly > > > > partial > participant_id="srfBElmCRp2QB23b7Mpk0w=="> > i1Pz3to5hGk8fuXl+PbwCw== > 8zc6e0lYTlWIINA6GR+3ag== > > participant="zSfPoSvdSDCmU3A3TRDxAw=="> > 8zc6e0lYTlWIINA6GR+3ag== > i1Pz3to5hGk8fuXl+PbwCw== > > > > > Here in the above snapshot both Alice and Bob send and recv streams. > > Note the above approach would work for all cases (stream mixed from SRC to > SRS or one of the endpoint is Focus in which case SRC received mixed > streams e.t.c). In all the flows the presence /absence of and > tags could be used to indicate whether a participant is > contributing to a stream or not and whether it is receiving a stream or > not. > > Let me know if this approach is fine and if this works for every one in > the WG. > > Regards, > Ram > >> As an example, if the CS is a two party call, a hold of the CS might >> result in the SRC stopping/pausing the recording. If it is a conference >> call, one party going on hold would have might have no effect on the >> direction of the media descriptions in the RS, but may result in the >> generation of some XML indicating that a specific participant is no >> longer contributing any media. I thought the existing XML allowed for >> this, but perhaps I am mistaken about that? >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Ram Mohan R (rmohanr) >>> Sent: Wednesday, May 01, 2013 8:21 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>> >>> A question here: >>> >>> In the current metadata draft to indicate CS hold/resume from SRC to >>> SRS >>> we re-use the SIP/SDP semantics and indicate the same with >>> a=inactive/a=sendonly respectively. >>> In the below discussion, I see we want to give a special meaning for >>> a=inactive/a=sendonly sent from SRC to SRS. This would mean CS >>> hold / >>> resume cannot be indicated using SDP semantics from SRC to SRS as >>> the SRS >>> cannot differentiate between CS hold/resume and Recording >>> stop/resume if >>> we use the same semantics for both. >>> >>> The current metadata XML draft does not have any means to indicate >>> CS >>> hold/resume in XML. The general approach followed in the metadata >>> (as a >>> result of past feedback received) is to re-use SIP/SDP semantics >>> wherever >>> possible to represent metadata attributes and have XML >>> representation for >>> only those attributes that does not have a semantics in SIP/SDP to >>> represent. And hence the current draft re-uses SDP semantics to >>> represent >>> CS HOLD/RESUME. >>> >>> I want to hear feedback on - if the WG wants CSC hold/resume to be >>> represented in XML ? >>> >>> Ram >>> >>> >>>> On 01/05/13 1:10 PM, "Hutton, Andrew" >>>> wrote: >>> >>>> My view is that this is enough of an issue to make it a MUST as you >>> say >>>> the fact that this would result in a misunderstanding and therefore >>>> probably a trouble ticket being raised against the implementation >>> is >>>> reason enough. >>>> >>>> Andy >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] >>>>> Sent: 01 May 2013 05:39 >>>>> To: Alan Johnston; Hutton, Andrew >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>>>> >>>>> The only interop issue this can cause is an SRS would mistaken a >>> hold >>>>> as pause/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" >>> >>>> enterprise.com> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 Fri May 10 04:12:46 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 17DC721F8FED for ; Fri, 10 May 2013 04:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=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 5eSMMQShKtok for ; Fri, 10 May 2013 04:12:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EC65E21F8F25 for ; Fri, 10 May 2013 04:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15599; q=dns/txt; s=iport; t=1368184361; x=1369393961; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=vOnxxH7yE7GGIbwH9xd21YRl3/tiFxQ0uhH7O027e7Y=; b=KskYX5swJaGzjKz7xEgoIlCHTmt/uCnPrklACybx7H+Yr//7qYXNunJ8 NusgjxKiIaijZZlIJNDfK0mJ5blogZnKzI0UB0KVwzUVp9RDzFYTsmRNg 4mB1GrNf0n6BHtyAMQht4+eWIoGVjBfF5e7eTLXvJ6IfO3ZlI+JZAlk5e 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFABfVjFGtJXG8/2dsb2JhbABSgwc3wAx/Fm0Hgh8BAQEDAQEBASQTLgYQBwYBCBEDAQEBAQoUCSgGCxQJCAIEEwiHcgMJBgydb5dwDYgyjFKBLnUCBjICBIJuYQOVSIMKim2FIoMPgWkGHho X-IronPort-AV: E=Sophos;i="4.87,647,1363132800"; d="scan'208";a="208783230" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 10 May 2013 11:12:40 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4ABCetZ025696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 10 May 2013 11:12:40 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.52]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 10 May 2013 06:12:39 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOTW9Idkikm4vM2U6dYsAzh2L9ow== Date: Fri, 10 May 2013 11:12:38 +0000 Message-ID: In-Reply-To: <518C5D53.30101@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.191.57] Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Fri, 10 May 2013 11:12:46 -0000 Let me know if others have any concern with this proposal before 5/17. If no concern I will go ahead and update the metadata draft with text and call-flow draft with examples to have the below notation for pause/resume and CS hold/CS resume indication. Regards, Ram > On 10/05/13 8:07 AM, "Paul Kyzivat" wrote: >WFM > >On 5/9/13 2:30 AM, Ram Mohan R (rmohanr) wrote: >> Hi Charles, >> >> Sorry for delay. Please see inline >> >>> On 04/05/13 10:09 AM, "Charles Eckel (eckelcu)" >>> wrote: >> >>> Hi Ram, >>> >>> My thinking on this is that we should use changing of the direction of >>> media descriptions in the RS from sendonly to inactive and vice versa >>>to >>> indicate stopping/starting the recording of the associated media stream >>> as a whole. This does not imply anything about the state of the media >>>in >>> the CS. >> >> I gave some thought about this and I tend to agree with you that we >>could >> use the SDP direction attribute of RS to indicate stop/re-start the >> recording of media represented by that m-line. Now how an SRC decides to >> start/stop should be left outside the scope of SIPREC and may be >>dictated >> by a policy. >> >>> A hold/resume of the CS could result in the SRC deciding to stop the >>> recording, but this is not necessarily the case. The SRC could let the >>> recording continue, and indicate in XML which participants in the CS >>>are >>> actively contributing media. >> >> To represent hold/resume or any other change in CS media, we could still >> do with the existing metadata XML. We could use the and >>XML >> elements of a to indicate whether a participant is sending >> media/not sending a particular media stream whose properties are >> represented by element. Note with this we only convey if a >> participant is sending/not sending media but an SRC still cannot convey >> why a CS participant is not sending media(like hold e.t.c). I don't >>think >> an SRC can really know this, all it can leo is by looking at CS >>signaling >> SDP and learn the direction attributes of media and send a snapshot >> metadata which has the information on participant sending/not sending a >> particular media stream. >> >> For example, in your below case for a two party call if one participant >> Alice puts the call on hold by sending a SDP with a=3Dsendonly and Bob >> responds with a=3Drecvonly then a snapshot of metadata at that instance >>from >> SRC to SRS would look as below. Assume here a snapshot was sent >>initially >> with both participants having to the two streams: >> >> Snapshot sent from SRC to SRS after initial RS setup. >> >> F1 INVITE SRC --------------> SRS >> >> Content-Type: application/SDP >> ... >> m=3Daudio 49170 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:96 >> a=3Dsendonly >> ... >> >> m=3Daudio 51372 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:97 >> a=3Dsendonly >> >> .... >> >> >> complete >> >> 2010-12-16T23:41:07Z >> >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> >> >> Alice >> >> >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" >> session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> >> 2013-05-09T23:41:07Z >> >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D >> >> > participant_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> Bob >> >> >> > participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" >> session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> >> 2013-05-09T23:42:07Z >> >> > participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> >> > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> >> >> >> > session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >> >> >> >> Partial metadata Snapshot sent when Alice puts Bob on hold: >> >> F2 INVITE SRC --------------> SRS >> >> Content-Type: application/SDP >> ... >> m=3Daudio 49170 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:96 >> a=3Dsendonly >> ... >> >> m=3Daudio 51372 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:97 >> a=3Dsendonly >> >> >> >> Partial Snapshot after Alice resumes with Bob >> >> >> partial >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> >> > participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> >> >> >> Here in the above snapshot the absence of for participant_id >> srfBElmCRp2QB23b7Mpk0w=3D=3D (Alice) could be used to indicate that Alic= e is >> only sending media and not receiving any thing. Same way for Bob. >> >> Partial metadata Snapshot sent when Alice resumes call with Bob: >> >> F3 INVITE SRC --------------> SRS >> >> Content-Type: application/SDP >> ... >> m=3Daudio 49170 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:96 >> a=3Dsendonly >> ... >> >> m=3Daudio 51372 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:97 >> a=3Dsendonly >> >> >> >> partial >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D >> >> > participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> >> >> >> >> Here in the above snapshot both Alice and Bob send and recv streams. >> >> Note the above approach would work for all cases (stream mixed from SRC >>to >> SRS or one of the endpoint is Focus in which case SRC received mixed >> streams e.t.c). In all the flows the presence /absence of and >> tags could be used to indicate whether a participant is >> contributing to a stream or not and whether it is receiving a stream or >> not. >> >> Let me know if this approach is fine and if this works for every one in >> the WG. >> >> Regards, >> Ram >> >>> As an example, if the CS is a two party call, a hold of the CS might >>> result in the SRC stopping/pausing the recording. If it is a conference >>> call, one party going on hold would have might have no effect on the >>> direction of the media descriptions in the RS, but may result in the >>> generation of some XML indicating that a specific participant is no >>> longer contributing any media. I thought the existing XML allowed for >>> this, but perhaps I am mistaken about that? >>> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Ram Mohan R (rmohanr) >>>> Sent: Wednesday, May 01, 2013 8:21 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>>> >>>> A question here: >>>> >>>> In the current metadata draft to indicate CS hold/resume from SRC to >>>> SRS >>>> we re-use the SIP/SDP semantics and indicate the same with >>>> a=3Dinactive/a=3Dsendonly respectively. >>>> In the below discussion, I see we want to give a special meaning for >>>> a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS >>>> hold / >>>> resume cannot be indicated using SDP semantics from SRC to SRS as >>>> the SRS >>>> cannot differentiate between CS hold/resume and Recording >>>> stop/resume if >>>> we use the same semantics for both. >>>> >>>> The current metadata XML draft does not have any means to indicate >>>> CS >>>> hold/resume in XML. The general approach followed in the metadata >>>> (as a >>>> result of past feedback received) is to re-use SIP/SDP semantics >>>> wherever >>>> possible to represent metadata attributes and have XML >>>> representation for >>>> only those attributes that does not have a semantics in SIP/SDP to >>>> represent. And hence the current draft re-uses SDP semantics to >>>> represent >>>> CS HOLD/RESUME. >>>> >>>> I want to hear feedback on - if the WG wants CSC hold/resume to be >>>> represented in XML ? >>>> >>>> Ram >>>> >>>> >>>>> On 01/05/13 1:10 PM, "Hutton, Andrew" >>>>> wrote: >>>> >>>>> My view is that this is enough of an issue to make it a MUST as you >>>> say >>>>> the fact that this would result in a misunderstanding and therefore >>>>> probably a trouble ticket being raised against the implementation >>>> is >>>>> reason enough. >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] >>>>>> Sent: 01 May 2013 05:39 >>>>>> To: Alan Johnston; Hutton, Andrew >>>>>> Cc: siprec@ietf.org >>>>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>>>>> >>>>>> The only interop issue this can cause is an SRS would mistaken a >>>> hold >>>>>> as pause/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" >>>> >>>>> enterprise.com> 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=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. Med= ia >>>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From henry.lum@genesyslab.com Mon May 13 11:17:00 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE8621F87B1 for ; Mon, 13 May 2013 11:17:00 -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=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=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 o40tnOYdT4jX for ; Mon, 13 May 2013 11:16:56 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id E9DA721F8545 for ; Mon, 13 May 2013 11:16:52 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Mon, 13 May 2013 14:16:49 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 13 May 2013 11:16:48 -0700 From: Henry Lum To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgACS/YCAAG94YYAAMcNQgAHAF4CAAzq6gIAH+mcAgAFRQYCAAJAJAIAEuCGA Date: Mon, 13 May 2013 18:16:47 +0000 Message-ID: References: <518C5D53.30101@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.77] MIME-Version: 1.0 X-MC-Unique: 113051314165001201 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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: Mon, 13 May 2013 18:17:01 -0000 This works for me. Thanks Henry -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: May-10-13 7:13 AM To: siprec@ietf.org Subject: Re: [siprec] CS hold/resume clarification in protocol draft Let me know if others have any concern with this proposal before 5/17. If no concern I will go ahead and update the metadata draft with text and call-flow draft with examples to have the below notation for pause/resume and CS hold/CS resume indication. Regards, Ram > On 10/05/13 8:07 AM, "Paul Kyzivat" wrote: >WFM > >On 5/9/13 2:30 AM, Ram Mohan R (rmohanr) wrote: >> Hi Charles, >> >> Sorry for delay. Please see inline >> >>> On 04/05/13 10:09 AM, "Charles Eckel (eckelcu)" >>> wrote: >> >>> Hi Ram, >>> >>> My thinking on this is that we should use changing of the direction of >>> media descriptions in the RS from sendonly to inactive and vice versa >>>to >>> indicate stopping/starting the recording of the associated media stream >>> as a whole. This does not imply anything about the state of the media >>>in >>> the CS. >> >> I gave some thought about this and I tend to agree with you that we >>could >> use the SDP direction attribute of RS to indicate stop/re-start the >> recording of media represented by that m-line. Now how an SRC decides to >> start/stop should be left outside the scope of SIPREC and may be >>dictated >> by a policy. >> >>> A hold/resume of the CS could result in the SRC deciding to stop the >>> recording, but this is not necessarily the case. The SRC could let the >>> recording continue, and indicate in XML which participants in the CS >>>are >>> actively contributing media. >> >> To represent hold/resume or any other change in CS media, we could still >> do with the existing metadata XML. We could use the and >>XML >> elements of a to indicate whether a participant is sending >> media/not sending a particular media stream whose properties are >> represented by element. Note with this we only convey if a >> participant is sending/not sending media but an SRC still cannot convey >> why a CS participant is not sending media(like hold e.t.c). I don't >>think >> an SRC can really know this, all it can leo is by looking at CS >>signaling >> SDP and learn the direction attributes of media and send a snapshot >> metadata which has the information on participant sending/not sending a >> particular media stream. >> >> For example, in your below case for a two party call if one participant >> Alice puts the call on hold by sending a SDP with a=3Dsendonly and Bob >> responds with a=3Drecvonly then a snapshot of metadata at that instance >>from >> SRC to SRS would look as below. Assume here a snapshot was sent >>initially >> with both participants having to the two streams: >> >> Snapshot sent from SRC to SRS after initial RS setup. >> >> F1 INVITE SRC --------------> SRS >> >> Content-Type: application/SDP >> ... >> m=3Daudio 49170 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:96 >> a=3Dsendonly >> ... >> >> m=3Daudio 51372 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:97 >> a=3Dsendonly >> >> .... >> >> >> complete >> >> 2010-12-16T23:41:07Z >> >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> >> >> Alice >> >> >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" >> session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> >> 2013-05-09T23:41:07Z >> >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D >> >> > participant_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> Bob >> >> >> > participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" >> session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> >> 2013-05-09T23:42:07Z >> >> > participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> >> > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> >> >> >> > session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >> >> >> >> Partial metadata Snapshot sent when Alice puts Bob on hold: >> >> F2 INVITE SRC --------------> SRS >> >> Content-Type: application/SDP >> ... >> m=3Daudio 49170 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:96 >> a=3Dsendonly >> ... >> >> m=3Daudio 51372 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:97 >> a=3Dsendonly >> >> >> >> Partial Snapshot after Alice resumes with Bob >> >> >> partial >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> >> > participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> >> >> >> Here in the above snapshot the absence of for participant_id >> srfBElmCRp2QB23b7Mpk0w=3D=3D (Alice) could be used to indicate that Alic= e is >> only sending media and not receiving any thing. Same way for Bob. >> >> Partial metadata Snapshot sent when Alice resumes call with Bob: >> >> F3 INVITE SRC --------------> SRS >> >> Content-Type: application/SDP >> ... >> m=3Daudio 49170 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:96 >> a=3Dsendonly >> ... >> >> m=3Daudio 51372 RTP/AVP 0 >> a=3Drtpmap:0 PCMU/8000 >> a=3Dlabel:97 >> a=3Dsendonly >> >> >> >> partial >> > participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D >> >> > participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D >> >> >> >> >> Here in the above snapshot both Alice and Bob send and recv streams. >> >> Note the above approach would work for all cases (stream mixed from SRC >>to >> SRS or one of the endpoint is Focus in which case SRC received mixed >> streams e.t.c). In all the flows the presence /absence of and >> tags could be used to indicate whether a participant is >> contributing to a stream or not and whether it is receiving a stream or >> not. >> >> Let me know if this approach is fine and if this works for every one in >> the WG. >> >> Regards, >> Ram >> >>> As an example, if the CS is a two party call, a hold of the CS might >>> result in the SRC stopping/pausing the recording. If it is a conference >>> call, one party going on hold would have might have no effect on the >>> direction of the media descriptions in the RS, but may result in the >>> generation of some XML indicating that a specific participant is no >>> longer contributing any media. I thought the existing XML allowed for >>> this, but perhaps I am mistaken about that? >>> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Ram Mohan R (rmohanr) >>>> Sent: Wednesday, May 01, 2013 8:21 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>>> >>>> A question here: >>>> >>>> In the current metadata draft to indicate CS hold/resume from SRC to >>>> SRS >>>> we re-use the SIP/SDP semantics and indicate the same with >>>> a=3Dinactive/a=3Dsendonly respectively. >>>> In the below discussion, I see we want to give a special meaning for >>>> a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS >>>> hold / >>>> resume cannot be indicated using SDP semantics from SRC to SRS as >>>> the SRS >>>> cannot differentiate between CS hold/resume and Recording >>>> stop/resume if >>>> we use the same semantics for both. >>>> >>>> The current metadata XML draft does not have any means to indicate >>>> CS >>>> hold/resume in XML. The general approach followed in the metadata >>>> (as a >>>> result of past feedback received) is to re-use SIP/SDP semantics >>>> wherever >>>> possible to represent metadata attributes and have XML >>>> representation for >>>> only those attributes that does not have a semantics in SIP/SDP to >>>> represent. And hence the current draft re-uses SDP semantics to >>>> represent >>>> CS HOLD/RESUME. >>>> >>>> I want to hear feedback on - if the WG wants CSC hold/resume to be >>>> represented in XML ? >>>> >>>> Ram >>>> >>>> >>>>> On 01/05/13 1:10 PM, "Hutton, Andrew" >>>>> wrote: >>>> >>>>> My view is that this is enough of an issue to make it a MUST as you >>>> say >>>>> the fact that this would result in a misunderstanding and therefore >>>>> probably a trouble ticket being raised against the implementation >>>> is >>>>> reason enough. >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] >>>>>> Sent: 01 May 2013 05:39 >>>>>> To: Alan Johnston; Hutton, Andrew >>>>>> Cc: siprec@ietf.org >>>>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft >>>>>> >>>>>> The only interop issue this can cause is an SRS would mistaken a >>>> hold >>>>>> as pause/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" >>>> >>>>> enterprise.com> 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=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. Med= ia >>>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Wed May 15 12:25:20 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 BCD7A1F0D30 for ; Wed, 15 May 2013 12:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=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 wDkizaWMm4e7 for ; Wed, 15 May 2013 12:25:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A7AFC1F0D11 for ; Wed, 15 May 2013 12:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17528; q=dns/txt; s=iport; t=1368645915; x=1369855515; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3+U0PUooUOlRw3Tzz3FO1raMzkYAqeJYimipxVNaWH8=; b=aDhP8FIPlET9gYlv/IkXqtjwuUUWzHnKCG/zdE6puTVY1AeO4AI5bQpQ 5gplHuC84oL8HWPVDMedaS/XMLAwIxh4oI7JWksII3tK9H6DCqBOUy5ac u4Q+W22tONBvV8OcSf07Hg0ZZBOG6HVAmC66iQzUtBUgvK534Q9vuYzB6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAPvfk1GtJXG8/2dsb2JhbABbgwc3wFd9FnSCHwEBAQQBAQEkEy4GFwQCAQgRAwEBAQEKFAkHIQYLFAkIAgQBEgiHcgMOAQy0Vw2IUYxIgS53BjICBIJuYQOVT4MNinKFI4MQgWkGHho X-IronPort-AV: E=Sophos;i="4.87,678,1363132800"; d="scan'208";a="210970375" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 15 May 2013 19:25:14 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4FJPEOV030556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 19:25:14 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.28]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 15 May 2013 14:25:14 -0500 From: "Charles Eckel (eckelcu)" To: Henry Lum , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgABxdoCAAOTQAIAAMpaAgAFJ7ICAAja1gIAI/mwAgAFRQYCAAJAJAIAFLYCAgALjtRA= Date: Wed, 15 May 2013 19:25:14 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882804833F39@xmb-aln-x08.cisco.com> References: <518C5D53.30101@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.44] 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: Wed, 15 May 2013 19:25:20 -0000 Me too. Thanks for the detailed example Ram. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of > Henry Lum > Sent: Monday, May 13, 2013 11:17 AM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] CS hold/resume clarification in protocol draft >=20 > This works for me. >=20 > Thanks > Henry >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of > Ram Mohan R (rmohanr) > Sent: May-10-13 7:13 AM > To: siprec@ietf.org > Subject: Re: [siprec] CS hold/resume clarification in protocol draft >=20 > Let me know if others have any concern with this proposal before 5/17. >=20 > If no concern I will go ahead and update the metadata draft with text and > call-flow draft with examples to have the below notation for pause/resume > and CS hold/CS resume indication. >=20 > Regards, > Ram >=20 > > On 10/05/13 8:07 AM, "Paul Kyzivat" wrote: >=20 > >WFM > > > >On 5/9/13 2:30 AM, Ram Mohan R (rmohanr) wrote: > >> Hi Charles, > >> > >> Sorry for delay. Please see inline > >> > >>> On 04/05/13 10:09 AM, "Charles Eckel (eckelcu)" > >>> wrote: > >> > >>> Hi Ram, > >>> > >>> My thinking on this is that we should use changing of the direction o= f > >>> media descriptions in the RS from sendonly to inactive and vice versa > >>>to > >>> indicate stopping/starting the recording of the associated media stre= am > >>> as a whole. This does not imply anything about the state of the media > >>>in > >>> the CS. > >> > >> I gave some thought about this and I tend to agree with you that we > >>could > >> use the SDP direction attribute of RS to indicate stop/re-start the > >> recording of media represented by that m-line. Now how an SRC decides = to > >> start/stop should be left outside the scope of SIPREC and may be > >>dictated > >> by a policy. > >> > >>> A hold/resume of the CS could result in the SRC deciding to stop the > >>> recording, but this is not necessarily the case. The SRC could let th= e > >>> recording continue, and indicate in XML which participants in the CS > >>>are > >>> actively contributing media. > >> > >> To represent hold/resume or any other change in CS media, we could sti= ll > >> do with the existing metadata XML. We could use the and > >>XML > >> elements of a to indicate whether a participant is sendi= ng > >> media/not sending a particular media stream whose properties are > >> represented by element. Note with this we only convey if a > >> participant is sending/not sending media but an SRC still cannot conve= y > >> why a CS participant is not sending media(like hold e.t.c). I don't > >>think > >> an SRC can really know this, all it can leo is by looking at CS > >>signaling > >> SDP and learn the direction attributes of media and send a snapshot > >> metadata which has the information on participant sending/not sending = a > >> particular media stream. > >> > >> For example, in your below case for a two party call if one participan= t > >> Alice puts the call on hold by sending a SDP with a=3Dsendonly and Bo= b > >> responds with a=3Drecvonly then a snapshot of metadata at that instanc= e > >>from > >> SRC to SRS would look as below. Assume here a snapshot was sent > >>initially > >> with both participants having to the two streams: > >> > >> Snapshot sent from SRC to SRS after initial RS setup. > >> > >> F1 INVITE SRC --------------> SRS > >> > >> Content-Type: application/SDP > >> ... > >> m=3Daudio 49170 RTP/AVP 0 > >> a=3Drtpmap:0 PCMU/8000 > >> a=3Dlabel:96 > >> a=3Dsendonly > >> ... > >> > >> m=3Daudio 51372 RTP/AVP 0 > >> a=3Drtpmap:0 PCMU/8000 > >> a=3Dlabel:97 > >> a=3Dsendonly > >> > >> .... > >> > >> > >> complete > >> > >> 2010-12-16T23:41:07Z > >> > >> >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> > >> > >> Alice > >> > >> > >> >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > >> session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > >> 2013-05-09T23:41:07Z > >> > >> >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D > >> > >> >> participant_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > >> > >> Bob > >> > >> > >> >> participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > >> session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > >> 2013-05-09T23:42:07Z > >> > >> >> participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > >> > >> >> session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > >> > >> > >> >> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > >> > >> > >> > >> > >> > >> > >> Partial metadata Snapshot sent when Alice puts Bob on hold: > >> > >> F2 INVITE SRC --------------> SRS > >> > >> Content-Type: application/SDP > >> ... > >> m=3Daudio 49170 RTP/AVP 0 > >> a=3Drtpmap:0 PCMU/8000 > >> a=3Dlabel:96 > >> a=3Dsendonly > >> ... > >> > >> m=3Daudio 51372 RTP/AVP 0 > >> a=3Drtpmap:0 PCMU/8000 > >> a=3Dlabel:97 > >> a=3Dsendonly > >> > >> > >> > >> Partial Snapshot after Alice resumes with Bob > >> > >> > >> partial > >> >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > >> > >> >> participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > >> > >> > >> > >> Here in the above snapshot the absence of for participant_id > >> srfBElmCRp2QB23b7Mpk0w=3D=3D (Alice) could be used to indicate that Al= ice is > >> only sending media and not receiving any thing. Same way for Bob. > >> > >> Partial metadata Snapshot sent when Alice resumes call with Bob: > >> > >> F3 INVITE SRC --------------> SRS > >> > >> Content-Type: application/SDP > >> ... > >> m=3Daudio 49170 RTP/AVP 0 > >> a=3Drtpmap:0 PCMU/8000 > >> a=3Dlabel:96 > >> a=3Dsendonly > >> ... > >> > >> m=3Daudio 51372 RTP/AVP 0 > >> a=3Drtpmap:0 PCMU/8000 > >> a=3Dlabel:97 > >> a=3Dsendonly > >> > >> > >> > >> partial > >> >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D > >> > >> >> participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > >> > >> > >> > >> > >> Here in the above snapshot both Alice and Bob send and recv streams. > >> > >> Note the above approach would work for all cases (stream mixed from SR= C > >>to > >> SRS or one of the endpoint is Focus in which case SRC received mixed > >> streams e.t.c). In all the flows the presence /absence of and > >> tags could be used to indicate whether a participant is > >> contributing to a stream or not and whether it is receiving a stream o= r > >> not. > >> > >> Let me know if this approach is fine and if this works for every one i= n > >> the WG. > >> > >> Regards, > >> Ram > >> > >>> As an example, if the CS is a two party call, a hold of the CS might > >>> result in the SRC stopping/pausing the recording. If it is a conferen= ce > >>> call, one party going on hold would have might have no effect on the > >>> direction of the media descriptions in the RS, but may result in the > >>> generation of some XML indicating that a specific participant is no > >>> longer contributing any media. I thought the existing XML allowed for > >>> this, but perhaps I am mistaken about that? > >>> > >>> Cheers, > >>> Charles > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Ram Mohan R (rmohanr) > >>>> Sent: Wednesday, May 01, 2013 8:21 PM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft > >>>> > >>>> A question here: > >>>> > >>>> In the current metadata draft to indicate CS hold/resume from SRC to > >>>> SRS > >>>> we re-use the SIP/SDP semantics and indicate the same with > >>>> a=3Dinactive/a=3Dsendonly respectively. > >>>> In the below discussion, I see we want to give a special meaning for > >>>> a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS > >>>> hold / > >>>> resume cannot be indicated using SDP semantics from SRC to SRS as > >>>> the SRS > >>>> cannot differentiate between CS hold/resume and Recording > >>>> stop/resume if > >>>> we use the same semantics for both. > >>>> > >>>> The current metadata XML draft does not have any means to indicate > >>>> CS > >>>> hold/resume in XML. The general approach followed in the metadata > >>>> (as a > >>>> result of past feedback received) is to re-use SIP/SDP semantics > >>>> wherever > >>>> possible to represent metadata attributes and have XML > >>>> representation for > >>>> only those attributes that does not have a semantics in SIP/SDP to > >>>> represent. And hence the current draft re-uses SDP semantics to > >>>> represent > >>>> CS HOLD/RESUME. > >>>> > >>>> I want to hear feedback on - if the WG wants CSC hold/resume to be > >>>> represented in XML ? > >>>> > >>>> Ram > >>>> > >>>> > >>>>> On 01/05/13 1:10 PM, "Hutton, Andrew" > >>>>> wrote: > >>>> > >>>>> My view is that this is enough of an issue to make it a MUST as you > >>>> say > >>>>> the fact that this would result in a misunderstanding and therefore > >>>>> probably a trouble ticket being raised against the implementation > >>>> is > >>>>> reason enough. > >>>>> > >>>>> Andy > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] > >>>>>> Sent: 01 May 2013 05:39 > >>>>>> To: Alan Johnston; Hutton, Andrew > >>>>>> Cc: siprec@ietf.org > >>>>>> Subject: Re: [siprec] CS hold/resume clarification in protocol dra= ft > >>>>>> > >>>>>> The only interop issue this can cause is an SRS would mistaken a > >>>> hold > >>>>>> as pause/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 dra= ft > >>>>>> > >>>>>> > >>>>>> 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" > >>>> >>>>>> enterprise.com> 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=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. M= edia > >>>>>>>> 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 > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu May 16 12:55:54 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB13811E80AE for ; Thu, 16 May 2013 12:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=0.163, 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 KjGMqtdaKAqX for ; Thu, 16 May 2013 12:55:50 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id DD7E611E80A5 for ; Thu, 16 May 2013 12:55:49 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id cffu1l0071ei1Bg59jvoVB; Thu, 16 May 2013 19:55:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id cjvo1l0053ZTu2S3kjvouf; Thu, 16 May 2013 19:55:48 +0000 Message-ID: <519539C2.4010005@alum.mit.edu> Date: Thu, 16 May 2013 15:55:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "siprec@ietf.org" References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> In-Reply-To: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368734148; bh=Jt0MvmyYsNyBy/7rj05dlVel2ByHvVKSCCCp9GY4OEo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DacfY8f9Z3ts+RO0N9ffpzG4FlKGp87GEV/qKbDTDGYQOCMsxrzsfhkZ0LdK9lI2T e94kFrGUMJ8sqJwevpnBbPXGr8TK6g2OovD+Di0kPdvl79ztsGaxwIRs4HMHMN2Yte NXMh5IyKiAP8OcHgfkU6Wf/iUjYa9g+MefQ2h7tSTNoh+NOV29noA3Uo0nkgpo6VZ0 kTQnFvyjHhahN18ThNWQDJ+WkGdNmIAgFti1pw8ii/3Hs0b6SKTL7uc22hQdvsRF5V qcwbKpVInzWTtSEVIU+ZGOQK1ntjemUArKsEWzOndvt6se0jPfTngFFC6VU25Zt0Y8 vUaKhaBPSezqA== Subject: [siprec] Proposal for follow-on siprec work 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, 16 May 2013 19:55:54 -0000 siprec'ers: I hope I'm not getting ahead of myself, but I *think* we are almost done with the current round of siprec work. While we need to finish it, I also think we need to be thinking about "what next". Michael Yan and I have just posted a new draft proposing some new siprec functionality that we would like to see. We are looking to assess the interest in this. The draft is intentionally somewhat vague, reflecting its preliminary status. We want to refine it based on interest from the community. I can imagine refining it in two ways: - deepening it with more detail about the functionality mentioned - broadening it with additional functionality that others feel is currently lacking from siprec. I'm posting this message to siprec, where I know there is a built-in community of interest. But IIUC the actual process for adopting new work of this sort will be to go back through dispatch. So I'll probably also be posting a similar message to the dispatch mailing list. Please, we want to hear from you! Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-kyzivat-siprec-webconf-use-case-00.txt Date: Thu, 16 May 2013 12:41:28 -0700 From: internet-drafts@ietf.org To: Paul H. Kyzivat , Michael Yan , Paul Kyzivat A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt has been successfully submitted by Paul H. Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-siprec-webconf-use-case Revision: 00 Title: Web Conference Recording Use Case Creation date: 2013-05-16 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf-use-case-00.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use-case Htmlized: http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 Abstract: The current work of SIPREC will soon finish. As its charter defined, SIPREC has covered industries like financial trading floors, contact center and emergency service bureaus. But when talking about products or solutions like data or web conferencing, SIPREC is insufficient to record all aspects of calls with different interactive media channels. This draft tries to show a use case for web conference recording and show how it can work well under SIPREC mechanism. The IETF Secretariat From gchurchouse@revcord.com Thu May 16 13:26:23 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B799611E8104 for ; Thu, 16 May 2013 13:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 OblGYS8fN9kN for ; Thu, 16 May 2013 13:26:19 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4825221F8EAD for ; Thu, 16 May 2013 13:26:19 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id t10so3613510lbi.18 for ; Thu, 16 May 2013 13:26:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:references:in-reply-to:mime-version:x-mailer :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=jgQqfNfhMO7uYla5OepBpTrM4e2WUVbSi9srvwFYWIw=; b=AdAqoDwd3M86IX9YMFWdS8UlUE8g2IDwl+SACkxyq2u3flNFbQi0FjVVyA/m7+v0/I nuDgMeqg0MZlC+Ae/cWPAecJkf0QAi7dfSanwXokXuwO8rBb7mTtEgLe4oFnndlc6vw0 NCsLrHaM1JXyvv5aKY12y8pq46ZuCPhKWRsuP0TMAJrfz5RkXuGIgB4RI9EWsa3ojo1P DtS6+C42gXJBAcb7IczyoLZWplSRvYxTQUTcmqOjcVL76+6l+E4jL476I927MR1X0HRI od2ExRV3ALjY+oeg2BrCT/TefDNZr+HsOtSVYzQ0LXbNVGak6amq1F7lsKEdphXgZYEC dKoQ== X-Received: by 10.112.161.131 with SMTP id xs3mr12129973lbb.15.1368735977969; Thu, 16 May 2013 13:26:17 -0700 (PDT) From: Guy Churchouse References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> <519539C2.4010005@alum.mit.edu> In-Reply-To: <519539C2.4010005@alum.mit.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 thread-index: AQIfhP95AZUB677L72IfG/pqpCOTwwHMrf4tmFd3TFA= Date: Thu, 16 May 2013 13:25:20 -0700 Message-ID: <625f68627c8289d9524879179ba37317@mail.gmail.com> To: Paul Kyzivat , siprec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk4xSQ7vLEL9NSo0pHhFMFs0EJRL1Jg74/TVZVwiTWF4MZ/w5fvlzfWbpJ0z0POJwytIrpX Subject: Re: [siprec] Proposal for follow-on siprec work 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, 16 May 2013 20:26:23 -0000 I very much support continuing with web conferencing recording as outlined. Guy Guy Churchouse, ENP, SSCA (SIP Certified) Book of the Month: Surfaces and Essences: Analogy as the Fuel and Fire of Thinking By: Douglas Hofstadter & Emmanuel Sander Executive Vice President REVCORD Revolutionizing Voice Recording 10575 Katy Freeway, Suite 470 Houston, Texas=A0 77024 281-404-7040=A0 Main 281-404-5323=A0 Fax 866-559-2188=A0 Toll Mobile 714-316-4952 gchurchouse.revcord Skype -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, May 16, 2013 12:56 PM To: siprec@ietf.org Subject: [siprec] Proposal for follow-on siprec work siprec'ers: I hope I'm not getting ahead of myself, but I *think* we are almost done with the current round of siprec work. While we need to finish it, I also think we need to be thinking about "what next". Michael Yan and I have just posted a new draft proposing some new siprec functionality that we would like to see. We are looking to assess the interest in this. The draft is intentionally somewhat vague, reflecting its preliminary status. We want to refine it based on interest from the community. I can imagine refining it in two ways: - deepening it with more detail about the functionality mentioned - broadening it with additional functionality that others feel is currently lacking from siprec. I'm posting this message to siprec, where I know there is a built-in community of interest. But IIUC the actual process for adopting new work of this sort will be to go back through dispatch. So I'll probably also be posting a similar message to the dispatch mailing list. Please, we want to hear from you! Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-kyzivat-siprec-webconf-use-case-00.txt Date: Thu, 16 May 2013 12:41:28 -0700 From: internet-drafts@ietf.org To: Paul H. Kyzivat , Michael Yan , Paul Kyzivat A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt has been successfully submitted by Paul H. Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-siprec-webconf-use-case Revision: 00 Title: Web Conference Recording Use Case Creation date: 2013-05-16 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf-use-case- 00.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use-case Htmlized: http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 Abstract: The current work of SIPREC will soon finish. As its charter defined, SIPREC has covered industries like financial trading floors, contact center and emergency service bureaus. But when talking about products or solutions like data or web conferencing, SIPREC is insufficient to record all aspects of calls with different interactive media channels. This draft tries to show a use case for web conference recording and show how it can work well under SIPREC mechanism. The IETF Secretariat _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu May 16 13:45:56 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 BEA8D11E8132 for ; Thu, 16 May 2013 13:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=0.144, 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 lkaER6Bc93Os for ; Thu, 16 May 2013 13:45:52 -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 DBA5411E8150 for ; Thu, 16 May 2013 13:45:51 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id cixR1l00W0EZKEL53klqQa; Thu, 16 May 2013 20:45:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id cklq1l00Z3ZTu2S3MklqLl; Thu, 16 May 2013 20:45:50 +0000 Message-ID: <5195457E.1040400@alum.mit.edu> Date: Thu, 16 May 2013 16:45:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Guy Churchouse References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> <519539C2.4010005@alum.mit.edu> <625f68627c8289d9524879179ba37317@mail.gmail.com> In-Reply-To: <625f68627c8289d9524879179ba37317@mail.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=1368737150; bh=jwJQO4ecVRo4dDSLB6FJPJZm/hW42ckYsfPEgVGxuUE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hNlHPFCgMt1aksHOGneoToRWZaDbB3jWmZOfDQzoT2cx0yaHnPH8ioAhrlnXbCf6X dWt/GQEq27x5qek9H+RrjVvhZQFfv4rXEBx9RqRE/s0V4vgDEXtncJus/cw6iFWS5e 6TtSVxqPlbC3r8xqaOM3ptmxOMsnbwt1FzmomyB1ckVjB8e4/yh9ZWjwLTFTtrGMC6 LEA7cxoVoSJlCI8RfcGabOWEH7INErLr48c14PIO5HDH6M9GMKMr9dIsJ+TD9HDe/n ynwGsP6N32Dwo0exmcugOPHEXaScLBZlBM5BEYTZMgEAQwTc44XnTFzsdq1lB9nYKU KIASpETcIXBzg== Cc: siprec@ietf.org Subject: Re: [siprec] Proposal for follow-on siprec work 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, 16 May 2013 20:45:56 -0000 On 5/16/13 4:25 PM, Guy Churchouse wrote: > I very much support continuing with web conferencing recording as > outlined. Thanks Guy! We would appreciate any suggestions you have toward refining what we have written. Thanks, Paul > Guy > > Guy Churchouse, ENP, SSCA (SIP Certified) > Book of the Month: Surfaces and Essences: Analogy as the Fuel and Fire of > Thinking By: Douglas Hofstadter & Emmanuel Sander > Executive Vice President > REVCORD Revolutionizing Voice Recording > 10575 Katy Freeway, Suite 470 > Houston, Texas 77024 > 281-404-7040 Main > 281-404-5323 Fax > 866-559-2188 Toll > Mobile 714-316-4952 > gchurchouse.revcord Skype > > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, May 16, 2013 12:56 PM > To: siprec@ietf.org > Subject: [siprec] Proposal for follow-on siprec work > > siprec'ers: > > I hope I'm not getting ahead of myself, but I *think* we are almost done > with the current round of siprec work. While we need to finish it, I also > think we need to be thinking about "what next". > > Michael Yan and I have just posted a new draft proposing some new siprec > functionality that we would like to see. We are looking to assess the > interest in this. > > The draft is intentionally somewhat vague, reflecting its preliminary > status. We want to refine it based on interest from the community. I can > imagine refining it in two ways: > > - deepening it with more detail about the functionality mentioned > - broadening it with additional functionality that others feel is > currently lacking from siprec. > > I'm posting this message to siprec, where I know there is a built-in > community of interest. But IIUC the actual process for adopting new work > of this sort will be to go back through dispatch. So I'll probably also be > posting a similar message to the dispatch mailing list. > > Please, we want to hear from you! > > Thanks, > Paul > > > -------- Original Message -------- > Subject: New Version Notification for > draft-kyzivat-siprec-webconf-use-case-00.txt > Date: Thu, 16 May 2013 12:41:28 -0700 > From: internet-drafts@ietf.org > To: Paul H. Kyzivat , Michael Yan > , Paul Kyzivat > > > A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt > has been successfully submitted by Paul H. Kyzivat and posted to the > IETF repository. > > Filename: draft-kyzivat-siprec-webconf-use-case > Revision: 00 > Title: Web Conference Recording Use Case > Creation date: 2013-05-16 > Group: Individual Submission > Number of pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf-use-case- > 00.txt > Status: > http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use-case > Htmlized: > http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 > > > Abstract: > The current work of SIPREC will soon finish. As its charter defined, > SIPREC has covered industries like financial trading floors, contact > center and emergency service bureaus. But when talking about > products or solutions like data or web conferencing, SIPREC is > insufficient to record all aspects of calls with different > interactive media channels. This draft tries to show a use case for > web conference recording and show how it can work well under SIPREC > mechanism. > > > > > > > The IETF Secretariat > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From br@brianrosen.net Thu May 16 13:51:47 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD4F11E8176 for ; Thu, 16 May 2013 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.288 X-Spam-Level: X-Spam-Status: No, score=-101.288 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, 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 sz17ZWDYH8Xf for ; Thu, 16 May 2013 13:51:43 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id F268A11E815E for ; Thu, 16 May 2013 13:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=LpGPIxK12xM8UTqA+H1y5ZR6wk0jGbHM4VD8hc0DoDM=; b=GRhKGRe7tnj0zjNPBjkDyL0JVh3P0o2mLA7VMCAETZXF7uJlDYSffwM3KKFlxobWB1JN/qbbkkxsVmpFcmTolQnIElcnyie5s8x7ApNJgTnvcTwkG00mTWZAfSQ7VkhKgCjirHanKyY4/r1EsSBzdgaAbLry6zl/1jCIYEsMEFU=; Received: from neustargw.va.neustar.com ([209.173.53.233]:32405 helo=[10.33.193.18]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ud59J-00052p-8K; Thu, 16 May 2013 16:51:41 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <5195457E.1040400@alum.mit.edu> Date: Thu, 16 May 2013 16:51:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01FA7EC0-FFB3-4808-BA6F-AD739D227068@brianrosen.net> References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> <519539C2.4010005@alum.mit.edu> <625f68627c8289d9524879179ba37317@mail.gmail.com> <5195457E.1040400@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: siprec@ietf.org Subject: Re: [siprec] Proposal for follow-on siprec work 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, 16 May 2013 20:51:47 -0000 In addition to this work, we need to extend for recording MSRP. I'll = probably contribute to a draft on that. Brian On May 16, 2013, at 4:45 PM, Paul Kyzivat wrote: > On 5/16/13 4:25 PM, Guy Churchouse wrote: >> I very much support continuing with web conferencing recording as >> outlined. >=20 > Thanks Guy! >=20 > We would appreciate any suggestions you have toward refining what we = have written. >=20 > Thanks, > Paul >=20 >> Guy >>=20 >> Guy Churchouse, ENP, SSCA (SIP Certified) >> Book of the Month: Surfaces and Essences: Analogy as the Fuel and = Fire of >> Thinking By: Douglas Hofstadter & Emmanuel Sander >> Executive Vice President >> REVCORD Revolutionizing Voice Recording >> 10575 Katy Freeway, Suite 470 >> Houston, Texas 77024 >> 281-404-7040 Main >> 281-404-5323 Fax >> 866-559-2188 Toll >> Mobile 714-316-4952 >> gchurchouse.revcord Skype >>=20 >>=20 >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf >> Of Paul Kyzivat >> Sent: Thursday, May 16, 2013 12:56 PM >> To: siprec@ietf.org >> Subject: [siprec] Proposal for follow-on siprec work >>=20 >> siprec'ers: >>=20 >> I hope I'm not getting ahead of myself, but I *think* we are almost = done >> with the current round of siprec work. While we need to finish it, I = also >> think we need to be thinking about "what next". >>=20 >> Michael Yan and I have just posted a new draft proposing some new = siprec >> functionality that we would like to see. We are looking to assess the >> interest in this. >>=20 >> The draft is intentionally somewhat vague, reflecting its preliminary >> status. We want to refine it based on interest from the community. I = can >> imagine refining it in two ways: >>=20 >> - deepening it with more detail about the functionality mentioned >> - broadening it with additional functionality that others feel is >> currently lacking from siprec. >>=20 >> I'm posting this message to siprec, where I know there is a built-in >> community of interest. But IIUC the actual process for adopting new = work >> of this sort will be to go back through dispatch. So I'll probably = also be >> posting a similar message to the dispatch mailing list. >>=20 >> Please, we want to hear from you! >>=20 >> Thanks, >> Paul >>=20 >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-kyzivat-siprec-webconf-use-case-00.txt >> Date: Thu, 16 May 2013 12:41:28 -0700 >> From: internet-drafts@ietf.org >> To: Paul H. Kyzivat , Michael Yan >> , Paul Kyzivat >>=20 >>=20 >> A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt >> has been successfully submitted by Paul H. Kyzivat and posted to the >> IETF repository. >>=20 >> Filename: draft-kyzivat-siprec-webconf-use-case >> Revision: 00 >> Title: Web Conference Recording Use Case >> Creation date: 2013-05-16 >> Group: Individual Submission >> Number of pages: 6 >> URL: >> = http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf-use-case-= >> 00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use-case >> Htmlized: >> http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 >>=20 >>=20 >> Abstract: >> The current work of SIPREC will soon finish. As its charter = defined, >> SIPREC has covered industries like financial trading floors, = contact >> center and emergency service bureaus. But when talking about >> products or solutions like data or web conferencing, SIPREC is >> insufficient to record all aspects of calls with different >> interactive media channels. This draft tries to show a use case = for >> web conference recording and show how it can work well under = SIPREC >> mechanism. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >>=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From MSmith@dss-corp.com Thu May 16 13:59: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 60E6521F8503 for ; Thu, 16 May 2013 13:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRW8HXem7pO5 for ; Thu, 16 May 2013 13:59:12 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9784711E8135 for ; Thu, 16 May 2013 13:59:12 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id hil53c0171s7 for ; Thu, 16 May 2013 17:05:57 -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; Thu, 16 May 2013 17:05:57 -0400 Received: from EXC01.dss.lan ([fe80::6540:2e8d:f781:8389]) by exc01.dss.lan ([fe80::6540:2e8d:f781:8389%16]) with mapi; Thu, 16 May 2013 16:58:37 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Proposal for follow-on siprec work Thread-Index: AQHOUm9PO5CyRQ/1YUef05ayQT2AQZkIhSgAgAAFugCAAAGggP//vp4g Date: Thu, 16 May 2013 20:58:39 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880DC02F95C6@exc01.dss.lan> References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> <519539C2.4010005@alum.mit.edu> <625f68627c8289d9524879179ba37317@mail.gmail.com> <5195457E.1040400@alum.mit.edu> <01FA7EC0-FFB3-4808-BA6F-AD739D227068@brianrosen.net> In-Reply-To: <01FA7EC0-FFB3-4808-BA6F-AD739D227068@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201305162105570075737 Subject: Re: [siprec] Proposal for follow-on siprec work 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, 16 May 2013 20:59:16 -0000 +1 on recording MSRP - and support for associated metadata. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Brian Rosen Sent: Thursday, May 16, 2013 4:52 PM To: Paul Kyzivat Cc: siprec@ietf.org Subject: Re: [siprec] Proposal for follow-on siprec work In addition to this work, we need to extend for recording MSRP. I'll proba= bly contribute to a draft on that. Brian On May 16, 2013, at 4:45 PM, Paul Kyzivat wrote: > On 5/16/13 4:25 PM, Guy Churchouse wrote: >> I very much support continuing with web conferencing recording as=20 >> outlined. >=20 > Thanks Guy! >=20 > We would appreciate any suggestions you have toward refining what we have= written. >=20 > Thanks, > Paul >=20 >> Guy >>=20 >> Guy Churchouse, ENP, SSCA (SIP Certified) Book of the Month: Surfaces=20 >> and Essences: Analogy as the Fuel and Fire of Thinking By: Douglas=20 >> Hofstadter & Emmanuel Sander Executive Vice President REVCORD=20 >> Revolutionizing Voice Recording >> 10575 Katy Freeway, Suite 470 >> Houston, Texas 77024 >> 281-404-7040 Main >> 281-404-5323 Fax >> 866-559-2188 Toll >> Mobile 714-316-4952 >> gchurchouse.revcord Skype >>=20 >>=20 >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: Thursday, May 16, 2013 12:56 PM >> To: siprec@ietf.org >> Subject: [siprec] Proposal for follow-on siprec work >>=20 >> siprec'ers: >>=20 >> I hope I'm not getting ahead of myself, but I *think* we are almost=20 >> done with the current round of siprec work. While we need to finish=20 >> it, I also think we need to be thinking about "what next". >>=20 >> Michael Yan and I have just posted a new draft proposing some new=20 >> siprec functionality that we would like to see. We are looking to=20 >> assess the interest in this. >>=20 >> The draft is intentionally somewhat vague, reflecting its preliminary=20 >> status. We want to refine it based on interest from the community. I=20 >> can imagine refining it in two ways: >>=20 >> - deepening it with more detail about the functionality mentioned >> - broadening it with additional functionality that others feel is >> currently lacking from siprec. >>=20 >> I'm posting this message to siprec, where I know there is a built-in=20 >> community of interest. But IIUC the actual process for adopting new=20 >> work of this sort will be to go back through dispatch. So I'll=20 >> probably also be posting a similar message to the dispatch mailing list. >>=20 >> Please, we want to hear from you! >>=20 >> Thanks, >> Paul >>=20 >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for=20 >> draft-kyzivat-siprec-webconf-use-case-00.txt >> Date: Thu, 16 May 2013 12:41:28 -0700 >> From: internet-drafts@ietf.org >> To: Paul H. Kyzivat , Michael Yan >> , Paul Kyzivat >>=20 >>=20 >> A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt >> has been successfully submitted by Paul H. Kyzivat and posted to the=20 >> IETF repository. >>=20 >> Filename: draft-kyzivat-siprec-webconf-use-case >> Revision: 00 >> Title: Web Conference Recording Use Case >> Creation date: 2013-05-16 >> Group: Individual Submission >> Number of pages: 6 >> URL: >> http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf-use- >> case- >> 00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use-case >> Htmlized: >> http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 >>=20 >>=20 >> Abstract: >> The current work of SIPREC will soon finish. As its charter defined= , >> SIPREC has covered industries like financial trading floors, contact >> center and emergency service bureaus. But when talking about >> products or solutions like data or web conferencing, SIPREC is >> insufficient to record all aspects of calls with different >> interactive media channels. This draft tries to show a use case for >> web conference recording and show how it can work well under SIPREC >> mechanism. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >>=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu May 16 13:59: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 D116821F8EB5 for ; Thu, 16 May 2013 13:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=0.137, 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 eBX9-7IxdAwR for ; Thu, 16 May 2013 13:59:46 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 11BAA21F8503 for ; Thu, 16 May 2013 13:59:45 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id ch6a1l00x17dt5G54kzlZe; Thu, 16 May 2013 20:59:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id ckzl1l00Q3ZTu2S3ZkzlCG; Thu, 16 May 2013 20:59:45 +0000 Message-ID: <519548C1.5000903@alum.mit.edu> Date: Thu, 16 May 2013 16:59:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Rosen References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> <519539C2.4010005@alum.mit.edu> <625f68627c8289d9524879179ba37317@mail.gmail.com> <5195457E.1040400@alum.mit.edu> <01FA7EC0-FFB3-4808-BA6F-AD739D227068@brianrosen.net> In-Reply-To: <01FA7EC0-FFB3-4808-BA6F-AD739D227068@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368737985; bh=EkLglFuhvmpr8QW71H+SJFKYuWKed6gOITW1YwiJfAw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DDuo0TWwiZq3pt67/6tP+0YEwWs3GBB3/HbGtqxoQRDL06vQbMq20u9LcbDG+Sk0F tipDGO0V/z8NSy0faS22CF/NKccVqQZRxQvrizuc152xTL4maDaLyL1fd+9lVFCcZW /75BVtpUAbin9naKkf8PLDn2zfYNK2x3kwZzmj+g10JpPGWHBnYhNWNyZeXyoPGoMB LpeDIDPs0yHko4zUfjmiAnZ8Zy1VUsUYBje84ByIbXbutG/VwRZGaHWfTtGNBKtlUp cTbxR4cBKwaYGNC52nJ6UlrS/eiRaf5VxMUc28xGfk0m05YKujTm8vk/JoeX60ybeW wsH6aG76MwdSg== Cc: siprec@ietf.org Subject: Re: [siprec] Proposal for follow-on siprec work 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, 16 May 2013 20:59:50 -0000 On 5/16/13 4:51 PM, Brian Rosen wrote: > In addition to this work, we need to extend for recording MSRP. I'll probably contribute to a draft on that. This is one of the things included! Thanks, Paul > Brian > > On May 16, 2013, at 4:45 PM, Paul Kyzivat wrote: > >> On 5/16/13 4:25 PM, Guy Churchouse wrote: >>> I very much support continuing with web conferencing recording as >>> outlined. >> >> Thanks Guy! >> >> We would appreciate any suggestions you have toward refining what we have written. >> >> Thanks, >> Paul >> >>> Guy >>> >>> Guy Churchouse, ENP, SSCA (SIP Certified) >>> Book of the Month: Surfaces and Essences: Analogy as the Fuel and Fire of >>> Thinking By: Douglas Hofstadter & Emmanuel Sander >>> Executive Vice President >>> REVCORD Revolutionizing Voice Recording >>> 10575 Katy Freeway, Suite 470 >>> Houston, Texas 77024 >>> 281-404-7040 Main >>> 281-404-5323 Fax >>> 866-559-2188 Toll >>> Mobile 714-316-4952 >>> gchurchouse.revcord Skype >>> >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Thursday, May 16, 2013 12:56 PM >>> To: siprec@ietf.org >>> Subject: [siprec] Proposal for follow-on siprec work >>> >>> siprec'ers: >>> >>> I hope I'm not getting ahead of myself, but I *think* we are almost done >>> with the current round of siprec work. While we need to finish it, I also >>> think we need to be thinking about "what next". >>> >>> Michael Yan and I have just posted a new draft proposing some new siprec >>> functionality that we would like to see. We are looking to assess the >>> interest in this. >>> >>> The draft is intentionally somewhat vague, reflecting its preliminary >>> status. We want to refine it based on interest from the community. I can >>> imagine refining it in two ways: >>> >>> - deepening it with more detail about the functionality mentioned >>> - broadening it with additional functionality that others feel is >>> currently lacking from siprec. >>> >>> I'm posting this message to siprec, where I know there is a built-in >>> community of interest. But IIUC the actual process for adopting new work >>> of this sort will be to go back through dispatch. So I'll probably also be >>> posting a similar message to the dispatch mailing list. >>> >>> Please, we want to hear from you! >>> >>> Thanks, >>> Paul >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-kyzivat-siprec-webconf-use-case-00.txt >>> Date: Thu, 16 May 2013 12:41:28 -0700 >>> From: internet-drafts@ietf.org >>> To: Paul H. Kyzivat , Michael Yan >>> , Paul Kyzivat >>> >>> >>> A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt >>> has been successfully submitted by Paul H. Kyzivat and posted to the >>> IETF repository. >>> >>> Filename: draft-kyzivat-siprec-webconf-use-case >>> Revision: 00 >>> Title: Web Conference Recording Use Case >>> Creation date: 2013-05-16 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf-use-case- >>> 00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use-case >>> Htmlized: >>> http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 >>> >>> >>> Abstract: >>> The current work of SIPREC will soon finish. As its charter defined, >>> SIPREC has covered industries like financial trading floors, contact >>> center and emergency service bureaus. But when talking about >>> products or solutions like data or web conferencing, SIPREC is >>> insufficient to record all aspects of calls with different >>> interactive media channels. This draft tries to show a use case for >>> web conference recording and show how it can work well under SIPREC >>> mechanism. >>> >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > From andrew.hutton@siemens-enterprise.com Fri May 17 02:19:06 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 BBE2921F9223 for ; Fri, 17 May 2013 02:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=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 iWIv39mpy4v8 for ; Fri, 17 May 2013 02:19:02 -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 32AB421F91BF for ; Fri, 17 May 2013 02:19:01 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id D523823F050D; Fri, 17 May 2013 11:19:00 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Fri, 17 May 2013 11:19:00 +0200 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , Henry Lum , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] CS hold/resume clarification in protocol draft Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgABxdoCAAOTQAIAAMpaAgAFJ7ICAAja1gIAI/mwAgAFRQYCAAJAJAIAFLYCAgALjtRCAAntnQA== Date: Fri, 17 May 2013 09:18:59 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159B51C@MCHP04MSX.global-ad.net> References: <518C5D53.30101@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C0882804833F39@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882804833F39@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] 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: Fri, 17 May 2013 09:19:06 -0000 Looks good to me great work Ram. Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: 15 May 2013 20:25 > To: Henry Lum; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] CS hold/resume clarification in protocol draft >=20 > Me too. Thanks for the detailed example Ram. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of > > Henry Lum > > Sent: Monday, May 13, 2013 11:17 AM > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: Re: [siprec] CS hold/resume clarification in protocol draft > > > > This works for me. > > > > Thanks > > Henry > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of > > Ram Mohan R (rmohanr) > > Sent: May-10-13 7:13 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] CS hold/resume clarification in protocol draft > > > > Let me know if others have any concern with this proposal before > 5/17. > > > > If no concern I will go ahead and update the metadata draft with text > and > > call-flow draft with examples to have the below notation for > pause/resume > > and CS hold/CS resume indication. > > > > Regards, > > Ram > > > > > On 10/05/13 8:07 AM, "Paul Kyzivat" wrote: > > > > >WFM > > > > > >On 5/9/13 2:30 AM, Ram Mohan R (rmohanr) wrote: > > >> Hi Charles, > > >> > > >> Sorry for delay. Please see inline > > >> > > >>> On 04/05/13 10:09 AM, "Charles Eckel (eckelcu)" > > > >>> wrote: > > >> > > >>> Hi Ram, > > >>> > > >>> My thinking on this is that we should use changing of the > direction of > > >>> media descriptions in the RS from sendonly to inactive and vice > versa > > >>>to > > >>> indicate stopping/starting the recording of the associated media > stream > > >>> as a whole. This does not imply anything about the state of the > media > > >>>in > > >>> the CS. > > >> > > >> I gave some thought about this and I tend to agree with you that > we > > >>could > > >> use the SDP direction attribute of RS to indicate stop/re-start > the > > >> recording of media represented by that m-line. Now how an SRC > decides to > > >> start/stop should be left outside the scope of SIPREC and may be > > >>dictated > > >> by a policy. > > >> > > >>> A hold/resume of the CS could result in the SRC deciding to stop > the > > >>> recording, but this is not necessarily the case. The SRC could > let the > > >>> recording continue, and indicate in XML which participants in the > CS > > >>>are > > >>> actively contributing media. > > >> > > >> To represent hold/resume or any other change in CS media, we could > still > > >> do with the existing metadata XML. We could use the and > > > >>XML > > >> elements of a to indicate whether a participant is > sending > > >> media/not sending a particular media stream whose properties are > > >> represented by element. Note with this we only convey if > a > > >> participant is sending/not sending media but an SRC still cannot > convey > > >> why a CS participant is not sending media(like hold e.t.c). I > don't > > >>think > > >> an SRC can really know this, all it can leo is by looking at CS > > >>signaling > > >> SDP and learn the direction attributes of media and send a > snapshot > > >> metadata which has the information on participant sending/not > sending a > > >> particular media stream. > > >> > > >> For example, in your below case for a two party call if one > participant > > >> Alice puts the call on hold by sending a SDP with a=3Dsendonly and > Bob > > >> responds with a=3Drecvonly then a snapshot of metadata at that > instance > > >>from > > >> SRC to SRS would look as below. Assume here a snapshot was sent > > >>initially > > >> with both participants having to the two streams: > > >> > > >> Snapshot sent from SRC to SRS after initial RS setup. > > >> > > >> F1 INVITE SRC --------------> SRS > > >> > > >> Content-Type: application/SDP > > >> ... > > >> m=3Daudio 49170 RTP/AVP 0 > > >> a=3Drtpmap:0 PCMU/8000 > > >> a=3Dlabel:96 > > >> a=3Dsendonly > > >> ... > > >> > > >> m=3Daudio 51372 RTP/AVP 0 > > >> a=3Drtpmap:0 PCMU/8000 > > >> a=3Dlabel:97 > > >> a=3Dsendonly > > >> > > >> .... > > >> > > >> > > >> complete > > >> > > >> 2010-12-16T23:41:07Z > > >> > > >> > >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> > > >> > > >> Alice > > >> > > >> > > >> > >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > > >> session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > >> 2013-05-09T23:41:07Z > > >> > > >> > >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> > > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > >> > > >> > >> participant_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > > >> > > >> Bob > > >> > > >> > > >> > >> participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > > >> session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > >> 2013-05-09T23:42:07Z time> > > >> > > >> > >> participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > > >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > >> > > >> > >> session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > >> > > >> > > >> > >> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > > >> > > >> > > >> > > >> > > >> > > >> > > >> Partial metadata Snapshot sent when Alice puts Bob on hold: > > >> > > >> F2 INVITE SRC --------------> SRS > > >> > > >> Content-Type: application/SDP > > >> ... > > >> m=3Daudio 49170 RTP/AVP 0 > > >> a=3Drtpmap:0 PCMU/8000 > > >> a=3Dlabel:96 > > >> a=3Dsendonly > > >> ... > > >> > > >> m=3Daudio 51372 RTP/AVP 0 > > >> a=3Drtpmap:0 PCMU/8000 > > >> a=3Dlabel:97 > > >> a=3Dsendonly > > >> > > >> > > >> > > >> Partial Snapshot after Alice resumes with Bob > > >> > > >> > > >> partial > > >> > >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> > > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > >> > > >> > >> participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > >> > > >> > > >> > > >> Here in the above snapshot the absence of for > participant_id > > >> srfBElmCRp2QB23b7Mpk0w=3D=3D (Alice) could be used to indicate that > Alice is > > >> only sending media and not receiving any thing. Same way for Bob. > > >> > > >> Partial metadata Snapshot sent when Alice resumes call with Bob: > > >> > > >> F3 INVITE SRC --------------> SRS > > >> > > >> Content-Type: application/SDP > > >> ... > > >> m=3Daudio 49170 RTP/AVP 0 > > >> a=3Drtpmap:0 PCMU/8000 > > >> a=3Dlabel:96 > > >> a=3Dsendonly > > >> ... > > >> > > >> m=3Daudio 51372 RTP/AVP 0 > > >> a=3Drtpmap:0 PCMU/8000 > > >> a=3Dlabel:97 > > >> a=3Dsendonly > > >> > > >> > > >> > > >> partial > > >> > >> participant_id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"> > > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > >> > > >> > >> participant=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > > >> 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > >> i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > >> > > >> > > >> > > >> > > >> Here in the above snapshot both Alice and Bob send and recv > streams. > > >> > > >> Note the above approach would work for all cases (stream mixed > from SRC > > >>to > > >> SRS or one of the endpoint is Focus in which case SRC received > mixed > > >> streams e.t.c). In all the flows the presence /absence of > and > > >> tags could be used to indicate whether a participant is > > >> contributing to a stream or not and whether it is receiving a > stream or > > >> not. > > >> > > >> Let me know if this approach is fine and if this works for every > one in > > >> the WG. > > >> > > >> Regards, > > >> Ram > > >> > > >>> As an example, if the CS is a two party call, a hold of the CS > might > > >>> result in the SRC stopping/pausing the recording. If it is a > conference > > >>> call, one party going on hold would have might have no effect on > the > > >>> direction of the media descriptions in the RS, but may result in > the > > >>> generation of some XML indicating that a specific participant is > no > > >>> longer contributing any media. I thought the existing XML allowed > for > > >>> this, but perhaps I am mistaken about that? > > >>> > > >>> Cheers, > > >>> Charles > > >>> > > >>>> -----Original Message----- > > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > >>>> Behalf Of Ram Mohan R (rmohanr) > > >>>> Sent: Wednesday, May 01, 2013 8:21 PM > > >>>> To: siprec@ietf.org > > >>>> Subject: Re: [siprec] CS hold/resume clarification in protocol > draft > > >>>> > > >>>> A question here: > > >>>> > > >>>> In the current metadata draft to indicate CS hold/resume from > SRC to > > >>>> SRS > > >>>> we re-use the SIP/SDP semantics and indicate the same with > > >>>> a=3Dinactive/a=3Dsendonly respectively. > > >>>> In the below discussion, I see we want to give a special meaning > for > > >>>> a=3Dinactive/a=3Dsendonly sent from SRC to SRS. This would mean CS > > >>>> hold / > > >>>> resume cannot be indicated using SDP semantics from SRC to SRS > as > > >>>> the SRS > > >>>> cannot differentiate between CS hold/resume and Recording > > >>>> stop/resume if > > >>>> we use the same semantics for both. > > >>>> > > >>>> The current metadata XML draft does not have any means to > indicate > > >>>> CS > > >>>> hold/resume in XML. The general approach followed in the > metadata > > >>>> (as a > > >>>> result of past feedback received) is to re-use SIP/SDP semantics > > >>>> wherever > > >>>> possible to represent metadata attributes and have XML > > >>>> representation for > > >>>> only those attributes that does not have a semantics in SIP/SDP > to > > >>>> represent. And hence the current draft re-uses SDP semantics to > > >>>> represent > > >>>> CS HOLD/RESUME. > > >>>> > > >>>> I want to hear feedback on - if the WG wants CSC hold/resume to > be > > >>>> represented in XML ? > > >>>> > > >>>> Ram > > >>>> > > >>>> > > >>>>> On 01/05/13 1:10 PM, "Hutton, Andrew" > > >>>>> wrote: > > >>>> > > >>>>> My view is that this is enough of an issue to make it a MUST as > you > > >>>> say > > >>>>> the fact that this would result in a misunderstanding and > therefore > > >>>>> probably a trouble ticket being raised against the > implementation > > >>>> is > > >>>>> reason enough. > > >>>>> > > >>>>> Andy > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Henry Lum [mailto:Henry.Lum@genesyslab.com] > > >>>>>> Sent: 01 May 2013 05:39 > > >>>>>> To: Alan Johnston; Hutton, Andrew > > >>>>>> Cc: siprec@ietf.org > > >>>>>> Subject: Re: [siprec] CS hold/resume clarification in protocol > draft > > >>>>>> > > >>>>>> The only interop issue this can cause is an SRS would mistaken > a > > >>>> hold > > >>>>>> as pause/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" > > >>>> > >>>>>> enterprise.com> 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=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 > > >>>>> > > >>>>> _______________________________________________ > > >>>>> siprec mailing list > > >>>>> siprec@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> siprec mailing list > > >>>> siprec@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/siprec > > >>> > > >> > > >> > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > >> > > > > > >_______________________________________________ > > >siprec mailing list > > >siprec@ietf.org > > >https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From DAVE.HIGTON@nice.com Fri May 17 02:38:17 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BB221F93BC for ; Fri, 17 May 2013 02:38:17 -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 9gti+fgQK-UH for ; Fri, 17 May 2013 02:38:13 -0700 (PDT) Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 42E2121F92FC for ; Fri, 17 May 2013 02:38:13 -0700 (PDT) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Fri, 17 May 2013 10:38:11 +0100 Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 May 2013 10:38:11 +0100 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Fri, 17 May 2013 10:38:10 +0100 From: "Dave Higton" To: Date: Fri, 17 May 2013 10:38:09 +0100 Thread-Topic: [siprec] Proposal for follow-on siprec work Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Index: Ac5SeFMh45ZzgIraTZitbTpbr5nxKAAadWXQ Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B6940561F74EFC@SOUEXC01.eu.nice.com> References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com><519539C2.4010005@alum.mit.edu><625f68627c8289d9524879179ba37317@mail.gmail.com><5195457E.1040400@alum.mit.edu><01FA7EC0-FFB3-4808-BA6F-AD739D227068@brianrosen.net> <519548C1.5000903@alum.mit.edu> In-Reply-To: <519548C1.5000903@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 May 2013 09:38:11.0337 (UTC) FILETIME=[3EFFEF90:01CE52E2] Subject: Re: [siprec] Proposal for follow-on siprec work 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, 17 May 2013 09:38:17 -0000 Excellent news, because it's +1 from NICE too. Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 16 May 2013 22:00 To: Brian Rosen Cc: siprec@ietf.org Subject: Re: [siprec] Proposal for follow-on siprec work On 5/16/13 4:51 PM, Brian Rosen wrote: > In addition to this work, we need to extend for recording MSRP. I'll = probably contribute to a draft on that. This is one of the things included! Thanks, Paul > Brian > > On May 16, 2013, at 4:45 PM, Paul Kyzivat = wrote: > >> On 5/16/13 4:25 PM, Guy Churchouse wrote: >>> I very much support continuing with web conferencing recording as >>> outlined. >> >> Thanks Guy! >> >> We would appreciate any suggestions you have toward refining what we = have written. >> >> Thanks, >> Paul >> >>> Guy >>> >>> Guy Churchouse, ENP, SSCA (SIP Certified) >>> Book of the Month: Surfaces and Essences: Analogy as the Fuel and = Fire of >>> Thinking By: Douglas Hofstadter & Emmanuel Sander >>> Executive Vice President >>> REVCORD Revolutionizing Voice Recording >>> 10575 Katy Freeway, Suite 470 >>> Houston, Texas 77024 >>> 281-404-7040 Main >>> 281-404-5323 Fax >>> 866-559-2188 Toll >>> Mobile 714-316-4952 >>> gchurchouse.revcord Skype >>> >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf >>> Of Paul Kyzivat >>> Sent: Thursday, May 16, 2013 12:56 PM >>> To: siprec@ietf.org >>> Subject: [siprec] Proposal for follow-on siprec work >>> >>> siprec'ers: >>> >>> I hope I'm not getting ahead of myself, but I *think* we are almost = done >>> with the current round of siprec work. While we need to finish it, I = also >>> think we need to be thinking about "what next". >>> >>> Michael Yan and I have just posted a new draft proposing some new = siprec >>> functionality that we would like to see. We are looking to assess = the >>> interest in this. >>> >>> The draft is intentionally somewhat vague, reflecting its = preliminary >>> status. We want to refine it based on interest from the community. I = can >>> imagine refining it in two ways: >>> >>> - deepening it with more detail about the functionality mentioned >>> - broadening it with additional functionality that others feel is >>> currently lacking from siprec. >>> >>> I'm posting this message to siprec, where I know there is a built-in >>> community of interest. But IIUC the actual process for adopting new = work >>> of this sort will be to go back through dispatch. So I'll probably = also be >>> posting a similar message to the dispatch mailing list. >>> >>> Please, we want to hear from you! >>> >>> Thanks, >>> Paul >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-kyzivat-siprec-webconf-use-case-00.txt >>> Date: Thu, 16 May 2013 12:41:28 -0700 >>> From: internet-drafts@ietf.org >>> To: Paul H. Kyzivat , Michael Yan >>> , Paul Kyzivat = >>> >>> >>> A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt >>> has been successfully submitted by Paul H. Kyzivat and posted to the >>> IETF repository. >>> >>> Filename: draft-kyzivat-siprec-webconf-use-case >>> Revision: 00 >>> Title: Web Conference Recording Use Case >>> Creation date: 2013-05-16 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL: >>> = http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf-use-case= - >>> 00.txt >>> Status: >>> = http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use-case >>> Htmlized: >>> http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 >>> >>> >>> Abstract: >>> The current work of SIPREC will soon finish. As its charter = defined, >>> SIPREC has covered industries like financial trading floors, = contact >>> center and emergency service bureaus. But when talking about >>> products or solutions like data or web conferencing, SIPREC is >>> insufficient to record all aspects of calls with different >>> interactive media channels. This draft tries to show a use = case for >>> web conference recording and show how it can work well under = SIPREC >>> mechanism. >>> >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec NICE Systems UK Limited ("NICE") is registered in England under company = number, 3403044. The registered office of NICE is at Tollbar Way, Hedge = End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for = the above-named persons only and may be confidential and/or legally = privileged. Any opinions expressed in this communication are not = necessarily those of NICE. If this communication has come to you in = error you must take no action based on it, nor must you copy or show it = to anyone; please delete/destroy and inform the sender by e-mail = immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail = and attachments are free from any virus, we advise that in keeping with = good computing practice the recipient should ensure they are actually = virus free. From andrew.hutton@siemens-enterprise.com Fri May 17 06:59:48 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3ED121F9423 for ; Fri, 17 May 2013 06:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, 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 LEUO20bBG7Hk for ; Fri, 17 May 2013 06:59:44 -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 8A84821F9301 for ; Fri, 17 May 2013 06:59:44 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 6696C23F068C for ; Fri, 17 May 2013 15:59:43 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Fri, 17 May 2013 15:59:43 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Call for real world siprec call flows. Thread-Index: Ac5TBseZyPJYuqChSFGAIj+IYxjYZA== Date: Fri, 17 May 2013 13:59:42 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159B949@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1159B949MCHP04MSXglobal_" MIME-Version: 1.0 Subject: [siprec] Call for real world siprec call flows. 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, 17 May 2013 13:59:49 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1159B949MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to progress the SIPREC call flows draft (http://tools.ietf.org/htm= l/draft-ietf-siprec-callflows-00) we discussed during IETF86 the need for t= he community to provide some traces of real implemented call flows includin= g metadata for inclusion in the document. If you have this capability and are willing to provide traces to the workin= g group we would be very grateful. Regards Andy (SIPREC Co-Chair). --_000_9F33F40F6F2CD847824537F3C4E37DDF1159B949MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In order to progress the SIPREC call flows draft (h= ttp://tools.ietf.org/html/draft-ietf-siprec-callflows-00) we= discussed during IETF86 the need for the community to provide some traces of real implemented call flows includi= ng metadata for inclusion in the document.
 
If you have this capability and are willing to provide traces to the w= orking group we would be very grateful.
 
Regards
Andy (SIPREC Co-Chair).
 
 
 --_000_9F33F40F6F2CD847824537F3C4E37DDF1159B949MCHP04MSXglobal_-- From andrew.hutton@siemens-enterprise.com Fri May 17 07:08:44 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 9AECB21F8B64 for ; Fri, 17 May 2013 07:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 F4ztvLjaeHnE for ; Fri, 17 May 2013 07:08:39 -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 6817321F87E0 for ; Fri, 17 May 2013 07:08:39 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C2E551EB875C; Fri, 17 May 2013 16:08:35 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Fri, 17 May 2013 16:08:35 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" , "Rosen, Brian" Thread-Topic: SIPREC Session Request for IETF 87 Thread-Index: AQHOUwgE6R2APygPVk2nYfdGwm6lOQ== Date: Fri, 17 May 2013 14:08:34 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159B97C@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [siprec] SIPREC Session Request for IETF 87 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, 17 May 2013 14:08:44 -0000 SGkgQWxsLA0KDQpUaGUgd29yayBsb2FkIGlzIHJlZHVjaW5nIGJ1dCBJIGFzc3VtZSB3ZSBzdGls bCB3YW50IHRvIG1lZXQgaW4gQmVybGluIHNvIEkgaGF2ZSBtYWRlIGEgcmVxdWVzdCBmb3IgYSAx LjUgaG91ciBzZXNzaW9uLg0KDQpJZiB5b3UgYXJlIGludGVuZGluZyB0byBtYWtlIGEgcHJlc2Vu dGF0aW9uIGR1cmluZyB0aGUgbWVldGluZyBwbGVhc2UgbGV0IEJyaWFuIGFuZCBJIGtub3cuDQoN ClJlZ2FyZHMNCkFuZHkgKFNJUFJFQyBDby1DaGFpcikuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogIklFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbCIgW21h aWx0bzpzZXNzaW9uX3JlcXVlc3RfZGV2ZWxvcGVyc0BpZXRmLm9yZ10gDQpTZW50OiAxNyBNYXkg MjAxMyAxNTowMw0KVG86IHNlc3Npb24tcmVxdWVzdEBpZXRmLm9yZw0KQ2M6IHNpcHJlYy1hZHNA dG9vbHMuaWV0Zi5vcmc7IGJyQGJyaWFucm9zZW4ubmV0OyBIdXR0b24sIEFuZHJldzsgSHV0dG9u LCBBbmRyZXcNClN1YmplY3Q6IHNpcHJlYyAtIE5ldyBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBm b3IgSUVURiA4Nw0KDQoNCg0KQSBuZXcgbWVldGluZyBzZXNzaW9uIHJlcXVlc3QgaGFzIGp1c3Qg YmVlbiBzdWJtaXR0ZWQgYnkgQW5kcmV3IEh1dHRvbiwgYSBjaGFpciBvZiB0aGUgc2lwcmVjIHdv cmtpbmcgZ3JvdXAuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpXb3JraW5nIEdyb3VwIE5hbWU6IFNJUCBSZWNvcmRpbmcNCkFy ZWEgTmFtZTogUmVhbC10aW1lIEFwcGxpY2F0aW9ucyBhbmQgSW5mcmFzdHJ1Y3R1cmUgQXJlYQ0K U2Vzc2lvbiBSZXF1ZXN0ZXI6IEFuZHJldyBIdXR0b24NCg0KTnVtYmVyIG9mIFNlc3Npb25zOiAx DQpMZW5ndGggb2YgU2Vzc2lvbihzKTogIDEuNSBIb3Vycw0KTnVtYmVyIG9mIEF0dGVuZGVlczog NDANCkNvbmZsaWN0cyB0byBBdm9pZDogDQogRmlyc3QgUHJpb3JpdHk6IGJlaGF2ZSBhdnRjb3Jl IGF2dGV4dCBiZmNwYmlzIGNsdWUgZGlzcGF0Y2ggZWNyaXQgZ2VvcHJpdiBoaXAgbWVkaWFjdHJs IG1tdXNpYyBwMnBzaXAgcGF3cyBydGN3ZWIgc2lwY29yZSB2aXByIGluc2lwaWQgc2FsdWQgc3Ry YXcNCiBTZWNvbmQgUHJpb3JpdHk6IGFsdG8gY29kZWMgY3VzcyBkcmlua3Mgc29jIHhtcHANCg0K DQoNClNwZWNpYWwgUmVxdWVzdHM6DQogIE1lZXRlY2hvIGZvciByZW1vdGUgcGFydGljaXBhdGlv biwgamFiYmVyLCBhbmQgcmVjb3JkaW5nIG9mIHRoZSBzZXNzaW9uLg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From partha@parthasarathi.co.in Fri May 17 08:40:33 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 F213321F96D1 for ; Fri, 17 May 2013 08:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1xXj5kIX6TH for ; Fri, 17 May 2013 08:40:28 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB7F21F96B1 for ; Fri, 17 May 2013 08:40:28 -0700 (PDT) Received: from userPC (unknown [122.179.86.30]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 2836F1908261; Fri, 17 May 2013 15:40:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1368805227; bh=KP9C5nD6bjLTB5lJcSeSHMJbBfhMqXY6rXbW9pSrRXc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WmQA69MrKff2p+Ed1iqbvW6nMOmK2usoXpIk1RsdOIXYVlMoZdl7P/lZ2djA1edeH f5zamO9PkRNR1QzqqfSMgkA2t/MLoZq3ltB6VdnvVFd9VNmtXpZ0YhkypdFTNMMYLF Mingrb/QuLd1PyvvDeeczc8C/F6HMj+O4XR3vX9s= From: "Parthasarathi R" To: "'Paul Kyzivat'" , "'Brian Rosen'" References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> <519539C2.4010005@alum.mit.edu> <625f68627c8289d9524879179ba37317@mail.gmail.com> <5195457E.1040400@alum.mit.edu> <01FA7EC0-FFB3-4808-BA6F-AD739D227068@brianrosen.net> <519548C1.5000903@alum.mit.edu> In-Reply-To: <519548C1.5000903@alum.mit.edu> Date: Fri, 17 May 2013 21:10:10 +0530 Message-ID: <007f01ce5314$d69344b0$83b9ce10$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5SeE/gHZDutnuAQxu0khTtWwhpOwAnGRnQ Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0202.51964F6B.00E6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: siprec@ietf.org Subject: Re: [siprec] Proposal for follow-on siprec work 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, 17 May 2013 15:40:33 -0000 Nice to hear that MSRP is added. I'll happy to review MSRP recording. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, May 17, 2013 2:30 AM > To: Brian Rosen > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposal for follow-on siprec work > > On 5/16/13 4:51 PM, Brian Rosen wrote: > > In addition to this work, we need to extend for recording MSRP. I'll > probably contribute to a draft on that. > > This is one of the things included! > > Thanks, > Paul > > > Brian > > > > On May 16, 2013, at 4:45 PM, Paul Kyzivat > wrote: > > > >> On 5/16/13 4:25 PM, Guy Churchouse wrote: > >>> I very much support continuing with web conferencing recording as > >>> outlined. > >> > >> Thanks Guy! > >> > >> We would appreciate any suggestions you have toward refining what we > have written. > >> > >> Thanks, > >> Paul > >> > >>> Guy > >>> > >>> Guy Churchouse, ENP, SSCA (SIP Certified) > >>> Book of the Month: Surfaces and Essences: Analogy as the Fuel and > Fire of > >>> Thinking By: Douglas Hofstadter & Emmanuel Sander > >>> Executive Vice President > >>> REVCORD Revolutionizing Voice Recording > >>> 10575 Katy Freeway, Suite 470 > >>> Houston, Texas 77024 > >>> 281-404-7040 Main > >>> 281-404-5323 Fax > >>> 866-559-2188 Toll > >>> Mobile 714-316-4952 > >>> gchurchouse.revcord Skype > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >>> Of Paul Kyzivat > >>> Sent: Thursday, May 16, 2013 12:56 PM > >>> To: siprec@ietf.org > >>> Subject: [siprec] Proposal for follow-on siprec work > >>> > >>> siprec'ers: > >>> > >>> I hope I'm not getting ahead of myself, but I *think* we are almost > done > >>> with the current round of siprec work. While we need to finish it, > I also > >>> think we need to be thinking about "what next". > >>> > >>> Michael Yan and I have just posted a new draft proposing some new > siprec > >>> functionality that we would like to see. We are looking to assess > the > >>> interest in this. > >>> > >>> The draft is intentionally somewhat vague, reflecting its > preliminary > >>> status. We want to refine it based on interest from the community. > I can > >>> imagine refining it in two ways: > >>> > >>> - deepening it with more detail about the functionality mentioned > >>> - broadening it with additional functionality that others feel is > >>> currently lacking from siprec. > >>> > >>> I'm posting this message to siprec, where I know there is a built- > in > >>> community of interest. But IIUC the actual process for adopting new > work > >>> of this sort will be to go back through dispatch. So I'll probably > also be > >>> posting a similar message to the dispatch mailing list. > >>> > >>> Please, we want to hear from you! > >>> > >>> Thanks, > >>> Paul > >>> > >>> > >>> -------- Original Message -------- > >>> Subject: New Version Notification for > >>> draft-kyzivat-siprec-webconf-use-case-00.txt > >>> Date: Thu, 16 May 2013 12:41:28 -0700 > >>> From: internet-drafts@ietf.org > >>> To: Paul H. Kyzivat , Michael Yan > >>> , Paul Kyzivat > > >>> > >>> > >>> A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt > >>> has been successfully submitted by Paul H. Kyzivat and posted to > the > >>> IETF repository. > >>> > >>> Filename: draft-kyzivat-siprec-webconf-use-case > >>> Revision: 00 > >>> Title: Web Conference Recording Use Case > >>> Creation date: 2013-05-16 > >>> Group: Individual Submission > >>> Number of pages: 6 > >>> URL: > >>> http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf- > use-case- > >>> 00.txt > >>> Status: > >>> http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use- > case > >>> Htmlized: > >>> http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 > >>> > >>> > >>> Abstract: > >>> The current work of SIPREC will soon finish. As its charter > defined, > >>> SIPREC has covered industries like financial trading floors, > contact > >>> center and emergency service bureaus. But when talking about > >>> products or solutions like data or web conferencing, SIPREC is > >>> insufficient to record all aspects of calls with different > >>> interactive media channels. This draft tries to show a use > case for > >>> web conference recording and show how it can work well under > SIPREC > >>> mechanism. > >>> > >>> > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Fri May 17 13:49:38 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 D538421F898B; Fri, 17 May 2013 13:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npGfmYvTh9Wf; Fri, 17 May 2013 13:49:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BD621F925B; Fri, 17 May 2013 13:49:36 -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.45 Message-ID: <20130517204936.6373.33223.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 13:49:36 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-10.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, 17 May 2013 20:49:38 -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-10.txt Pages : 41 Date : 2013-05-17 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From henry.lum@genesyslab.com Fri May 17 14:01:01 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A4E21F9672 for ; Fri, 17 May 2013 14:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 eol7N7xlU1mB for ; Fri, 17 May 2013 14:00:55 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 158CD21F968D for ; Fri, 17 May 2013 14:00:55 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Fri, 17 May 2013 17:00:53 -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; Fri, 17 May 2013 14:00:51 -0700 From: Henry Lum To: Parthasarathi R , 'Paul Kyzivat' , 'Brian Rosen' Thread-Topic: [siprec] Proposal for follow-on siprec work Thread-Index: AQHOUm9is6X0movLmEeC6/diWhisG5kIt3IAgAAFugCAAAGggIAAAkSAgAE5CgD//+Ee4A== Date: Fri, 17 May 2013 21:00:50 +0000 Message-ID: References: <20130516194128.15788.68159.idtracker@ietfa.amsl.com> <519539C2.4010005@alum.mit.edu> <625f68627c8289d9524879179ba37317@mail.gmail.com> <5195457E.1040400@alum.mit.edu> <01FA7EC0-FFB3-4808-BA6F-AD739D227068@brianrosen.net> <519548C1.5000903@alum.mit.edu> <007f01ce5314$d69344b0$83b9ce10$@co.in> In-Reply-To: <007f01ce5314$d69344b0$83b9ce10$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.77] MIME-Version: 1.0 X-MC-Unique: 113051717005313802 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposal for follow-on siprec work 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, 17 May 2013 21:01:01 -0000 I support MSRP work as well. I also want to see if there is interest in recording VoiceXML dialogs. I ha= ve a few suggestions that I can write up for providing standard metadata an= d mechanisms in VoiceXML. Regards, Henry -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R Sent: May-17-13 11:40 AM To: 'Paul Kyzivat'; 'Brian Rosen' Cc: siprec@ietf.org Subject: Re: [siprec] Proposal for follow-on siprec work Nice to hear that MSRP is added. I'll happy to review MSRP recording. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, May 17, 2013 2:30 AM > To: Brian Rosen > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposal for follow-on siprec work >=20 > On 5/16/13 4:51 PM, Brian Rosen wrote: > > In addition to this work, we need to extend for recording MSRP. I'll > probably contribute to a draft on that. >=20 > This is one of the things included! >=20 > =09Thanks, > =09Paul >=20 > > Brian > > > > On May 16, 2013, at 4:45 PM, Paul Kyzivat > wrote: > > > >> On 5/16/13 4:25 PM, Guy Churchouse wrote: > >>> I very much support continuing with web conferencing recording as > >>> outlined. > >> > >> Thanks Guy! > >> > >> We would appreciate any suggestions you have toward refining what we > have written. > >> > >> =09Thanks, > >> =09Paul > >> > >>> Guy > >>> > >>> Guy Churchouse, ENP, SSCA (SIP Certified) > >>> Book of the Month: Surfaces and Essences: Analogy as the Fuel and > Fire of > >>> Thinking By: Douglas Hofstadter & Emmanuel Sander > >>> Executive Vice President > >>> REVCORD Revolutionizing Voice Recording > >>> 10575 Katy Freeway, Suite 470 > >>> Houston, Texas 77024 > >>> 281-404-7040 Main > >>> 281-404-5323 Fax > >>> 866-559-2188 Toll > >>> Mobile 714-316-4952 > >>> gchurchouse.revcord Skype > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >>> Of Paul Kyzivat > >>> Sent: Thursday, May 16, 2013 12:56 PM > >>> To: siprec@ietf.org > >>> Subject: [siprec] Proposal for follow-on siprec work > >>> > >>> siprec'ers: > >>> > >>> I hope I'm not getting ahead of myself, but I *think* we are almost > done > >>> with the current round of siprec work. While we need to finish it, > I also > >>> think we need to be thinking about "what next". > >>> > >>> Michael Yan and I have just posted a new draft proposing some new > siprec > >>> functionality that we would like to see. We are looking to assess > the > >>> interest in this. > >>> > >>> The draft is intentionally somewhat vague, reflecting its > preliminary > >>> status. We want to refine it based on interest from the community. > I can > >>> imagine refining it in two ways: > >>> > >>> - deepening it with more detail about the functionality mentioned > >>> - broadening it with additional functionality that others feel is > >>> currently lacking from siprec. > >>> > >>> I'm posting this message to siprec, where I know there is a built- > in > >>> community of interest. But IIUC the actual process for adopting new > work > >>> of this sort will be to go back through dispatch. So I'll probably > also be > >>> posting a similar message to the dispatch mailing list. > >>> > >>> Please, we want to hear from you! > >>> > >>> =09Thanks, > >>> =09Paul > >>> > >>> > >>> -------- Original Message -------- > >>> Subject: New Version Notification for > >>> draft-kyzivat-siprec-webconf-use-case-00.txt > >>> Date: Thu, 16 May 2013 12:41:28 -0700 > >>> From: internet-drafts@ietf.org > >>> To: Paul H. Kyzivat , Michael Yan > >>> , Paul Kyzivat > > >>> > >>> > >>> A new version of I-D, draft-kyzivat-siprec-webconf-use-case-00.txt > >>> has been successfully submitted by Paul H. Kyzivat and posted to > the > >>> IETF repository. > >>> > >>> Filename:=09 draft-kyzivat-siprec-webconf-use-case > >>> Revision:=09 00 > >>> Title:=09=09 Web Conference Recording Use Case > >>> Creation date:=09 2013-05-16 > >>> Group:=09=09 Individual Submission > >>> Number of pages: 6 > >>> URL: > >>> http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-webconf- > use-case- > >>> 00.txt > >>> Status: > >>> http://datatracker.ietf.org/doc/draft-kyzivat-siprec-webconf-use- > case > >>> Htmlized: > >>> http://tools.ietf.org/html/draft-kyzivat-siprec-webconf-use-case-00 > >>> > >>> > >>> Abstract: > >>> The current work of SIPREC will soon finish. As its charter > defined, > >>> SIPREC has covered industries like financial trading floors, > contact > >>> center and emergency service bureaus. But when talking about > >>> products or solutions like data or web conferencing, SIPREC is > >>> insufficient to record all aspects of calls with different > >>> interactive media channels. This draft tries to show a use > case for > >>> web conference recording and show how it can work well under > SIPREC > >>> mechanism. > >>> > >>> > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Thu May 23 13:58: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 9E86B21F9885; Thu, 23 May 2013 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.294 X-Spam-Level: X-Spam-Status: No, score=-102.294 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c3g5k7i-cct; Thu, 23 May 2013 13:58:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A2821F92EC; Thu, 23 May 2013 13:17:42 -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.50 Message-ID: <20130523201707.13395.58020.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 13:17:07 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-08.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 20:58:58 -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 : An Architecture for Media Recording using the Session In= itiation Protocol Author(s) : Andrew Hutton Leon Portman Rajnish Jain Ken Rehor Filename : draft-ietf-siprec-architecture-08.txt Pages : 17 Date : 2013-05-23 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-architecture-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-architecture-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon May 27 20:18:06 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 6102F21F93ED; Mon, 27 May 2013 20:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5RoeNW+ECtT; Mon, 27 May 2013 20:18:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC3521F9385; Mon, 27 May 2013 20:18:05 -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.50 Message-ID: <20130528031805.25716.19888.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 20:18:05 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-12.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 03:18:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-12.txt Pages : 29 Date : 2013-05-27 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-metadata-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rmohanr@cisco.com Mon May 27 20:35:08 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 EC1CA21F9410 for ; Mon, 27 May 2013 20:35:08 -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 ryG9uS2Wa9it for ; Mon, 27 May 2013 20:35:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CFD8D21F9408 for ; Mon, 27 May 2013 20:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1879; q=dns/txt; s=iport; t=1369712103; x=1370921703; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zTR0fT64F5jUDoaOCXGZ71U2qEkMBgWE3KBxzdUkyuk=; b=NMpYfeybcOl+XQjsB7k8GFxBmIbISDcxs55/6Jz7E+j9rg96FUMvk2Fa 5A5q8gNtz7SO49svOghAY5lA8B7piCfWMRJNwgzcvTTEWaoOy0Sq8jK+H I6H9iRoav8vnYrdalpkzl2PAC6xNSesFiSLK9isHHQyXOvFnRkqwgJhUC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8GAGAlpFGtJXHB/2dsb2JhbABagwgwQ8FHgQkWbQeCIwEBAQMBOj0CBQ0BCCIUQhsBBgMCBA4FCAGHfgYHBbwVjmwxB4JzYQOYZJAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,755,1363132800"; d="scan'208";a="215549881" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 28 May 2013 03:35:03 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4S3Z3b4022120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 May 2013 03:35:03 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.106]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 27 May 2013 22:35:02 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: New Version Notification for draft-ietf-siprec-metadata-12.txt Thread-Index: AQHOW1H7Ux59jT/Y1kCyrXEhLcdgKJkaooqA Date: Tue, 28 May 2013 03:35:02 +0000 Message-ID: In-Reply-To: <20130528031806.25716.58391.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.212.104] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] FW: New Version Notification for draft-ietf-siprec-metadata-12.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 03:35:09 -0000 Hi All, We have published the new revision of SIPREC metadata draft. The changes from previous version are: 1) Modified text for CS termination reason in Section 6.3.3 and added XML schema for reason header as per the discussions we had. 2) Modified text in section 6.8.1 and 6.8.3 to clarify on how CS hold/resume will be represented in metadata. The actual examples of hold/resume will be added in call flows draft. Please review and provide comments Regards, Authors > On 28/05/13 8:48 AM, "internet-drafts@ietf.org" > wrote: > >A new version of I-D, draft-ietf-siprec-metadata-12.txt >has been successfully submitted by Ram Mohan Ravindranath and posted to >the >IETF repository. > >Filename: draft-ietf-siprec-metadata >Revision: 12 >Title: Session Initiation Protocol (SIP) Recording Metadata >Creation date: 2013-05-28 >Group: siprec >Number of pages: 29 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-12.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-ietf-siprec-metadata >Htmlized: http://tools.ietf.org/html/draft-ietf-siprec-metadata-12 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-12 > >Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. > > =20 > =20 > > >The IETF Secretariat > >