From trac+siprec@trac.tools.ietf.org Wed Jan 4 07:10:22 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4EE21F8739 for ; Wed, 4 Jan 2012 07:10:21 -0800 (PST) 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 bgbt02xnmCgh for ; Wed, 4 Jan 2012 07:10:21 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3332421F8737 for ; Wed, 4 Jan 2012 07:10:19 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RiSTn-0004wM-CI; Wed, 04 Jan 2012 10:10:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: andrew.hutton@siemens-enterprise.com X-Trac-Project: siprec Date: Wed, 04 Jan 2012 15:10:14 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/siprec/trac/ticket/80 Message-ID: <077.46a021a77843bb47f233c7c1c87f9c9c@trac.tools.ietf.org> X-Trac-Ticket-ID: 80 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: andrew.hutton@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: [siprec] #80: How to identify CS in SRS Initiated recording. 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: Wed, 04 Jan 2012 15:10:22 -0000 #80: How to identify CS in SRS Initiated recording. Section 3.2.2 of draft-ietf-siprec-architecture-03 currently has an open issue regarding how CS to be recorded is indicated by the SRS in the SRS initiated recording case. This was discussed at IETF82 with no firm conclusion however it was suggested that this is a matter for the protocol draft and the architecture draft does not need to specify this. It is also possible that we leave the mechanism to a later date and don't specify anything now. See http://tools.ietf.org/html/draft-ietf-siprec- architecture-03#section-3.2.2 -- --------------------------------+----------------------------- Reporter: andrew.hutton@… | Owner: andrew.hutton@… Type: enhancement | Status: new Priority: major | Milestone: Component: Architecture | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------------- Ticket URL: siprec From andrew.hutton@siemens-enterprise.com Wed Jan 4 08:11:23 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DDD21F878A for ; Wed, 4 Jan 2012 08:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651, 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 53zsGhJIfb-R for ; Wed, 4 Jan 2012 08:11:22 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 488F221F8781 for ; Wed, 4 Jan 2012 08:11:22 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id CA9D923F04EB; Wed, 4 Jan 2012 17:11:18 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 4 Jan 2012 17:11:18 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" , "leonp@nice.com" Date: Wed, 4 Jan 2012 17:11:16 +0100 Thread-Topic: [siprec] #78: Using of feature and options tags in SIPREC protocol Thread-Index: AcykKtWXMtlTKjwCTCe9m2aD405QrQmzq8bQ Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311FD92E68E@MCHP058A.global-ad.net> References: <055.bd9bf14e48b183684fe7b426156f0089@trac.tools.ietf.org> In-Reply-To: <055.bd9bf14e48b183684fe7b426156f0089@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [siprec] #78: Using of feature and options tags in SIPREC protocol 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, 04 Jan 2012 16:11:23 -0000 V2UgYWdyZWVkIGR1cmluZyB0aGUgSUVURjgyIG1lZXRpbmcgdGhhdDoNCg0KMS4gV2Ugd2lsbCB1 c2UgdGhlIGZlYXR1cmUgdGFncyAnK3NpcC5zcmMnIGFuZCAnK3NpcC5zcmMnIGFuZCB0aGF0IHRo aXMgY2FuIGJlIHVzZWQgYXMgYW4gaW5kaWNhdGlvbiBvZiBpbnRlbnQgdG8gZXN0YWJsaXNoIGEg UmVjb3JkaW5nIFNlc3Npb24uIA0KDQoyLiBUbyBtYWludGFpbiB0aGUgY3VycmVudCB1c2FnZSBv ZiB0aGUgInNpcHJlYyIgb3B0aW9uIHRhZyBhcyBjdXJyZW50bHkgc3BlY2lmaWVkIGluIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lwcmVjLXByb3RvY29sLTAyI3NlY3Rp b24tMTEuMS4xLg0KDQpTbyBJIHRoaW5rIHdlIGNhbiBjbG9zZSB0aGlzIHRpY2tldC4NCg0KUmVn YXJkcw0KQW5keQ0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBz aXByZWMgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrc2lwcmVjQHRyYWMudG9vbHMuaWV0Zi5v cmddDQo+IFNlbnQ6IDE2IE5vdmVtYmVyIDIwMTEgMDY6NDINCj4gVG86IGRyYWZ0LWlldGYtc2lw cmVjLXByb3RvY29sQHRvb2xzLmlldGYub3JnOyBsZW9ucEBuaWNlLmNvbQ0KPiBDYzogc2lwcmVj QGlldGYub3JnDQo+IFN1YmplY3Q6IFtzaXByZWNdICM3ODogVXNpbmcgb2YgZmVhdHVyZSBhbmQg b3B0aW9ucyB0YWdzIGluIFNJUFJFQw0KPiBwcm90b2NvbA0KPiANCj4gIzc4OiBVc2luZyBvZiBm ZWF0dXJlIGFuZCBvcHRpb25zIHRhZ3MgaW4gU0lQUkVDIHByb3RvY29sDQo+IA0KPiAgaXMgaXQg Y29ycmVjdCB1c2FnZSBvZiBmZWF0dXJlIHRhZ3M/DQo+IA0KPiAgTW9yZSBkZXRhaWxzIGluOg0K PiANCj4gIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXByZWMvY3VycmVu dC9tc2cwMjg4NS5odG1sDQo+IA0KPiAgIGFuZA0KPiANCj4gIGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zaXByZWMvY3VycmVudC9tc2cwMjg5Ny5odG1sDQo+IA0KPiAgTGVv bg0KPiANCj4gLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIFJlcG9ydGVyOiAgbGVvbnBA4oCmICAgfCAgICAg IE93bmVyOiAgZHJhZnQtaWV0Zi1zaXByZWMtcHJvdG9jb2xA4oCmDQo+ICAgICAgVHlwZTogIGRl ZmVjdCAgICB8ICAgICBTdGF0dXM6ICBuZXcNCj4gIFByaW9yaXR5OiAgbWFqb3IgICAgIHwgIE1p bGVzdG9uZToNCj4gQ29tcG9uZW50OiAgcHJvdG9jb2wgIHwgICAgVmVyc2lvbjogIDIuMA0KPiAg U2V2ZXJpdHk6ICAtICAgICAgICAgfCAgIEtleXdvcmRzOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGlj a2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3NpcHJlYy90cmFjL3RpY2tl dC83OD4NCj4gc2lwcmVjIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvc2lwcmVjLz4NCg0K From andrew.hutton@siemens-enterprise.com Wed Jan 4 08:38:34 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B2B21F8738 for ; Wed, 4 Jan 2012 08:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 9yRkp+Ga+M2o for ; Wed, 4 Jan 2012 08:38:33 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4C021F876F for ; Wed, 4 Jan 2012 08:38:33 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id DFA9C1EB8415 for ; Wed, 4 Jan 2012 17:38:29 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 4 Jan 2012 17:38:30 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Wed, 4 Jan 2012 17:38:28 +0100 Thread-Topic: Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpsw== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> 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_101C6067BEC68246B0C3F6843BCCC1E311FD92E6BDMCHP058Agloba_" MIME-Version: 1.0 Subject: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 04 Jan 2012 16:38:34 -0000 --_000_101C6067BEC68246B0C3F6843BCCC1E311FD92E6BDMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, During IETF82 we discussed RTP & RTCP Multiplexing (RFC 5761) and whether w= hat we should say about this in the SIPREC protocol draft the conclusion wa= s that this could be supported but we needed to confirm this. I am not sure we really need to say anything about this in the protocol dra= ft since support for it would of course be optional like many other SDP att= ributes and I don't see any specific relevant to SIPREC other than it being= useful in reducing the number of ports used at the SRS and SRC. I think it would be ok for the protocol draft to say that support for this = would be a good idea but don't think we should make it mandatory. Any comments? Regards Andy --_000_101C6067BEC68246B0C3F6843BCCC1E311FD92E6BDMCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
During IETF82 we discussed RTP & RTCP Multiplexing (RFC 5761) and = whether what we should say about this in the SIPREC protocol draft the conc= lusion was that this could be supported but we needed to confirm this.
 
I am not sure we really need to say anything about this in the protoco= l draft since support for it would of course be optional like many other SD= P attributes and I don’t see any specific relevant to SIPREC other th= an it being useful in reducing the number of ports used at the SRS and SRC.
 
I think it would be ok for the protocol draft to say that support for = this would be a good idea but don’t think we should make it mandatory= .
 
Any comments?
 
Regards
Andy
 
 
 --_000_101C6067BEC68246B0C3F6843BCCC1E311FD92E6BDMCHP058Agloba_-- From eckelcu@cisco.com Wed Jan 4 11:12:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970A321F85D5 for ; Wed, 4 Jan 2012 11:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZr6Hsuz0pxB for ; Wed, 4 Jan 2012 11:12:15 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 22DB621F85D4 for ; Wed, 4 Jan 2012 11:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1346; q=dns/txt; s=iport; t=1325704335; x=1326913935; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=nD5NsAZc9+MQFz0vVHop8QWS5S+djQVHI23CIpRHXCU=; b=Yw/1HTls96S+GW2m0NfyDypD0KWQI0djI+uRMxnZvsLv+DPBuIxTAJSG /sq/evdOvs6Ih0BBsvlDqViNj6oTpuCOgCAPk1Blfwy/y7rupVF0jbwxt XjHEC3GqAw/kT4zwJNHBvMKgb/vPKMkZ8ERJB8vA8rU1CqGXBeGvJbap4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADSkBE+rRDoI/2dsb2JhbABDggWqZIEFgXIBAQEEEgEdCksEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqfAQGeGossYwSIOJ8h X-IronPort-AV: E=Sophos;i="4.71,457,1320624000"; d="scan'208";a="23819837" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 04 Jan 2012 19:12:13 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q04JCD0q013808; Wed, 4 Jan 2012 19:12:13 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 11:12:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jan 2012 11:12:12 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpswAFMHoA References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , X-OriginalArrivalTime: 04 Jan 2012 19:12:13.0011 (UTC) FILETIME=[C3B51230:01CCCB14] Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 04 Jan 2012 19:12:15 -0000 Hi Andy, I agree with you, and I do not see a need for us to make RFC 5761 RTP & RTCP multiplexing MANDATORY. There is currently no recommendation for it in draft-eckelcu-siprec-rtp-rec. It is mentioned only to differentiate it from symmetric RTP/RTCP, which is MANDATORY when sending RTP/RTCP. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Wednesday, January 04, 2012 8:38 AM > To: siprec@ietf.org > Subject: [siprec] Multiplexing RTP & RTCP in SIPREC >=20 > Hi, >=20 > During IETF82 we discussed RTP & RTCP Multiplexing (RFC 5761) and > whether what we should say about this in the SIPREC protocol draft the > conclusion was that this could be supported but we needed to confirm > this. >=20 > I am not sure we really need to say anything about this in the protocol > draft since support for it would of course be optional like many other > SDP attributes and I don't see any specific relevant to SIPREC other > than it being useful in reducing the number of ports used at the SRS > and SRC. >=20 > I think it would be ok for the protocol draft to say that support for > this would be a good idea but don't think we should make it mandatory. >=20 > Any comments? >=20 > Regards > Andy >=20 >=20 From pkyzivat@alum.mit.edu Wed Jan 4 11:26:30 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0590611E80A5 for ; Wed, 4 Jan 2012 11:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 D4uOjnft3QRZ for ; Wed, 4 Jan 2012 11:26:29 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5C53F11E80A2 for ; Wed, 4 Jan 2012 11:26:29 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta13.westchester.pa.mail.comcast.net with comcast id HW0D1i0031uE5Es5DXSVyl; Wed, 04 Jan 2012 19:26:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id HXSV1i00J07duvL3cXSVJ4; Wed, 04 Jan 2012 19:26:29 +0000 Message-ID: <4F04A7E3.5060104@alum.mit.edu> Date: Wed, 04 Jan 2012 14:26:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 04 Jan 2012 19:26:30 -0000 On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: > Hi Andy, > > I agree with you, and I do not see a need for us to make RFC 5761 RTP& > RTCP multiplexing MANDATORY. There is currently no recommendation for it > in draft-eckelcu-siprec-rtp-rec. It is mentioned only to differentiate > it from symmetric RTP/RTCP, which is MANDATORY when sending RTP/RTCP. I agree it probably doesn't make sense to make it mandatory, nor to ban it. So from a spec perspective it may not be necessary to mention it at all. But given that there might be a large number of streams, it could be desirable to use. I guess the question would be whether we want to make it mandatory to support but optional to use. Thanks, Paul > Cheers, > Charles > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Wednesday, January 04, 2012 8:38 AM >> To: siprec@ietf.org >> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC >> >> Hi, >> >> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) and >> whether what we should say about this in the SIPREC protocol draft the >> conclusion was that this could be supported but we needed to confirm >> this. >> >> I am not sure we really need to say anything about this in the > protocol >> draft since support for it would of course be optional like many other >> SDP attributes and I don't see any specific relevant to SIPREC other >> than it being useful in reducing the number of ports used at the SRS >> and SRC. >> >> I think it would be ok for the protocol draft to say that support for >> this would be a good idea but don't think we should make it mandatory. >> >> Any comments? >> >> Regards >> Andy >> >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pravindran@sonusnet.com Wed Jan 4 17:01:31 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2C521F85B5 for ; Wed, 4 Jan 2012 17:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbDxUwkfSHg2 for ; Wed, 4 Jan 2012 17:01:30 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 360F321F85B4 for ; Wed, 4 Jan 2012 17:01:29 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0512AL8025405; Wed, 4 Jan 2012 20:02:10 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 20:01:26 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 06:32:15 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 5 Jan 2012 06:32:14 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpswAFMHoA//+pN4D//0dmIA== Date: Thu, 5 Jan 2012 01:02:12 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> <4F04A7E3.5060104@alum.mit.edu> In-Reply-To: <4F04A7E3.5060104@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 01:02:15.0158 (UTC) FILETIME=[A9F66160:01CCCB45] Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 05 Jan 2012 01:01:31 -0000 Paul, My understanding about rtcp-mux (RFC5761) attribute is optional to support = in SIPREC as per Sec 5.1.1 of RFC 5761 statement " If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute." Here in case SRS does not support RFC 5761, the answer to SRC will not have= "a=3Drtcp-mux" and SRC will fallback as per RFC suggestion. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Paul Kyzivat >Sent: Thursday, January 05, 2012 12:56 AM >To: siprec@ietf.org >Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC > >On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: >> Hi Andy, >> >> I agree with you, and I do not see a need for us to make RFC 5761 RTP& >> RTCP multiplexing MANDATORY. There is currently no recommendation for >> it in draft-eckelcu-siprec-rtp-rec. It is mentioned only to >> differentiate it from symmetric RTP/RTCP, which is MANDATORY when >sending RTP/RTCP. > >I agree it probably doesn't make sense to make it mandatory, nor to ban >it. So from a spec perspective it may not be necessary to mention it at >all. > >But given that there might be a large number of streams, it could be >desirable to use. I guess the question would be whether we want to make >it mandatory to support but optional to use. > > Thanks, > Paul > >> Cheers, >> Charles >> >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: Wednesday, January 04, 2012 8:38 AM >>> To: siprec@ietf.org >>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC >>> >>> Hi, >>> >>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) and >>> whether what we should say about this in the SIPREC protocol draft >>> the conclusion was that this could be supported but we needed to >>> confirm this. >>> >>> I am not sure we really need to say anything about this in the >> protocol >>> draft since support for it would of course be optional like many >>> other SDP attributes and I don't see any specific relevant to SIPREC >>> other than it being useful in reducing the number of ports used at >>> the SRS and SRC. >>> >>> I think it would be ok for the protocol draft to say that support for >>> this would be a good idea but don't think we should make it >mandatory. >>> >>> Any comments? >>> >>> Regards >>> Andy >>> >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Jan 4 17:21:14 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A7911E80CF for ; Wed, 4 Jan 2012 17:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 o1HNtvPmi+Oq for ; Wed, 4 Jan 2012 17:21:10 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 015D111E8099 for ; Wed, 4 Jan 2012 17:21:09 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id HdAE1i0030Fqzac54dMAZB; Thu, 05 Jan 2012 01:21:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id HdMA1i00H07duvL3UdMAKj; Thu, 05 Jan 2012 01:21:10 +0000 Message-ID: <4F04FB04.9000203@alum.mit.edu> Date: Wed, 04 Jan 2012 20:21:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> <4F04A7E3.5060104@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 05 Jan 2012 01:21:14 -0000 On 1/4/12 8:02 PM, Ravindran, Parthasarathi wrote: > Paul, > > My understanding about rtcp-mux (RFC5761) attribute is optional to support in SIPREC as per Sec 5.1.1 of RFC 5761 statement > > " If the answer does not contain an "a=rtcp-mux" attribute, the offerer > MUST NOT multiplex RTP and RTCP packets on a single port. Instead, > it should send and receive RTCP on a port allocated according to the > usual port-selection rules (either the port pair, or a signalled port > if the "a=rtcp:" attribute [10] is also included). This will occur > when talking to a peer that does not understand the "a=rtcp-mux" > attribute." > Here in case SRS does not support RFC 5761, the answer to SRC will not have "a=rtcp-mux" and SRC will fallback as per RFC suggestion. This implies that the offerer must reserve a port on which to receive rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp-mux is accepted it can free up that port. And even though RTP is one-way for siprec, the RTCP is two-way, so this can't be avoided for siprec. Thanks, Paul > Thanks > Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Thursday, January 05, 2012 12:56 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC >> >> On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: >>> Hi Andy, >>> >>> I agree with you, and I do not see a need for us to make RFC 5761 RTP& >>> RTCP multiplexing MANDATORY. There is currently no recommendation for >>> it in draft-eckelcu-siprec-rtp-rec. It is mentioned only to >>> differentiate it from symmetric RTP/RTCP, which is MANDATORY when >> sending RTP/RTCP. >> >> I agree it probably doesn't make sense to make it mandatory, nor to ban >> it. So from a spec perspective it may not be necessary to mention it at >> all. >> >> But given that there might be a large number of streams, it could be >> desirable to use. I guess the question would be whether we want to make >> it mandatory to support but optional to use. >> >> Thanks, >> Paul >> >>> Cheers, >>> Charles >>> >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Hutton, Andrew >>>> Sent: Wednesday, January 04, 2012 8:38 AM >>>> To: siprec@ietf.org >>>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC >>>> >>>> Hi, >>>> >>>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) and >>>> whether what we should say about this in the SIPREC protocol draft >>>> the conclusion was that this could be supported but we needed to >>>> confirm this. >>>> >>>> I am not sure we really need to say anything about this in the >>> protocol >>>> draft since support for it would of course be optional like many >>>> other SDP attributes and I don't see any specific relevant to SIPREC >>>> other than it being useful in reducing the number of ports used at >>>> the SRS and SRC. >>>> >>>> I think it would be ok for the protocol draft to say that support for >>>> this would be a good idea but don't think we should make it >> mandatory. >>>> >>>> Any comments? >>>> >>>> Regards >>>> Andy >>>> >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From pravindran@sonusnet.com Wed Jan 4 17:32:58 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FC211E80E6 for ; Wed, 4 Jan 2012 17:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9ZahZYkQcHh for ; Wed, 4 Jan 2012 17:32:51 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6D51B11E80E5 for ; Wed, 4 Jan 2012 17:32:51 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q051XVsU013326; Wed, 4 Jan 2012 20:33:31 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 20:32:48 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 07:03:36 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Thu, 5 Jan 2012 07:03:36 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat Thread-Topic: [siprec] Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpswAFMHoA//+pN4D//0dmIIABG7MA//+jjoD//0SQEA== Date: Thu, 5 Jan 2012 01:33:34 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC3BB3@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> <4F04A7E3.5060104@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com> <4F04FB04.9000203@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 01:33:36.0764 (UTC) FILETIME=[0B7CABC0:01CCCB4A] Cc: "siprec@ietf.org" Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 05 Jan 2012 01:32:58 -0000 Correction - "Optional to support" instead "optional to use"=20 >-----Original Message----- >From: Ravindran, Parthasarathi >Sent: Thursday, January 05, 2012 7:00 AM >To: 'Paul Kyzivat' >Cc: siprec@ietf.org >Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC > >Paul, > >We are in the same page for having two port allocation for RTCP when the >offer is sent by SRC/SRS and make it to single port after the >negotiation is done with answer. These kind of SIPREC implementation is >inline with any other RFC 5761 implementation. Please let me know >whether it is fine to make RFC 5761 as optional to support for SIPREC. > >Thanks >Partha > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>Sent: Thursday, January 05, 2012 6:51 AM >>To: Ravindran, Parthasarathi >>Cc: siprec@ietf.org >>Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC >> >>On 1/4/12 8:02 PM, Ravindran, Parthasarathi wrote: >>> Paul, >>> >>> My understanding about rtcp-mux (RFC5761) attribute is optional to >>> support in SIPREC as per Sec 5.1.1 of RFC 5761 statement >>> >>> " If the answer does not contain an "a=3Drtcp-mux" attribute, the >>offerer >>> MUST NOT multiplex RTP and RTCP packets on a single port. >>Instead, >>> it should send and receive RTCP on a port allocated according to >>the >>> usual port-selection rules (either the port pair, or a signalled >>port >>> if the "a=3Drtcp:" attribute [10] is also included). This will >>occur >>> when talking to a peer that does not understand the "a=3Drtcp-mux" >>> attribute." >> >>> Here in case SRS does not support RFC 5761, the answer to SRC will >>> not >>have "a=3Drtcp-mux" and SRC will fallback as per RFC suggestion. >> >>This implies that the offerer must reserve a port on which to receive >>rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp-mux >>is accepted it can free up that port. >> >>And even though RTP is one-way for siprec, the RTCP is two-way, so this >>can't be avoided for siprec. >> >> Thanks, >> Paul >> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Thursday, January 05, 2012 12:56 AM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC >>>> >>>> On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: >>>>> Hi Andy, >>>>> >>>>> I agree with you, and I do not see a need for us to make RFC 5761 >>>>> RTP& RTCP multiplexing MANDATORY. There is currently no >>>>> recommendation for it in draft-eckelcu-siprec-rtp-rec. It is >>>>> mentioned only to differentiate it from symmetric RTP/RTCP, which >>>>> is MANDATORY when >>>> sending RTP/RTCP. >>>> >>>> I agree it probably doesn't make sense to make it mandatory, nor to >>>> ban it. So from a spec perspective it may not be necessary to >>>> mention it at all. >>>> >>>> But given that there might be a large number of streams, it could be >>>> desirable to use. I guess the question would be whether we want to >>>> make it mandatory to support but optional to use. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Hutton, Andrew >>>>>> Sent: Wednesday, January 04, 2012 8:38 AM >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC >>>>>> >>>>>> Hi, >>>>>> >>>>>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) and >>>>>> whether what we should say about this in the SIPREC protocol draft >>>>>> the conclusion was that this could be supported but we needed to >>>>>> confirm this. >>>>>> >>>>>> I am not sure we really need to say anything about this in the >>>>> protocol >>>>>> draft since support for it would of course be optional like many >>>>>> other SDP attributes and I don't see any specific relevant to >>>>>> SIPREC other than it being useful in reducing the number of ports >>>>>> used at the SRS and SRC. >>>>>> >>>>>> I think it would be ok for the protocol draft to say that support >>>>>> for this would be a good idea but don't think we should make it >>>> mandatory. >>>>>> >>>>>> Any comments? >>>>>> >>>>>> Regards >>>>>> Andy >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> From pravindran@sonusnet.com Wed Jan 4 17:36:54 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF541F0C49 for ; Wed, 4 Jan 2012 17:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT6N1vA1DiOv for ; Wed, 4 Jan 2012 17:36:53 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5841F0C48 for ; Wed, 4 Jan 2012 17:36:53 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q051bZeF015924; Wed, 4 Jan 2012 20:37:35 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 20:29:54 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 07:00:42 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 5 Jan 2012 07:00:42 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat Thread-Topic: [siprec] Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpswAFMHoA//+pN4D//0dmIIABG7MA//+jjoA= Date: Thu, 5 Jan 2012 01:30:40 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC3BA2@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> <4F04A7E3.5060104@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com> <4F04FB04.9000203@alum.mit.edu> In-Reply-To: <4F04FB04.9000203@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 01:30:42.0903 (UTC) FILETIME=[A3DB9670:01CCCB49] Cc: "siprec@ietf.org" Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 05 Jan 2012 01:36:54 -0000 Paul, We are in the same page for having two port allocation for RTCP when the of= fer is sent by SRC/SRS and make it to single port after the negotiation is = done with answer. These kind of SIPREC implementation is inline with any ot= her RFC 5761 implementation. Please let me know whether it is fine to make = RFC 5761 as optional to use for SIPREC. Thanks Partha >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: Thursday, January 05, 2012 6:51 AM >To: Ravindran, Parthasarathi >Cc: siprec@ietf.org >Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC > >On 1/4/12 8:02 PM, Ravindran, Parthasarathi wrote: >> Paul, >> >> My understanding about rtcp-mux (RFC5761) attribute is optional to >> support in SIPREC as per Sec 5.1.1 of RFC 5761 statement >> >> " If the answer does not contain an "a=3Drtcp-mux" attribute, the >offerer >> MUST NOT multiplex RTP and RTCP packets on a single port. >Instead, >> it should send and receive RTCP on a port allocated according to >the >> usual port-selection rules (either the port pair, or a signalled >port >> if the "a=3Drtcp:" attribute [10] is also included). This will >occur >> when talking to a peer that does not understand the "a=3Drtcp-mux" >> attribute." > >> Here in case SRS does not support RFC 5761, the answer to SRC will not >have "a=3Drtcp-mux" and SRC will fallback as per RFC suggestion. > >This implies that the offerer must reserve a port on which to receive >rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp-mux >is accepted it can free up that port. > >And even though RTP is one-way for siprec, the RTCP is two-way, so this >can't be avoided for siprec. > > Thanks, > Paul > >> Thanks >> Partha >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, January 05, 2012 12:56 AM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC >>> >>> On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: >>>> Hi Andy, >>>> >>>> I agree with you, and I do not see a need for us to make RFC 5761 >>>> RTP& RTCP multiplexing MANDATORY. There is currently no >>>> recommendation for it in draft-eckelcu-siprec-rtp-rec. It is >>>> mentioned only to differentiate it from symmetric RTP/RTCP, which is >>>> MANDATORY when >>> sending RTP/RTCP. >>> >>> I agree it probably doesn't make sense to make it mandatory, nor to >>> ban it. So from a spec perspective it may not be necessary to mention >>> it at all. >>> >>> But given that there might be a large number of streams, it could be >>> desirable to use. I guess the question would be whether we want to >>> make it mandatory to support but optional to use. >>> >>> Thanks, >>> Paul >>> >>>> Cheers, >>>> Charles >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Hutton, Andrew >>>>> Sent: Wednesday, January 04, 2012 8:38 AM >>>>> To: siprec@ietf.org >>>>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC >>>>> >>>>> Hi, >>>>> >>>>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) and >>>>> whether what we should say about this in the SIPREC protocol draft >>>>> the conclusion was that this could be supported but we needed to >>>>> confirm this. >>>>> >>>>> I am not sure we really need to say anything about this in the >>>> protocol >>>>> draft since support for it would of course be optional like many >>>>> other SDP attributes and I don't see any specific relevant to >>>>> SIPREC other than it being useful in reducing the number of ports >>>>> used at the SRS and SRC. >>>>> >>>>> I think it would be ok for the protocol draft to say that support >>>>> for this would be a good idea but don't think we should make it >>> mandatory. >>>>> >>>>> Any comments? >>>>> >>>>> Regards >>>>> Andy >>>>> >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> From pravindran@sonusnet.com Thu Jan 5 09:16:51 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B8221F8859 for ; Thu, 5 Jan 2012 09:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 s-cZkXuLlbHV for ; Thu, 5 Jan 2012 09:16:49 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id A449021F8858 for ; Thu, 5 Jan 2012 09:16:49 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q05HHS53013252 for ; Thu, 5 Jan 2012 12:17:30 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 12:15:18 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 22:46:07 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 5 Jan 2012 22:46:06 +0530 From: "Ravindran, Parthasarathi" To: "siprec@ietf.org" Thread-Topic: Start & stop time for CS [was RE: IETF 82 Minutes.] Thread-Index: AQHMy821FXG9hLEz0USKI87oImfqFg== Date: Thu, 5 Jan 2012 17:16:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC3F71@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DC3F71inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 17:16:07.0417 (UTC) FILETIME=[B64D8690:01CCCBCD] Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] 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, 05 Jan 2012 17:16:51 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C01DC3F71inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Associate/disassociate time helps to understand how long CS is associated w= ith RS. Initial association time shall be considered as start time and fin= al disassociation time shall be considered as stop time. As we could not co= nclude this open item during IETF-82, I'm starting this mail thread for dis= cussion. I could not see any other strong reason for having start/stop time for CS a= part from associate/disassociate time. Please provide usecase for including= start/stop time attribute in CS. In case we could not see the proper usecase, it is better to remove from me= tadata draft. Thanks Partha Note: "Relevant IETF-82 notes" There was a comment to include start/Stop time also. Is it needed ? Start time seems to makes since RS may have started only after CS was start= ed. Stop time seems to be problematic in case of missing association. Probl= em to define start/stop time since a CS may include multiple SIP dialogs. Leon: start is useful, but there is a problem with stop - how is stop sent? Ram: Are there any use cases? Paul: Can do it for a dialog, but not for a CS which can be many dialogs, s= o not clear how you would define when the start time was but can identify w= hen participants join and leave. Brian: What do we need this for? Is there a need to track the times a CS is part of CS-Group ? Leon: This is needed for snapshot Paul: Example could be supervisor who joins a call center call to listen or= whisper might need to now when this happens. - might need this. Chairs: Need more discussion on use cases and whether this needs to be spec= ified or whether it is an extension. From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Friday, December 09, 2011 5:28 PM To: siprec@ietf.org Subject: [siprec] IETF 82 Minutes. SIPREC IETF82 minutes can be found at http://www.ietf.org/proceedings/82/mi= nutes/siprec.txt. Any issues with these then please let me know and I will check against the = audio and correct if necessary. Lets kick start some discussion on the open issues since we have all had a = few weeks now to recover after Taipei. Regards Andy --_000_387F9047F55E8C42850AD6B3A7A03C6C01DC3F71inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Associate/disassociate time helps to understand how long C= S is associated with RS. Initial association time shall be considered = as start time and final disassociation time shall be considered as stop time. As we could not conclude this open item during= IETF-82, I’m starting this mail thread for discussion.

 

I could not see any other strong reason for having start/s= top time for CS apart from associate/disassociate time. Please provide usec= ase for including start/stop time attribute in CS.

 

In case we could not see the proper usecase, it is better = to remove from metadata draft.

 

Thanks

Partha

 

Note: “Relevant IETF-82 notes”

 

There was a comment to include start/Stop time also. Is it= needed ?

Start time seems to makes since RS may have started only a= fter CS was started. Stop time seems to be problematic in case of missing a= ssociation. Problem to define start/stop time since a CS may include multiple SIP dialogs.

 

Leon: start is useful, but there is a problem with stop - = how is stop sent?

Ram: Are there any use cases?

Paul: Can do it for a dialog, but not for a CS which can b= e many dialogs, so not clear how you would define when the start time was b= ut can identify when participants join and leave.

Brian: What do we need this for?

 

Is there a need to track the times a CS is part of CS-Grou= p ?

Leon: This is needed for snapshot

Paul: Example could be supervisor who joins a call center = call to listen or whisper might need to now when this happens. - might need= this.

Chairs: Need more discussion on use cases and whether this= needs to be specified or whether it is an extension.

 

 

 <= /p>

 <= /p>

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: Friday, December 09, 2011 5:28 PM
To: siprec@ietf.org
Subject: [siprec] IETF 82 Minutes.

 

SIPREC IETF82 minutes can be found at http://ww= w.ietf.org/proceedings/82/minutes/siprec.txt.<= /p>

 

Any issues with these then please let m= e know and I will check against the audio and correct if necessary.

 

Lets kick start some discussion on the = open issues since we have all had a few weeks now to recover after Taipei.<= o:p>

 

Regards

Andy

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C01DC3F71inbamail01sonus_-- From andrew.hutton@siemens-enterprise.com Mon Jan 9 02:58:34 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3A121F8701 for ; Mon, 9 Jan 2012 02:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 VxawgxNu2bZO for ; Mon, 9 Jan 2012 02:58:30 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id BA30121F846C for ; Mon, 9 Jan 2012 02:58:29 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3E6FE23F03F1; Mon, 9 Jan 2012 11:58:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 9 Jan 2012 11:58:26 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" , Brian Rosen Date: Mon, 9 Jan 2012 11:58:24 +0100 Thread-Topic: Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 Thread-Index: Acy2kF4m4Fu11k7CS7uNQ8B5GkBYBAFeu3pgAGyVRzAAA58OwAQ79K7Q Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net> 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_101C6067BEC68246B0C3F6843BCCC1E312001ECA44MCHP058Agloba_" MIME-Version: 1.0 Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 09 Jan 2012 10:58:34 -0000 --_000_101C6067BEC68246B0C3F6843BCCC1E312001ECA44MCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The poll is now closed we only had 6 people who stated they would attend of= which at least a couple probably did so simply because they will be at the= CLUE meeting anyway. I don't consider this enough interest to call a face to face meeting. So my proposal is that we should make a big effort to get more contribution= s on the list and get the editors to update the drafts to get us in good sh= ape for a productive meeting in Paris. I am assuming the working group wi= ll require the usual 2 hour meeting time during IETF83 and I will book this= . I will do my best to keep discussion going on the list and drive some decis= ions. Regards Andy (SIPREC Co-Chair). From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: 18 December 2011 21:30 To: siprec@ietf.org Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 Hi All, I created a doodle poll to register an indication of whether or not you wou= ld attend a face to face SIPREC Interim meeting if it was held in the Bosto= n (US) area on the 17th of February (i.e. day after the CLUE meeting). The= venue for such a meeting would most likely be the same as for the CLUE mee= ting (i.e. Polycom office in Andover, MA) unless we get a large number of p= eople. Remote participation would be possible but this poll is for the purpose of = understanding who would actually attend in person. http://www.doodle.com/q3555taia7xbpmt2 This poll will close on the 6th of January after which the chairs will make= a decision as to whether the meeting should take place. Regards Andy --_000_101C6067BEC68246B0C3F6843BCCC1E312001ECA44MCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The poll is now closed we only had 6 people wh= o stated they would attend of which at least a couple probably did so simpl= y because they will be at the CLUE meeting anyway.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>I don’t consider this enough interest to call a face to face me= eting.

 

So my proposal is that we should make = a big effort to get more contributions on the list and get the editors to u= pdate the drafts to get us in good shape for a productive meeting in Paris.=   I am assuming  the working group will require the usual 2 hour = meeting time during IETF83 and I will book this.

 

I will do my best to keep discussion going on the list and drive some d= ecisions.

 

Regards

Andy (SIPREC Co-Chair).

 

 

 <= /span>

 

 

From: siprec-bounces@ietf.org [mailt= o:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: 18 December 2011 21:30
To: siprec@ietf.org
Subject: = [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012

 

Hi All,

 

I created a doodl= e poll to register an indication of whether or not you would attend a face = to face SIPREC Interim meeting if it was held in the Boston (US) area on th= e 17th of February (i.e. day after the CLUE meeting).  The = venue for such a meeting would most likely be the same as for the CLUE meet= ing (i.e. Polycom office in Andover, MA) unless we get a large number of pe= ople.

 

Remote participation would be possible = but this poll is for the purpose of understanding who would actually attend= in person.

 

http://www.doodle.com/q3555= taia7xbpmt2

 

This poll will close on the 6th of January after which the chai= rs will make a decision as to whether the meeting should take place.

 

Regards

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Andy

 

= --_000_101C6067BEC68246B0C3F6843BCCC1E312001ECA44MCHP058Agloba_-- From eckelcu@cisco.com Mon Jan 9 09:06:44 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470C311E8093 for ; Mon, 9 Jan 2012 09:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNeDWqHIwi+Y for ; Mon, 9 Jan 2012 09:06:40 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E011E8097 for ; Mon, 9 Jan 2012 09:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3037; q=dns/txt; s=iport; t=1326128800; x=1327338400; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Rfxmi/pe029VS4+wsX8jHMcvd29YgrCnptAb/0SS7XM=; b=dPX050PODadjesaT5Ngbg9KcXKPc31ppidIVg+zS9hHGpkmMrH6G/klo Imz5MTMj1mPhOxmGVuGtMfUYJFL2ZpW7ZRp4qG6ciRVNP/+nPzRSNrqH5 UrUrZEFhUXXTemrAHp/eeExdr5h4UvsbbrfeuYNY+/Yywi2ofyj895pKg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI0dC0+rRDoI/2dsb2JhbABErFOBBYFyAQEBBBIBHQpLBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2CXeQGeQosuYwSIOZ8q X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; d="scan'208";a="24488005" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Jan 2012 17:06:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q09H6ddO009247; Mon, 9 Jan 2012 17:06:39 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 09:06:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2012 09:06:37 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 Thread-Index: Acy2kF4m4Fu11k7CS7uNQ8B5GkBYBAFeu3pgAGyVRzAAA58OwAQ79K7QAAzwgYA= References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , , "Brian Rosen" X-OriginalArrivalTime: 09 Jan 2012 17:06:39.0402 (UTC) FILETIME=[0D6450A0:01CCCEF1] Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 09 Jan 2012 17:06:44 -0000 Hi Andy, I see 6 people, not counting either of the co-chairs, plus I know of a few others who are considering attending but could not commit at this point for various reasons. It seems to me we are at a point where some white board sessions would be helpful to run through various signaling and media flow scenarios. These tend to be tedious and difficult to discuss via e-mail. IETF sessions tend to be more presentation and discussion oriented, so I think having a face to face working meeting outside of the normal IETF time slot would be beneficial. Doing this Feb 17 in conjunction with the CLUE interim meeting sounds ideal to me; however, if that timing does not work, perhaps we can consider another time/location. Just my 2 cents. Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Monday, January 09, 2012 2:58 AM > To: siprec@ietf.org; Brian Rosen > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area,Feb > 17th 2012 >=20 > Hi All, >=20 >=20 >=20 > The poll is now closed we only had 6 people who stated they would > attend of which at least a couple probably did so simply because they > will be at the CLUE meeting anyway. >=20 >=20 >=20 > I don't consider this enough interest to call a face to face meeting. >=20 >=20 >=20 > So my proposal is that we should make a big effort to get more > contributions on the list and get the editors to update the drafts to > get us in good shape for a productive meeting in Paris. I am assuming > the working group will require the usual 2 hour meeting time during > IETF83 and I will book this. >=20 >=20 >=20 > I will do my best to keep discussion going on the list and drive some > decisions. >=20 >=20 >=20 > Regards >=20 > Andy (SIPREC Co-Chair). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: 18 December 2011 21:30 > To: siprec@ietf.org > Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th > 2012 >=20 >=20 >=20 > Hi All, >=20 >=20 >=20 > I created a doodle poll to register an indication of whether or not you > would attend a face to face SIPREC Interim meeting if it was held in > the Boston (US) area on the 17th of February (i.e. day after the CLUE > meeting). The venue for such a meeting would most likely be the same > as for the CLUE meeting (i.e. Polycom office in Andover, MA) unless we > get a large number of people. >=20 >=20 >=20 > Remote participation would be possible but this poll is for the purpose > of understanding who would actually attend in person. >=20 >=20 >=20 > http://www.doodle.com/q3555taia7xbpmt2 >=20 >=20 >=20 > This poll will close on the 6th of January after which the chairs will > make a decision as to whether the meeting should take place. >=20 >=20 >=20 > Regards >=20 > Andy >=20 >=20 From pravindran@sonusnet.com Mon Jan 9 09:19:19 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DFB11E809B for ; Mon, 9 Jan 2012 09:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 2+lrM8v7OuvJ for ; Mon, 9 Jan 2012 09:19:18 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3A11E809A for ; Mon, 9 Jan 2012 09:19:17 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q09HJxBv014704; Mon, 9 Jan 2012 12:19:59 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 12:19:15 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 22:50:06 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Mon, 9 Jan 2012 22:50:06 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.] Thread-Index: AQHMwZZ9GaMczMqmT0qGBx+j73zrGJYEBkAA Date: Mon, 9 Jan 2012 17:20:04 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DAEE64@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DAEE64@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jan 2012 17:20:06.0960 (UTC) FILETIME=[EEBBE300:01CCCEF2] Subject: Re: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.] 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, 09 Jan 2012 17:19:19 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Even though CNAME attribute is used to find the multiplex RTP in some deplo= yments, it is possible to have multiple CNAME and not a generic attribute i= n SIPREC metadata as per discussion in IETF-82. Based on these discussion, = I think that CNAME attribute has to be considered as part of the extension = data of Metadata. Please let me know in case anybody have difference of opi= nion with this approach. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ravindran, Parthasarathi Sent: Friday, December 23, 2011 10:46 PM To: Hutton, Andrew; siprec@ietf.org Subject: [siprec] CNAME attribute in participant metadata element [was RE: = IETF 82 Minutes.] Hi all, As per IETF-82 meeting, we need to discuss in detail whether CNAME attribut= e has to be part of participant metadata element. The initial idea is to ma= p CNAME to participant id but it is complicated in some of the cases as men= tioned in IETF-82. I attached the relevant IETF-82 discussion as a note of = this mail. Let us discuss in this mail thread for the need of CNAME attribu= te and the issues related to it. Thanks Partha Note: Open Item: Metadata Model: Participant / Carry CNAME as participant attribu= te Any objections to having a new attribute in Participant class to represent = CNAME? This could be useful, but might not work in more complicated cases (= e.g. recordings of conferences). Paul: You need something. Magnus: It is a good idea but maybe not the main use case at the moment. Hadriel: Could have two different CNAMEs for the same endpoint if they are = not sync so not a participant identifier. Ram: Useful for correlation Charles: We are not using it as participant ID, but could be used to map to= a participant. Paul: It can get complicated Brian: Doesn't mean we can't try Hadriel: Can hurt if people expect this information Brian: We aren't chartered to come up with identifier for multiple devices = or users Hadriel: This is not really a solution to this problem Paul: Defer this as it needs more investigation Charles: Andy: Needs more discussion From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Friday, December 09, 2011 5:28 PM To: siprec@ietf.org Subject: [siprec] IETF 82 Minutes. SIPREC IETF82 minutes can be found at http://www.ietf.org/proceedings/82/mi= nutes/siprec.txt. Any issues with these then please let me know and I will check against the = audio and correct if necessary. Lets kick start some discussion on the open issues since we have all had a = few weeks now to recover after Taipei. Regards Andy --_000_387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

 <= /p>

Even though CNAME attribu= te is used to find the multiplex RTP in some deployments, it is possible to= have multiple CNAME and not a generic attribute in SIPREC metadata as per discussion in IETF-82. Based on these discussion, I think = that CNAME attribute has to be considered as part of the extension data of = Metadata. Please let me know in case anybody have difference of opinion wit= h this approach.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

 <= /p>

 <= /p>

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi
Sent: Friday, December 23, 2011 10:46 PM
To: Hutton, Andrew; siprec@ietf.org
Subject: [siprec] CNAME attribute in participant metadata element [w= as RE: IETF 82 Minutes.]

 

Hi all,

 

As per IETF-82 meeting, we need to discuss in detail wheth= er CNAME attribute has to be part of participant metadata element. The init= ial idea is to map CNAME to participant id but it is complicated in some of the cases as mentioned in IETF-82. I attached= the relevant IETF-82 discussion as a note of this mail. Let us discuss in = this mail thread for the need of CNAME attribute and the issues related to = it.

 

Thanks

Partha

 

 

Note:

Open Item: Metadata Model: Participant / Carry CNAME as pa= rticipant attribute

Any objections to having a new attribute in Participant cl= ass to represent CNAME? This could be useful, but might not work in more co= mplicated cases (e.g. recordings of conferences).

 

Paul: You need something.

Magnus: It is a good idea but maybe not the main use case = at the moment.

Hadriel: Could have two different CNAMEs for the same endp= oint if they are not sync so not a participant identifier.

Ram: Useful for correlation

Charles: We are not using it as participant ID, but could = be used to map to a participant.

Paul: It can get complicated

Brian: Doesn't mean we can't try

Hadriel: Can hurt if people expect this information

Brian: We aren't chartered to come up with identifier for = multiple devices or users

Hadriel: This is not really a solution to this problem

Paul: Defer this as it needs more investigation=

Charles:

Andy: Needs more discussion

 

 <= /p>

 <= /p>

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: Friday, December 09, 2011 5:28 PM
To: siprec@ietf.org
Subject: [siprec] IETF 82 Minutes.

 

SIPREC IETF82 minutes can be found at http://ww= w.ietf.org/proceedings/82/minutes/siprec.txt.<= /p>

 

Any issues with these then please let m= e know and I will check against the audio and correct if necessary.

 

Lets kick start some discussion on the = open issues since we have all had a few weeks now to recover after Taipei.<= o:p>

 

Regards

Andy

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9inbamail01sonus_-- From eckelcu@cisco.com Mon Jan 9 09:40:48 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2E011E80E8 for ; Mon, 9 Jan 2012 09:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujbMpAISwk9s for ; Mon, 9 Jan 2012 09:40:44 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A5A0111E80BD for ; Mon, 9 Jan 2012 09:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4128; q=dns/txt; s=iport; t=1326130844; x=1327340444; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=hCmJPTzTSKhK/D4nlErpjXQwzLkMt6QxG71xLR2AuVM=; b=CfLzzNWwucy53b6G++xTbObg5DoP8TDzgTe+EuGUc2aTbbctVeoOwbf2 xYZWRKbDho0v5rZwcT30bG5Xo+WakoO6cdokQ7p6VzVLdJ5J1h0+5y/cM oiAw2bx3XlQyukizLH5fpXK5wsnrQCdjYIREYRymf3UGZsKR94SL/ZcnI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQAAGclC0+rRDoH/2dsb2JhbABEnBaQPYEFgXIBAQEEEgEdCi4dBAIBCBEEAQELBhcBBgFFCQgCBAESCAESB4dgl3oBnkGLLmMEiDmfKg X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; d="scan'208";a="24493650" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 09 Jan 2012 17:40:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q09Hei42013914; Mon, 9 Jan 2012 17:40:44 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 09:40:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2012 09:40:41 -0800 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.] Thread-Index: AQHMwZZ9GaMczMqmT0qGBx+j73zrGJYEBkAAgABe/gA= References: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net><387F9047F55E8C42850AD6B3A7A03C6C01DAEE64@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9@inba-mail01.sonusnet.com> From: "Charles Eckel (eckelcu)" To: "Ravindran, Parthasarathi" , "Hutton, Andrew" , X-OriginalArrivalTime: 09 Jan 2012 17:40:44.0347 (UTC) FILETIME=[D04628B0:01CCCEF5] Subject: Re: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.] 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, 09 Jan 2012 17:40:48 -0000 Hi Partha, I think it will be useful for the SRC to be able to inform the SRS for any CNAME values it knows are associated with a participant. This information may often make it through the SRC to the SRS via RTCP, but in some cases, it may not. Ideally there will always be a single CNAME per participant; however, as discussed at IETF 82, there are times when there may be multiple different CNAMES for media associated with a single participant. For now, I am okay with leaving the CNAME as extension data. As we continue to work through the media flows in more detail, we can adjust if necessary. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: Monday, January 09, 2012 9:20 AM > To: Hutton, Andrew; siprec@ietf.org > Subject: Re: [siprec] CNAME attribute in participant metadata element > [was RE: IETF 82 Minutes.] >=20 > Hi all, >=20 >=20 >=20 > Even though CNAME attribute is used to find the multiplex RTP in some > deployments, it is possible to have multiple CNAME and not a generic > attribute in SIPREC metadata as per discussion in IETF-82. Based on > these discussion, I think that CNAME attribute has to be considered as > part of the extension data of Metadata. Please let me know in case > anybody have difference of opinion with this approach. >=20 >=20 >=20 > Thanks >=20 > Partha >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: Friday, December 23, 2011 10:46 PM > To: Hutton, Andrew; siprec@ietf.org > Subject: [siprec] CNAME attribute in participant metadata element [was > RE: IETF 82 Minutes.] >=20 >=20 >=20 > Hi all, >=20 >=20 >=20 > As per IETF-82 meeting, we need to discuss in detail whether CNAME > attribute has to be part of participant metadata element. The initial > idea is to map CNAME to participant id but it is complicated in some of > the cases as mentioned in IETF-82. I attached the relevant IETF-82 > discussion as a note of this mail. Let us discuss in this mail thread > for the need of CNAME attribute and the issues related to it. >=20 >=20 >=20 > Thanks >=20 > Partha >=20 >=20 >=20 >=20 >=20 > Note: >=20 > Open Item: Metadata Model: Participant / Carry CNAME as participant > attribute >=20 > Any objections to having a new attribute in Participant class to > represent CNAME? This could be useful, but might not work in more > complicated cases (e.g. recordings of conferences). >=20 >=20 >=20 > Paul: You need something. >=20 > Magnus: It is a good idea but maybe not the main use case at the > moment. >=20 > Hadriel: Could have two different CNAMEs for the same endpoint if they > are not sync so not a participant identifier. >=20 > Ram: Useful for correlation >=20 > Charles: We are not using it as participant ID, but could be used to > map to a participant. >=20 > Paul: It can get complicated >=20 > Brian: Doesn't mean we can't try >=20 > Hadriel: Can hurt if people expect this information >=20 > Brian: We aren't chartered to come up with identifier for multiple > devices or users >=20 > Hadriel: This is not really a solution to this problem >=20 > Paul: Defer this as it needs more investigation >=20 > Charles: >=20 > Andy: Needs more discussion >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Friday, December 09, 2011 5:28 PM > To: siprec@ietf.org > Subject: [siprec] IETF 82 Minutes. >=20 >=20 >=20 > SIPREC IETF82 minutes can be found at > http://www.ietf.org/proceedings/82/minutes/siprec.txt. >=20 >=20 >=20 > Any issues with these then please let me know and I will check against > the audio and correct if necessary. >=20 >=20 >=20 > Lets kick start some discussion on the open issues since we have all > had a few weeks now to recover after Taipei. >=20 >=20 >=20 > Regards >=20 > Andy >=20 >=20 From pravindran@sonusnet.com Mon Jan 9 15:54:11 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD81F0C3D for ; Mon, 9 Jan 2012 15:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi+blr70mgB6 for ; Mon, 9 Jan 2012 15:54:10 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 903C61F0C36 for ; Mon, 9 Jan 2012 15:54:10 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q09NsoWU013652; Mon, 9 Jan 2012 18:54:50 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 18:54:06 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 05:24:58 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Tue, 10 Jan 2012 05:24:58 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.] Thread-Index: AQHMwZZ9GaMczMqmT0qGBx+j73zrGJYEBkAAgABe/gCAAGk6UA== Date: Mon, 9 Jan 2012 23:54:57 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC5B33@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net><387F9047F55E8C42850AD6B3A7A03C6C01DAEE64@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jan 2012 23:54:58.0791 (UTC) FILETIME=[182A6770:01CCCF2A] Subject: Re: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.] 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, 09 Jan 2012 23:54:11 -0000 Hi Charles, Thanks for the quick closure of this open item in Metadata draft.=20 Hi all, Charles had request for this attribute initially. As discussed below, the a= uthors will update metadata draft in the next revision in case we didn't he= ar any objection for a week time. Thanks Partha >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Monday, January 09, 2012 11:11 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; siprec@ietf.org >Subject: RE: [siprec] CNAME attribute in participant metadata element >[was RE: IETF 82 Minutes.] > >Hi Partha, > >I think it will be useful for the SRC to be able to inform the SRS for >any CNAME values it knows are associated with a participant. This >information may often make it through the SRC to the SRS via RTCP, but >in some cases, it may not. Ideally there will always be a single CNAME >per participant; however, as discussed at IETF 82, there are times when >there may be multiple different CNAMES for media associated with a >single participant. >For now, I am okay with leaving the CNAME as extension data. As we >continue to work through the media flows in more detail, we can adjust >if necessary. > >Cheers, >Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: Monday, January 09, 2012 9:20 AM >> To: Hutton, Andrew; siprec@ietf.org >> Subject: Re: [siprec] CNAME attribute in participant metadata element >> [was RE: IETF 82 Minutes.] >> >> Hi all, >> >> >> >> Even though CNAME attribute is used to find the multiplex RTP in some >> deployments, it is possible to have multiple CNAME and not a generic >> attribute in SIPREC metadata as per discussion in IETF-82. Based on >> these discussion, I think that CNAME attribute has to be considered as >> part of the extension data of Metadata. Please let me know in case >> anybody have difference of opinion with this approach. >> >> >> >> Thanks >> >> Partha >> >> >> >> >> >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: Friday, December 23, 2011 10:46 PM >> To: Hutton, Andrew; siprec@ietf.org >> Subject: [siprec] CNAME attribute in participant metadata element [was >> RE: IETF 82 Minutes.] >> >> >> >> Hi all, >> >> >> >> As per IETF-82 meeting, we need to discuss in detail whether CNAME >> attribute has to be part of participant metadata element. The initial >> idea is to map CNAME to participant id but it is complicated in some >of >> the cases as mentioned in IETF-82. I attached the relevant IETF-82 >> discussion as a note of this mail. Let us discuss in this mail thread >> for the need of CNAME attribute and the issues related to it. >> >> >> >> Thanks >> >> Partha >> >> >> >> >> >> Note: >> >> Open Item: Metadata Model: Participant / Carry CNAME as participant >> attribute >> >> Any objections to having a new attribute in Participant class to >> represent CNAME? This could be useful, but might not work in more >> complicated cases (e.g. recordings of conferences). >> >> >> >> Paul: You need something. >> >> Magnus: It is a good idea but maybe not the main use case at the >> moment. >> >> Hadriel: Could have two different CNAMEs for the same endpoint if they >> are not sync so not a participant identifier. >> >> Ram: Useful for correlation >> >> Charles: We are not using it as participant ID, but could be used to >> map to a participant. >> >> Paul: It can get complicated >> >> Brian: Doesn't mean we can't try >> >> Hadriel: Can hurt if people expect this information >> >> Brian: We aren't chartered to come up with identifier for multiple >> devices or users >> >> Hadriel: This is not really a solution to this problem >> >> Paul: Defer this as it needs more investigation >> >> Charles: >> >> Andy: Needs more discussion >> >> >> >> >> >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Friday, December 09, 2011 5:28 PM >> To: siprec@ietf.org >> Subject: [siprec] IETF 82 Minutes. >> >> >> >> SIPREC IETF82 minutes can be found at >> http://www.ietf.org/proceedings/82/minutes/siprec.txt. >> >> >> >> Any issues with these then please let me know and I will check against >> the audio and correct if necessary. >> >> >> >> Lets kick start some discussion on the open issues since we have all >> had a few weeks now to recover after Taipei. >> >> >> >> Regards >> >> Andy >> >> From Leon.Portman@nice.com Tue Jan 10 06:39:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C86821F855E for ; Tue, 10 Jan 2012 06:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7ic7q2Smbms for ; Tue, 10 Jan 2012 06:39:49 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id AB50621F8569 for ; Tue, 10 Jan 2012 06:39:48 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 10 Jan 2012 16:39:45 +0200 From: Leon Portman To: "Ravindran, Parthasarathi" , "Charles Eckel (eckelcu)" , "Hutton, Andrew" , "siprec@ietf.org" Date: Tue, 10 Jan 2012 16:39:44 +0200 Thread-Topic: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.] Thread-Index: AQHMwZZ9GaMczMqmT0qGBx+j73zrGJYEBkAAgABe/gCAAGk6UIAA+aGQ Message-ID: <07465C1D981ABC41A344374066AE1A2C3927E3CEF6@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net><387F9047F55E8C42850AD6B3A7A03C6C01DAEE64@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DC5AC9@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DC5B33@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC5B33@inba-mail01.sonusnet.com> 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 Subject: Re: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.] 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, 10 Jan 2012 14:39:50 -0000 I am ok with that as well (representing SRS side). Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ravindran, Parthasarathi Sent: Tuesday, January 10, 2012 1:55 AM To: Charles Eckel (eckelcu); Hutton, Andrew; siprec@ietf.org Subject: Re: [siprec] CNAME attribute in participant metadata element [was = RE: IETF 82 Minutes.] Hi Charles, Thanks for the quick closure of this open item in Metadata draft.=20 Hi all, Charles had request for this attribute initially. As discussed below, the a= uthors will update metadata draft in the next revision in case we didn't he= ar any objection for a week time. Thanks Partha >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Monday, January 09, 2012 11:11 PM >To: Ravindran, Parthasarathi; Hutton, Andrew; siprec@ietf.org >Subject: RE: [siprec] CNAME attribute in participant metadata element=20 >[was RE: IETF 82 Minutes.] > >Hi Partha, > >I think it will be useful for the SRC to be able to inform the SRS for=20 >any CNAME values it knows are associated with a participant. This=20 >information may often make it through the SRC to the SRS via RTCP, but=20 >in some cases, it may not. Ideally there will always be a single CNAME=20 >per participant; however, as discussed at IETF 82, there are times when=20 >there may be multiple different CNAMES for media associated with a=20 >single participant. >For now, I am okay with leaving the CNAME as extension data. As we=20 >continue to work through the media flows in more detail, we can adjust=20 >if necessary. > >Cheers, >Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Ravindran, Parthasarathi >> Sent: Monday, January 09, 2012 9:20 AM >> To: Hutton, Andrew; siprec@ietf.org >> Subject: Re: [siprec] CNAME attribute in participant metadata element=20 >> [was RE: IETF 82 Minutes.] >> >> Hi all, >> >> >> >> Even though CNAME attribute is used to find the multiplex RTP in some=20 >> deployments, it is possible to have multiple CNAME and not a generic=20 >> attribute in SIPREC metadata as per discussion in IETF-82. Based on=20 >> these discussion, I think that CNAME attribute has to be considered=20 >> as part of the extension data of Metadata. Please let me know in case=20 >> anybody have difference of opinion with this approach. >> >> >> >> Thanks >> >> Partha >> >> >> >> >> >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Ravindran, Parthasarathi >> Sent: Friday, December 23, 2011 10:46 PM >> To: Hutton, Andrew; siprec@ietf.org >> Subject: [siprec] CNAME attribute in participant metadata element=20 >> [was >> RE: IETF 82 Minutes.] >> >> >> >> Hi all, >> >> >> >> As per IETF-82 meeting, we need to discuss in detail whether CNAME=20 >> attribute has to be part of participant metadata element. The initial=20 >> idea is to map CNAME to participant id but it is complicated in some >of >> the cases as mentioned in IETF-82. I attached the relevant IETF-82=20 >> discussion as a note of this mail. Let us discuss in this mail thread=20 >> for the need of CNAME attribute and the issues related to it. >> >> >> >> Thanks >> >> Partha >> >> >> >> >> >> Note: >> >> Open Item: Metadata Model: Participant / Carry CNAME as participant=20 >> attribute >> >> Any objections to having a new attribute in Participant class to=20 >> represent CNAME? This could be useful, but might not work in more=20 >> complicated cases (e.g. recordings of conferences). >> >> >> >> Paul: You need something. >> >> Magnus: It is a good idea but maybe not the main use case at the=20 >> moment. >> >> Hadriel: Could have two different CNAMEs for the same endpoint if=20 >> they are not sync so not a participant identifier. >> >> Ram: Useful for correlation >> >> Charles: We are not using it as participant ID, but could be used to=20 >> map to a participant. >> >> Paul: It can get complicated >> >> Brian: Doesn't mean we can't try >> >> Hadriel: Can hurt if people expect this information >> >> Brian: We aren't chartered to come up with identifier for multiple=20 >> devices or users >> >> Hadriel: This is not really a solution to this problem >> >> Paul: Defer this as it needs more investigation >> >> Charles: >> >> Andy: Needs more discussion >> >> >> >> >> >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Hutton, Andrew >> Sent: Friday, December 09, 2011 5:28 PM >> To: siprec@ietf.org >> Subject: [siprec] IETF 82 Minutes. >> >> >> >> SIPREC IETF82 minutes can be found at=20 >> http://www.ietf.org/proceedings/82/minutes/siprec.txt. >> >> >> >> Any issues with these then please let me know and I will check=20 >> against the audio and correct if necessary. >> >> >> >> Lets kick start some discussion on the open issues since we have all=20 >> had a few weeks now to recover after Taipei. >> >> >> >> Regards >> >> Andy >> >> _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Tue Jan 10 06:40:48 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA9321F8569 for ; Tue, 10 Jan 2012 06:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=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 L4G08hkgUH38 for ; Tue, 10 Jan 2012 06:40:47 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id E3B3521F858E for ; Tue, 10 Jan 2012 06:40:46 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 10 Jan 2012 16:40:44 +0200 From: Leon Portman To: "Charles Eckel (eckelcu)" , "Hutton, Andrew" , "siprec@ietf.org" , Brian Rosen Date: Tue, 10 Jan 2012 16:40:43 +0200 Thread-Topic: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 Thread-Index: Acy2kF4m4Fu11k7CS7uNQ8B5GkBYBAFeu3pgAGyVRzAAA58OwAQ79K7QAAzwgYAALYQwcA== Message-ID: <07465C1D981ABC41A344374066AE1A2C3927E3CEF7@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 10 Jan 2012 14:40:48 -0000 Good suggestion. +2 (me and developer) Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Monday, January 09, 2012 7:07 PM To: Hutton, Andrew; siprec@ietf.org; Brian Rosen Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th = 2012 Hi Andy, I see 6 people, not counting either of the co-chairs, plus I know of a few = others who are considering attending but could not commit at this point for= various reasons. It seems to me we are at a point where some white board sessions would be h= elpful to run through various signaling and media flow scenarios. These tend to be tedious and difficult to discuss via e-mail. IETF sessions= tend to be more presentation and discussion oriented, so I think having a = face to face working meeting outside of the normal IETF time slot would be = beneficial. Doing this Feb 17 in conjunction with the CLUE interim meeting = sounds ideal to me; however, if that timing does not work, perhaps we can c= onsider another time/location. Just my 2 cents. Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hutton, Andrew > Sent: Monday, January 09, 2012 2:58 AM > To: siprec@ietf.org; Brian Rosen > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area,Feb=20 > 17th 2012 >=20 > Hi All, >=20 >=20 >=20 > The poll is now closed we only had 6 people who stated they would=20 > attend of which at least a couple probably did so simply because they=20 > will be at the CLUE meeting anyway. >=20 >=20 >=20 > I don't consider this enough interest to call a face to face meeting. >=20 >=20 >=20 > So my proposal is that we should make a big effort to get more=20 > contributions on the list and get the editors to update the drafts to=20 > get us in good shape for a productive meeting in Paris. I am assuming=20 > the working group will require the usual 2 hour meeting time during > IETF83 and I will book this. >=20 >=20 >=20 > I will do my best to keep discussion going on the list and drive some=20 > decisions. >=20 >=20 >=20 > Regards >=20 > Andy (SIPREC Co-Chair). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hutton, Andrew > Sent: 18 December 2011 21:30 > To: siprec@ietf.org > Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th > 2012 >=20 >=20 >=20 > Hi All, >=20 >=20 >=20 > I created a doodle poll to register an indication of whether or not you > would attend a face to face SIPREC Interim meeting if it was held in=20 > the Boston (US) area on the 17th of February (i.e. day after the CLUE=20 > meeting). The venue for such a meeting would most likely be the same=20 > as for the CLUE meeting (i.e. Polycom office in Andover, MA) unless we=20 > get a large number of people. >=20 >=20 >=20 > Remote participation would be possible but this poll is for the purpose > of understanding who would actually attend in person. >=20 >=20 >=20 > http://www.doodle.com/q3555taia7xbpmt2 >=20 >=20 >=20 > This poll will close on the 6th of January after which the chairs will=20 > make a decision as to whether the meeting should take place. >=20 >=20 >=20 > Regards >=20 > Andy >=20 >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Tue Jan 10 06:45:59 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FCD21F85D4 for ; Tue, 10 Jan 2012 06:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 O+qLVJvJztAe for ; Tue, 10 Jan 2012 06:45:57 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id B811521F84D6 for ; Tue, 10 Jan 2012 06:45:56 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 10 Jan 2012 16:45:55 +0200 From: Leon Portman To: "Ravindran, Parthasarathi" , "siprec@ietf.org" Date: Tue, 10 Jan 2012 16:45:54 +0200 Thread-Topic: Start & stop time for CS [was RE: IETF 82 Minutes.] Thread-Index: AQHMy821FXG9hLEz0USKI87oImfqFpYFtG3Q Message-ID: <07465C1D981ABC41A344374066AE1A2C3927E3CF03@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DC3F71@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC3F71@inba-mail01.sonusnet.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_07465C1D981ABC41A344374066AE1A2C3927E3CF03TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] 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, 10 Jan 2012 14:45:59 -0000 --_000_07465C1D981ABC41A344374066AE1A2C3927E3CF03TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First couple of comments: 1. We need it also on the media level - for example when video or tex= t sharing started/ended and not only complete CS 2. Same for participants - joining/leaving CS For the scenarios where RS covers on part of CS - like record on demand, ho= w SRS will know when CS have started? It is import from compliance recording point of view to indicate that RS do= es not cover complete CS. Hope it helps Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ravindran, Parthasarathi Sent: Thursday, January 05, 2012 7:16 PM To: siprec@ietf.org Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] Hi all, Associate/disassociate time helps to understand how long CS is associated w= ith RS. Initial association time shall be considered as start time and fin= al disassociation time shall be considered as stop time. As we could not co= nclude this open item during IETF-82, I'm starting this mail thread for dis= cussion. I could not see any other strong reason for having start/stop time for CS a= part from associate/disassociate time. Please provide usecase for including= start/stop time attribute in CS. In case we could not see the proper usecase, it is better to remove from me= tadata draft. Thanks Partha Note: "Relevant IETF-82 notes" There was a comment to include start/Stop time also. Is it needed ? Start time seems to makes since RS may have started only after CS was start= ed. Stop time seems to be problematic in case of missing association. Probl= em to define start/stop time since a CS may include multiple SIP dialogs. Leon: start is useful, but there is a problem with stop - how is stop sent? Ram: Are there any use cases? Paul: Can do it for a dialog, but not for a CS which can be many dialogs, s= o not clear how you would define when the start time was but can identify w= hen participants join and leave. Brian: What do we need this for? Is there a need to track the times a CS is part of CS-Group ? Leon: This is needed for snapshot Paul: Example could be supervisor who joins a call center call to listen or= whisper might need to now when this happens. - might need this. Chairs: Need more discussion on use cases and whether this needs to be spec= ified or whether it is an extension. From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of H= utton, Andrew Sent: Friday, December 09, 2011 5:28 PM To: siprec@ietf.org Subject: [siprec] IETF 82 Minutes. SIPREC IETF82 minutes can be found at http://www.ietf.org/proceedings/82/mi= nutes/siprec.txt. Any issues with these then please let me know and I will check against the = audio and correct if necessary. Lets kick start some discussion on the open issues since we have all had a = few weeks now to recover after Taipei. Regards Andy --_000_07465C1D981ABC41A344374066AE1A2C3927E3CF03TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First cou= ple of comments:

1.We need it also on the media level – for exa= mple when video or text sharing started/ended and not only complete CS=

2.   &= nbsp;   Same for participants – joining/leaving CS

<= p class=3DMsoNormal> 

For the scenarios where RS covers on part of CS – like record= on demand, how SRS will know when CS have started?

<= p class=3DMsoNormal> 

It is import from compliance recording point of view to indicate th= at RS does not cover complete CS.

 

Hope it hel= ps

 

Leon

 

= From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf O= f Ravindran, Parthasarathi
Sent: Thursday, January 05, 2012 7= :16 PM
To: siprec@ietf.org
Subject: [siprec] Start &= ; stop time for CS [was RE: IETF 82 Minutes.]

 

Hi all,

 

Associate/disassociate time help= s to understand how long CS is associated with RS. Initial association time= shall be considered  as start time and final disassociation time shal= l be considered as stop time. As we could not conclude this open item durin= g IETF-82, I’m starting this mail thread for discussion.

 

I could not see any other s= trong reason for having start/stop time for CS apart from associate/disasso= ciate time. Please provide usecase for including start/stop time attribute = in CS.

 

In case w= e could not see the proper usecase, it is better to remove from metadata dr= aft.

 

Thanks=

Partha

 

Note: “Relevant IETF-82 notes”

 

There was a comment to include star= t/Stop time also. Is it needed ?

= Start time seems= to makes since RS may have started only after CS was started. Stop time se= ems to be problematic in case of missing association. Problem to define sta= rt/stop time since a CS may include multiple SIP dialogs.=

 

Leon: start is useful, but there = is a problem with stop - how is stop sent?

Ram: A= re there any use cases?

Paul: Can do it for a dia= log, but not for a CS which can be many dialogs, so not clear how you would= define when the start time was but can identify when participants join and= leave.

Brian: What do we need this for?

 

Is there a need to track= the times a CS is part of CS-Group ?

Leon: This = is needed for snapshot

Paul: Example could be sup= ervisor who joins a call center call to listen or whisper might need to now= when this happens. - might need this.

Chairs: Ne= ed more discussion on use cases and whether this needs to be specified or w= hether it is an extension.

 

 

&nb= sp;

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: Friday, December 09, 2011 5:28 PM
To= : siprec@ietf.org
Subject:= [siprec] IETF 82 Minutes.

 

SIPREC IETF82 minutes can= be found at http://www.ietf.org/proceedings/82/minutes/siprec.txt.<= /o:p>

 

=

Any issues with these then please let me know and I will= check against the audio and correct if necessary.

 

= Lets kick start some discussion on the open issues since we have all had a = few weeks now to recover after Taipei.

 

Regards=

Andy

<= div>

 

= --_000_07465C1D981ABC41A344374066AE1A2C3927E3CF03TLVMBX01nicec_-- From trac+siprec@trac.tools.ietf.org Tue Jan 10 06:49:18 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6E621F85D4 for ; Tue, 10 Jan 2012 06:49:18 -0800 (PST) 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 6ArO07xgUxj4 for ; Tue, 10 Jan 2012 06:49:17 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 94A5F21F84D6 for ; Tue, 10 Jan 2012 06:49:17 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rkd0U-00086f-5Q; Tue, 10 Jan 2012 09:48:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-siprec-protocol@tools.ietf.org, leonp@nice.com X-Trac-Project: siprec Date: Tue, 10 Jan 2012 14:48:56 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/78#comment:1 Message-ID: <070.59ea5554701581ee46ae110e307bab89@trac.tools.ietf.org> References: <055.bd9bf14e48b183684fe7b426156f0089@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <055.bd9bf14e48b183684fe7b426156f0089@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-siprec-protocol@tools.ietf.org, leonp@nice.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120110144917.94A5F21F84D6@ietfa.amsl.com> Resent-Date: Tue, 10 Jan 2012 06:49:17 -0800 (PST) Resent-From: trac+siprec@trac.tools.ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] #78: Using of feature and options tags in SIPREC protocol 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: Tue, 10 Jan 2012 14:49:18 -0000 #78: Using of feature and options tags in SIPREC protocol Changes (by leonp@…): * status: new => closed * resolution: => fixed -- ----------------------+------------------------------------------- Reporter: leonp@… | Owner: draft-ietf-siprec-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: 2.0 Severity: - | Resolution: fixed Keywords: | ----------------------+------------------------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Tue Jan 10 06:49:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39AC21F847B for ; Tue, 10 Jan 2012 06:49:28 -0800 (PST) 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 rZUSns-47F8Q for ; Tue, 10 Jan 2012 06:49:28 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6B08321F847A for ; Tue, 10 Jan 2012 06:49:28 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rkd0w-0000Yt-6s; Tue, 10 Jan 2012 09:49:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-siprec-protocol@tools.ietf.org, leonp@nice.com X-Trac-Project: siprec Date: Tue, 10 Jan 2012 14:49:26 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/78#comment:2 Message-ID: <070.42bc36c38e6ea1b4d73d58f9ae320ff5@trac.tools.ietf.org> References: <055.bd9bf14e48b183684fe7b426156f0089@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <055.bd9bf14e48b183684fe7b426156f0089@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-siprec-protocol@tools.ietf.org, leonp@nice.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120110144928.6B08321F847A@ietfa.amsl.com> Resent-Date: Tue, 10 Jan 2012 06:49:28 -0800 (PST) Resent-From: trac+siprec@trac.tools.ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] #78: Using of feature and options tags in SIPREC protocol 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: Tue, 10 Jan 2012 14:49:28 -0000 #78: Using of feature and options tags in SIPREC protocol Comment (by leonp@…): Agreed during IETF82 -- ----------------------+------------------------------------------- Reporter: leonp@… | Owner: draft-ietf-siprec-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: 2.0 Severity: - | Resolution: fixed Keywords: | ----------------------+------------------------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Tue Jan 10 06:50:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1108321F850B for ; Tue, 10 Jan 2012 06:50:25 -0800 (PST) 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=[AWL=0.000, 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 6LnwQ506niGP for ; Tue, 10 Jan 2012 06:50:24 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 939E621F84B4 for ; Tue, 10 Jan 2012 06:50:24 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rkd1r-0002Ux-LZ; Tue, 10 Jan 2012 09:50:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: andrew.hutton@siemens-enterprise.com, leonp@nice.com X-Trac-Project: siprec Date: Tue, 10 Jan 2012 14:50:23 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/80#comment:1 Message-ID: <092.7b6d0d9dc36a442d345fbb85223083ab@trac.tools.ietf.org> References: <077.46a021a77843bb47f233c7c1c87f9c9c@trac.tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <077.46a021a77843bb47f233c7c1c87f9c9c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: andrew.hutton@siemens-enterprise.com, leonp@nice.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #80: How to identify CS in SRS Initiated recording. 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: Tue, 10 Jan 2012 14:50:25 -0000 #80: How to identify CS in SRS Initiated recording. Changes (by leonp@…): * status: new => closed * resolution: => fixed Comment: It was decided during IETF82 to cover it in the protocol draft -- --------------------------------+------------------------------ Reporter: andrew.hutton@… | Owner: andrew.hutton@… Type: enhancement | Status: closed Priority: major | Milestone: Component: Architecture | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------ Ticket URL: siprec From andrew.hutton@siemens-enterprise.com Tue Jan 10 07:09:10 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2021F879C for ; Tue, 10 Jan 2012 07:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_43=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 Op2Ra7MyO3P1 for ; Tue, 10 Jan 2012 07:09:09 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 15FA821F8798 for ; Tue, 10 Jan 2012 07:09:08 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 6CE951EB8493; Tue, 10 Jan 2012 16:09:07 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 10 Jan 2012 16:09:07 +0100 From: "Hutton, Andrew" To: Leon Portman , "Charles Eckel (eckelcu)" , "siprec@ietf.org" , Brian Rosen , Gonzalo Camarillo , Mary Barnes Date: Tue, 10 Jan 2012 16:09:13 +0100 Thread-Topic: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 Thread-Index: Acy2kF4m4Fu11k7CS7uNQ8B5GkBYBAFeu3pgAGyVRzAAA58OwAQ79K7QAAzwgYAALYQwcAAA0nBw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C3927E3CEF7@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C3927E3CEF7@TLVMBX01.nice.com> 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 Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 10 Jan 2012 15:09:10 -0000 Hi All, Ok if Mary can commit to providing the facilities for the meeting (i.e. loc= ation, Webex, etc.) and we the 6 people who stated they will attend commit = to going then I guess there is nothing to stop the meeting going ahead. All I would ask is for all those who said they would attend in person on th= e doodle poll and any others willing to do so please send me an e-mail with= you commitment to attend. We might also need some stand-in chairs for the meeting as so far I don't b= elieve Brian will attend and it I am cannot fully commit to being present a= t the moment, but I will try. If I get the commitments then I will call the meeting. Regards Andy > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 10 January 2012 14:41 > To: Charles Eckel (eckelcu); Hutton, Andrew; siprec@ietf.org; Brian > Rosen > Subject: RE: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > 17th 2012 >=20 > Good suggestion. +2 (me and developer) >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Monday, January 09, 2012 7:07 PM > To: Hutton, Andrew; siprec@ietf.org; Brian Rosen > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > 17th 2012 >=20 > Hi Andy, >=20 > I see 6 people, not counting either of the co-chairs, plus I know of a > few others who are considering attending but could not commit at this > point for various reasons. > It seems to me we are at a point where some white board sessions would > be helpful to run through various signaling and media flow scenarios. > These tend to be tedious and difficult to discuss via e-mail. IETF > sessions tend to be more presentation and discussion oriented, so I > think having a face to face working meeting outside of the normal IETF > time slot would be beneficial. Doing this Feb 17 in conjunction with > the CLUE interim meeting sounds ideal to me; however, if that timing > does not work, perhaps we can consider another time/location. > Just my 2 cents. >=20 > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Monday, January 09, 2012 2:58 AM > > To: siprec@ietf.org; Brian Rosen > > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area,Feb > > 17th 2012 > > > > Hi All, > > > > > > > > The poll is now closed we only had 6 people who stated they would > > attend of which at least a couple probably did so simply because they > > will be at the CLUE meeting anyway. > > > > > > > > I don't consider this enough interest to call a face to face meeting. > > > > > > > > So my proposal is that we should make a big effort to get more > > contributions on the list and get the editors to update the drafts to > > get us in good shape for a productive meeting in Paris. I am > assuming > > the working group will require the usual 2 hour meeting time during > > IETF83 and I will book this. > > > > > > > > I will do my best to keep discussion going on the list and drive some > > decisions. > > > > > > > > Regards > > > > Andy (SIPREC Co-Chair). > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: 18 December 2011 21:30 > > To: siprec@ietf.org > > Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > 17th > > 2012 > > > > > > > > Hi All, > > > > > > > > I created a doodle poll to register an indication of whether or not > you > > would attend a face to face SIPREC Interim meeting if it was held in > > the Boston (US) area on the 17th of February (i.e. day after the CLUE > > meeting). The venue for such a meeting would most likely be the same > > as for the CLUE meeting (i.e. Polycom office in Andover, MA) unless > we > > get a large number of people. > > > > > > > > Remote participation would be possible but this poll is for the > purpose > > of understanding who would actually attend in person. > > > > > > > > http://www.doodle.com/q3555taia7xbpmt2 > > > > > > > > This poll will close on the 6th of January after which the chairs > will > > make a decision as to whether the meeting should take place. > > > > > > > > Regards > > > > Andy > > > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Jan 10 07:33:17 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D01A21F860B for ; Tue, 10 Jan 2012 07:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_43=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 v8+2uzVjl7lK for ; Tue, 10 Jan 2012 07:33:16 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49C21F8613 for ; Tue, 10 Jan 2012 07:33:11 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id KrZ81i00B17dt5G54rZCaj; Tue, 10 Jan 2012 15:33:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id KrZB1i00h07duvL3ZrZB2C; Tue, 10 Jan 2012 15:33:11 +0000 Message-ID: <4F0C5A37.5020107@alum.mit.edu> Date: Tue, 10 Jan 2012 10:33:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C3927E3CEF7@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 10 Jan 2012 15:33:17 -0000 On 1/10/12 10:09 AM, Hutton, Andrew wrote: > Hi All, > > Ok if Mary can commit to providing the facilities for the meeting (i.e. location, Webex, etc.) and we the 6 people who stated they will attend commit to going then I guess there is nothing to stop the meeting going ahead. > > All I would ask is for all those who said they would attend in person on the doodle poll and any others willing to do so please send me an e-mail with you commitment to attend. Here is mine. Thanks, Paul > We might also need some stand-in chairs for the meeting as so far I don't believe Brian will attend and it I am cannot fully commit to being present at the moment, but I will try. > > If I get the commitments then I will call the meeting. > > Regards > Andy > > > >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> Sent: 10 January 2012 14:41 >> To: Charles Eckel (eckelcu); Hutton, Andrew; siprec@ietf.org; Brian >> Rosen >> Subject: RE: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb >> 17th 2012 >> >> Good suggestion. +2 (me and developer) >> >> Leon >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Charles Eckel (eckelcu) >> Sent: Monday, January 09, 2012 7:07 PM >> To: Hutton, Andrew; siprec@ietf.org; Brian Rosen >> Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb >> 17th 2012 >> >> Hi Andy, >> >> I see 6 people, not counting either of the co-chairs, plus I know of a >> few others who are considering attending but could not commit at this >> point for various reasons. >> It seems to me we are at a point where some white board sessions would >> be helpful to run through various signaling and media flow scenarios. >> These tend to be tedious and difficult to discuss via e-mail. IETF >> sessions tend to be more presentation and discussion oriented, so I >> think having a face to face working meeting outside of the normal IETF >> time slot would be beneficial. Doing this Feb 17 in conjunction with >> the CLUE interim meeting sounds ideal to me; however, if that timing >> does not work, perhaps we can consider another time/location. >> Just my 2 cents. >> >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: Monday, January 09, 2012 2:58 AM >>> To: siprec@ietf.org; Brian Rosen >>> Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area,Feb >>> 17th 2012 >>> >>> Hi All, >>> >>> >>> >>> The poll is now closed we only had 6 people who stated they would >>> attend of which at least a couple probably did so simply because they >>> will be at the CLUE meeting anyway. >>> >>> >>> >>> I don't consider this enough interest to call a face to face meeting. >>> >>> >>> >>> So my proposal is that we should make a big effort to get more >>> contributions on the list and get the editors to update the drafts to >>> get us in good shape for a productive meeting in Paris. I am >> assuming >>> the working group will require the usual 2 hour meeting time during >>> IETF83 and I will book this. >>> >>> >>> >>> I will do my best to keep discussion going on the list and drive some >>> decisions. >>> >>> >>> >>> Regards >>> >>> Andy (SIPREC Co-Chair). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: 18 December 2011 21:30 >>> To: siprec@ietf.org >>> Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb >> 17th >>> 2012 >>> >>> >>> >>> Hi All, >>> >>> >>> >>> I created a doodle poll to register an indication of whether or not >> you >>> would attend a face to face SIPREC Interim meeting if it was held in >>> the Boston (US) area on the 17th of February (i.e. day after the CLUE >>> meeting). The venue for such a meeting would most likely be the same >>> as for the CLUE meeting (i.e. Polycom office in Andover, MA) unless >> we >>> get a large number of people. >>> >>> >>> >>> Remote participation would be possible but this poll is for the >> purpose >>> of understanding who would actually attend in person. >>> >>> >>> >>> http://www.doodle.com/q3555taia7xbpmt2 >>> >>> >>> >>> This poll will close on the 6th of January after which the chairs >> will >>> make a decision as to whether the meeting should take place. >>> >>> >>> >>> Regards >>> >>> Andy >>> >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From Leon.Portman@nice.com Tue Jan 10 07:46:03 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33FF21F8747 for ; Tue, 10 Jan 2012 07:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_43=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 ny91pmV8vnt6 for ; Tue, 10 Jan 2012 07:46:02 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3888F21F8757 for ; Tue, 10 Jan 2012 07:46:02 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 10 Jan 2012 17:46:00 +0200 From: Leon Portman To: "siprec@ietf.org" Date: Tue, 10 Jan 2012 17:45:59 +0200 Thread-Topic: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 Thread-Index: AczPrTRhCZQrJdSfR9CwLFQkWlCSaAAAabEw Message-ID: <07465C1D981ABC41A344374066AE1A2C3927E3CF5B@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C3927E3CEF7@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> <4F0C5A37.5020107@alum.mit.edu> In-Reply-To: <4F0C5A37.5020107@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 Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 10 Jan 2012 15:46:03 -0000 Committed , myself+1 and pending additional 1 Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Tuesday, January 10, 2012 5:33 PM To: siprec@ietf.org Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th = 2012 On 1/10/12 10:09 AM, Hutton, Andrew wrote: > Hi All, > > Ok if Mary can commit to providing the facilities for the meeting (i.e. l= ocation, Webex, etc.) and we the 6 people who stated they will attend commi= t to going then I guess there is nothing to stop the meeting going ahead. > > All I would ask is for all those who said they would attend in person on = the doodle poll and any others willing to do so please send me an e-mail wi= th you commitment to attend. Here is mine. Thanks, Paul > We might also need some stand-in chairs for the meeting as so far I don't= believe Brian will attend and it I am cannot fully commit to being present= at the moment, but I will try. > > If I get the commitments then I will call the meeting. > > Regards > Andy > > > >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> Sent: 10 January 2012 14:41 >> To: Charles Eckel (eckelcu); Hutton, Andrew; siprec@ietf.org; Brian=20 >> Rosen >> Subject: RE: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb=20 >> 17th 2012 >> >> Good suggestion. +2 (me and developer) >> >> Leon >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Charles Eckel (eckelcu) >> Sent: Monday, January 09, 2012 7:07 PM >> To: Hutton, Andrew; siprec@ietf.org; Brian Rosen >> Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb=20 >> 17th 2012 >> >> Hi Andy, >> >> I see 6 people, not counting either of the co-chairs, plus I know of=20 >> a few others who are considering attending but could not commit at=20 >> this point for various reasons. >> It seems to me we are at a point where some white board sessions=20 >> would be helpful to run through various signaling and media flow scenari= os. >> These tend to be tedious and difficult to discuss via e-mail. IETF=20 >> sessions tend to be more presentation and discussion oriented, so I=20 >> think having a face to face working meeting outside of the normal=20 >> IETF time slot would be beneficial. Doing this Feb 17 in conjunction=20 >> with the CLUE interim meeting sounds ideal to me; however, if that=20 >> timing does not work, perhaps we can consider another time/location. >> Just my 2 cents. >> >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Hutton, Andrew >>> Sent: Monday, January 09, 2012 2:58 AM >>> To: siprec@ietf.org; Brian Rosen >>> Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area,Feb=20 >>> 17th 2012 >>> >>> Hi All, >>> >>> >>> >>> The poll is now closed we only had 6 people who stated they would=20 >>> attend of which at least a couple probably did so simply because=20 >>> they will be at the CLUE meeting anyway. >>> >>> >>> >>> I don't consider this enough interest to call a face to face meeting. >>> >>> >>> >>> So my proposal is that we should make a big effort to get more=20 >>> contributions on the list and get the editors to update the drafts=20 >>> to get us in good shape for a productive meeting in Paris. I am >> assuming >>> the working group will require the usual 2 hour meeting time during >>> IETF83 and I will book this. >>> >>> >>> >>> I will do my best to keep discussion going on the list and drive=20 >>> some decisions. >>> >>> >>> >>> Regards >>> >>> Andy (SIPREC Co-Chair). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Hutton, Andrew >>> Sent: 18 December 2011 21:30 >>> To: siprec@ietf.org >>> Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb >> 17th >>> 2012 >>> >>> >>> >>> Hi All, >>> >>> >>> >>> I created a doodle poll to register an indication of whether or not >> you >>> would attend a face to face SIPREC Interim meeting if it was held in=20 >>> the Boston (US) area on the 17th of February (i.e. day after the=20 >>> CLUE meeting). The venue for such a meeting would most likely be=20 >>> the same as for the CLUE meeting (i.e. Polycom office in Andover,=20 >>> MA) unless >> we >>> get a large number of people. >>> >>> >>> >>> Remote participation would be possible but this poll is for the >> purpose >>> of understanding who would actually attend in person. >>> >>> >>> >>> http://www.doodle.com/q3555taia7xbpmt2 >>> >>> >>> >>> This poll will close on the 6th of January after which the chairs >> will >>> make a decision as to whether the meeting should take place. >>> >>> >>> >>> Regards >>> >>> Andy >>> >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From mary.ietf.barnes@gmail.com Tue Jan 10 08:11:19 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D221F84F0 for ; Tue, 10 Jan 2012 08:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4TOR841yXNT for ; Tue, 10 Jan 2012 08:11:18 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2D321F84D0 for ; Tue, 10 Jan 2012 08:11:18 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so4034861vcb.31 for ; Tue, 10 Jan 2012 08:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kBZiiu5u+ISWhIkQOxeMksDfLRacpfbFd2WgDoRCJdE=; b=lhBVwWhL7v+Jab0TAYdadqojtwSHwn5RD/tMFZCJlhHEsv49+X8T9NEIZ+RJWLnDmr gHMaZMGTVcwHwJ8vbx7CcXfgg3uF1FHEiRk85iKMj7HnbHwCZKARqxUXLbkpwEMnisNz giGgR+J9t8mczzBl1o3o60ydueA14Z4CbUKfI= MIME-Version: 1.0 Received: by 10.220.231.198 with SMTP id jr6mr8936243vcb.18.1326211876703; Tue, 10 Jan 2012 08:11:16 -0800 (PST) Received: by 10.52.108.196 with HTTP; Tue, 10 Jan 2012 08:11:16 -0800 (PST) In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C3927E3CEF7@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> Date: Tue, 10 Jan 2012 10:11:16 -0600 Message-ID: From: Mary Barnes To: "Hutton, Andrew" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "siprec@ietf.org" Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 10 Jan 2012 16:11:19 -0000 Yes - Polycom can still host on the 17th. We were able to reserve the same meeting space we are using for CLUE for the 17th, as well. Folks can find travel information on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki Mary. On Tue, Jan 10, 2012 at 9:09 AM, Hutton, Andrew wrote: > Hi All, > > Ok if Mary can commit to providing the facilities for the meeting (i.e. l= ocation, Webex, etc.) and we the 6 people who stated they will attend commi= t to going then I guess there is nothing to stop the meeting going ahead. > > All I would ask is for all those who said they would attend in person on = the doodle poll and any others willing to do so please send me an e-mail wi= th you commitment to attend. > > We might also need some stand-in chairs for the meeting as so far I don't= believe Brian will attend and it I am cannot fully commit to being present= at the moment, but I will try. > > If I get the commitments then I will call the meeting. > > Regards > Andy > > > >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> Sent: 10 January 2012 14:41 >> To: Charles Eckel (eckelcu); Hutton, Andrew; siprec@ietf.org; Brian >> Rosen >> Subject: RE: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb >> 17th 2012 >> >> Good suggestion. +2 (me and developer) >> >> Leon >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Charles Eckel (eckelcu) >> Sent: Monday, January 09, 2012 7:07 PM >> To: Hutton, Andrew; siprec@ietf.org; Brian Rosen >> Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb >> 17th 2012 >> >> Hi Andy, >> >> I see 6 people, not counting either of the co-chairs, plus I know of a >> few others who are considering attending but could not commit at this >> point for various reasons. >> It seems to me we are at a point where some white board sessions would >> be helpful to run through various signaling and media flow scenarios. >> These tend to be tedious and difficult to discuss via e-mail. IETF >> sessions tend to be more presentation and discussion oriented, so I >> think having a face to face working meeting outside of the normal IETF >> time slot would be beneficial. Doing this Feb 17 in conjunction with >> the CLUE interim meeting sounds ideal to me; however, if that timing >> does not work, perhaps we can consider another time/location. >> Just my 2 cents. >> >> Charles >> >> > -----Original Message----- >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > Behalf Of Hutton, Andrew >> > Sent: Monday, January 09, 2012 2:58 AM >> > To: siprec@ietf.org; Brian Rosen >> > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area,Feb >> > 17th 2012 >> > >> > Hi All, >> > >> > >> > >> > The poll is now closed we only had 6 people who stated they would >> > attend of which at least a couple probably did so simply because they >> > will be at the CLUE meeting anyway. >> > >> > >> > >> > I don't consider this enough interest to call a face to face meeting. >> > >> > >> > >> > So my proposal is that we should make a big effort to get more >> > contributions on the list and get the editors to update the drafts to >> > get us in good shape for a productive meeting in Paris. =A0I am >> assuming >> > the working group will require the usual 2 hour meeting time during >> > IETF83 and I will book this. >> > >> > >> > >> > I will do my best to keep discussion going on the list and drive some >> > decisions. >> > >> > >> > >> > Regards >> > >> > Andy (SIPREC Co-Chair). >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > Behalf Of Hutton, Andrew >> > Sent: 18 December 2011 21:30 >> > To: siprec@ietf.org >> > Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb >> 17th >> > 2012 >> > >> > >> > >> > Hi All, >> > >> > >> > >> > I created a doodle poll to register an indication of whether or not >> you >> > would attend a face to face SIPREC Interim meeting if it was held in >> > the Boston (US) area on the 17th of February (i.e. day after the CLUE >> > meeting). =A0The venue for such a meeting would most likely be the sam= e >> > as for the CLUE meeting (i.e. Polycom office in Andover, MA) unless >> we >> > get a large number of people. >> > >> > >> > >> > Remote participation would be possible but this poll is for the >> purpose >> > of understanding who would actually attend in person. >> > >> > >> > >> > http://www.doodle.com/q3555taia7xbpmt2 >> > >> > >> > >> > This poll will close on the 6th of January after which the chairs >> will >> > make a decision as to whether the meeting should take place. >> > >> > >> > >> > Regards >> > >> > Andy >> > >> > >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Tue Jan 10 08:28:32 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42521F8750 for ; Tue, 10 Jan 2012 08:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQmkyKS7WyRt for ; Tue, 10 Jan 2012 08:28:31 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BD11321F8705 for ; Tue, 10 Jan 2012 08:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5382; q=dns/txt; s=iport; t=1326212912; x=1327422512; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=9bwFplCmZbWY8oTiO6RNvPWSDjEbrn/hCuHEmxDAGjo=; b=GVEcpaVe/6/YRVHNhe0aJxPW6QS0GsbJmZ1kW4vdDl3hxlMUQdDIxW+U 3T2x6JIp1QiqlYJdAASdJprzAxjT9YyxWVtAZYrlhwMorOCF7SvaYMnSe thzhUUx9LfsGyQrs3+eTDCfF+Dmbl3S2ZOtawpuzTILE4csMe+L3Le1AB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADZmDE+rRDoI/2dsb2JhbABDrFmBBYFyAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAIEARIIGodgmFUBniyLMGMEiDqfLQ X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; d="scan'208";a="24691090" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 10 Jan 2012 16:28:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0AGSVSs019483; Tue, 10 Jan 2012 16:28:31 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 08:28:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2012 08:28:30 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 Thread-Index: Acy2kF4m4Fu11k7CS7uNQ8B5GkBYBAFeu3pgAGyVRzAAA58OwAQ79K7QAAzwgYAALYQwcAAA0nBwAALtCUA= References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C3927E3CEF7@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "Leon Portman" , , "Brian Rosen" , "Gonzalo Camarillo" , "Mary Barnes" X-OriginalArrivalTime: 10 Jan 2012 16:28:31.0268 (UTC) FILETIME=[E3F88640:01CCCFB4] Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 10 Jan 2012 16:28:32 -0000 Great, count me as confirmed. Thanks, Charles > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Tuesday, January 10, 2012 7:09 AM > To: Leon Portman; Charles Eckel (eckelcu); siprec@ietf.org; Brian > Rosen; Gonzalo Camarillo; Mary Barnes > Subject: RE: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > 17th 2012 >=20 > Hi All, >=20 > Ok if Mary can commit to providing the facilities for the meeting (i.e. > location, Webex, etc.) and we the 6 people who stated they will attend > commit to going then I guess there is nothing to stop the meeting going > ahead. >=20 > All I would ask is for all those who said they would attend in person > on the doodle poll and any others willing to do so please send me an e- > mail with you commitment to attend. >=20 > We might also need some stand-in chairs for the meeting as so far I > don't believe Brian will attend and it I am cannot fully commit to > being present at the moment, but I will try. >=20 > If I get the commitments then I will call the meeting. >=20 > Regards > Andy >=20 >=20 >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 10 January 2012 14:41 > > To: Charles Eckel (eckelcu); Hutton, Andrew; siprec@ietf.org; Brian > > Rosen > > Subject: RE: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > > 17th 2012 > > > > Good suggestion. +2 (me and developer) > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Monday, January 09, 2012 7:07 PM > > To: Hutton, Andrew; siprec@ietf.org; Brian Rosen > > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > > 17th 2012 > > > > Hi Andy, > > > > I see 6 people, not counting either of the co-chairs, plus I know of > a > > few others who are considering attending but could not commit at this > > point for various reasons. > > It seems to me we are at a point where some white board sessions > would > > be helpful to run through various signaling and media flow scenarios. > > These tend to be tedious and difficult to discuss via e-mail. IETF > > sessions tend to be more presentation and discussion oriented, so I > > think having a face to face working meeting outside of the normal > IETF > > time slot would be beneficial. Doing this Feb 17 in conjunction with > > the CLUE interim meeting sounds ideal to me; however, if that timing > > does not work, perhaps we can consider another time/location. > > Just my 2 cents. > > > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: Monday, January 09, 2012 2:58 AM > > > To: siprec@ietf.org; Brian Rosen > > > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston > Area,Feb > > > 17th 2012 > > > > > > Hi All, > > > > > > > > > > > > The poll is now closed we only had 6 people who stated they would > > > attend of which at least a couple probably did so simply because > they > > > will be at the CLUE meeting anyway. > > > > > > > > > > > > I don't consider this enough interest to call a face to face > meeting. > > > > > > > > > > > > So my proposal is that we should make a big effort to get more > > > contributions on the list and get the editors to update the drafts > to > > > get us in good shape for a productive meeting in Paris. I am > > assuming > > > the working group will require the usual 2 hour meeting time during > > > IETF83 and I will book this. > > > > > > > > > > > > I will do my best to keep discussion going on the list and drive > some > > > decisions. > > > > > > > > > > > > Regards > > > > > > Andy (SIPREC Co-Chair). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: 18 December 2011 21:30 > > > To: siprec@ietf.org > > > Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > > 17th > > > 2012 > > > > > > > > > > > > Hi All, > > > > > > > > > > > > I created a doodle poll to register an indication of whether or not > > you > > > would attend a face to face SIPREC Interim meeting if it was held > in > > > the Boston (US) area on the 17th of February (i.e. day after the > CLUE > > > meeting). The venue for such a meeting would most likely be the > same > > > as for the CLUE meeting (i.e. Polycom office in Andover, MA) unless > > we > > > get a large number of people. > > > > > > > > > > > > Remote participation would be possible but this poll is for the > > purpose > > > of understanding who would actually attend in person. > > > > > > > > > > > > http://www.doodle.com/q3555taia7xbpmt2 > > > > > > > > > > > > This poll will close on the 6th of January after which the chairs > > will > > > make a decision as to whether the meeting should take place. > > > > > > > > > > > > Regards > > > > > > Andy > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@alcatel-lucent.com Tue Jan 10 19:48:29 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EDF21F8545 for ; Tue, 10 Jan 2012 19:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7zAGkswwkgW for ; Tue, 10 Jan 2012 19:48:28 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9885021F8510 for ; Tue, 10 Jan 2012 19:48:28 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0B3mR4t007053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 10 Jan 2012 21:48:27 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0B3mQZf021905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 Jan 2012 21:48:27 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q0B3mMrk028338 for ; Tue, 10 Jan 2012 19:48:24 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 19:48:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2012 19:48:18 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74080222D4@NAHALD.us.int.genesyslab.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 Thread-Index: Acy2kF4m4Fu11k7CS7uNQ8B5GkBYBAFeu3pgAGyVRzAAA58OwAQ79K7QAAzwgYAALYQwcAAA0nBwABqU1ZA= References: <101C6067BEC68246B0C3F6843BCCC1E311FAE710C2@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD73943D@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739527@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E311FD739529@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E312001ECA44@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C3927E3CEF7@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E312001ED312@MCHP058A.global-ad.net> From: "Henry Lum" To: X-OriginalArrivalTime: 11 Jan 2012 03:48:23.0212 (UTC) FILETIME=[DDDD36C0:01CCD013] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb 17th 2012 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, 11 Jan 2012 03:48:29 -0000 I can attend remotely. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: January-10-12 10:09 AM > To: Leon Portman; Charles Eckel (eckelcu); siprec@ietf.org; Brian > Rosen; Gonzalo Camarillo; Mary Barnes > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > 17th 2012 >=20 > Hi All, >=20 > Ok if Mary can commit to providing the facilities for the meeting (i.e. > location, Webex, etc.) and we the 6 people who stated they will attend > commit to going then I guess there is nothing to stop the meeting going > ahead. >=20 > All I would ask is for all those who said they would attend in person > on the doodle poll and any others willing to do so please send me an e- > mail with you commitment to attend. >=20 > We might also need some stand-in chairs for the meeting as so far I > don't believe Brian will attend and it I am cannot fully commit to > being present at the moment, but I will try. >=20 > If I get the commitments then I will call the meeting. >=20 > Regards > Andy >=20 >=20 >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 10 January 2012 14:41 > > To: Charles Eckel (eckelcu); Hutton, Andrew; siprec@ietf.org; Brian > > Rosen > > Subject: RE: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > > 17th 2012 > > > > Good suggestion. +2 (me and developer) > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Monday, January 09, 2012 7:07 PM > > To: Hutton, Andrew; siprec@ietf.org; Brian Rosen > > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > > 17th 2012 > > > > Hi Andy, > > > > I see 6 people, not counting either of the co-chairs, plus I know of > a > > few others who are considering attending but could not commit at this > > point for various reasons. > > It seems to me we are at a point where some white board sessions > would > > be helpful to run through various signaling and media flow scenarios. > > These tend to be tedious and difficult to discuss via e-mail. IETF > > sessions tend to be more presentation and discussion oriented, so I > > think having a face to face working meeting outside of the normal > IETF > > time slot would be beneficial. Doing this Feb 17 in conjunction with > > the CLUE interim meeting sounds ideal to me; however, if that timing > > does not work, perhaps we can consider another time/location. > > Just my 2 cents. > > > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: Monday, January 09, 2012 2:58 AM > > > To: siprec@ietf.org; Brian Rosen > > > Subject: Re: [siprec] Doodle Poll - SIPREC Interim - Boston > Area,Feb > > > 17th 2012 > > > > > > Hi All, > > > > > > > > > > > > The poll is now closed we only had 6 people who stated they would > > > attend of which at least a couple probably did so simply because > they > > > will be at the CLUE meeting anyway. > > > > > > > > > > > > I don't consider this enough interest to call a face to face > meeting. > > > > > > > > > > > > So my proposal is that we should make a big effort to get more > > > contributions on the list and get the editors to update the drafts > to > > > get us in good shape for a productive meeting in Paris. I am > > assuming > > > the working group will require the usual 2 hour meeting time during > > > IETF83 and I will book this. > > > > > > > > > > > > I will do my best to keep discussion going on the list and drive > some > > > decisions. > > > > > > > > > > > > Regards > > > > > > Andy (SIPREC Co-Chair). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: 18 December 2011 21:30 > > > To: siprec@ietf.org > > > Subject: [siprec] Doodle Poll - SIPREC Interim - Boston Area, Feb > > 17th > > > 2012 > > > > > > > > > > > > Hi All, > > > > > > > > > > > > I created a doodle poll to register an indication of whether or not > > you > > > would attend a face to face SIPREC Interim meeting if it was held > in > > > the Boston (US) area on the 17th of February (i.e. day after the > CLUE > > > meeting). The venue for such a meeting would most likely be the > same > > > as for the CLUE meeting (i.e. Polycom office in Andover, MA) unless > > we > > > get a large number of people. > > > > > > > > > > > > Remote participation would be possible but this poll is for the > > purpose > > > of understanding who would actually attend in person. > > > > > > > > > > > > http://www.doodle.com/q3555taia7xbpmt2 > > > > > > > > > > > > This poll will close on the 6th of January after which the chairs > > will > > > make a decision as to whether the meeting should take place. > > > > > > > > > > > > Regards > > > > > > Andy > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From pravindran@sonusnet.com Wed Jan 11 09:09:31 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E4721F886F for ; Wed, 11 Jan 2012 09:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 kWcWishROYaq for ; Wed, 11 Jan 2012 09:09:29 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E0A1721F86E0 for ; Wed, 11 Jan 2012 09:09:28 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0BHAAGn003783; Wed, 11 Jan 2012 12:10:10 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 12:08:30 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 22:39:23 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Wed, 11 Jan 2012 22:39:22 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman , "siprec@ietf.org" Thread-Topic: Start & stop time for CS [was RE: IETF 82 Minutes.] Thread-Index: AQHMy821FXG9hLEz0USKI87oImfqFpYFtG3QgAG4vPA= Date: Wed, 11 Jan 2012 17:09:20 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD050A@inba-mail02.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DC3F71@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C3927E3CF03@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C3927E3CF03@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DD050Ainbamail02sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 17:09:23.0347 (UTC) FILETIME=[C3EFD630:01CCD083] Subject: Re: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] 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, 11 Jan 2012 17:09:32 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD050Ainbamail02sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Leon, In case media level, it is possible to find the start/stop time using parti= cipantstream association or SDP attribute change for a specific stream. In = case of participant to CS, association & disassociation attribute helps to= identify how long participant is associated with CS during the recording. Please read inline for more comments. Thanks Partha From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Tuesday, January 10, 2012 8:16 PM To: Ravindran, Parthasarathi; siprec@ietf.org Subject: RE: Start & stop time for CS [was RE: IETF 82 Minutes.] First couple of comments: 1. We need it also on the media level - for example when video or tex= t sharing started/ended and not only complete CS 2. Same for participants - joining/leaving CS For the scenarios where RS covers on part of CS - like record on demand, ho= w SRS will know when CS have started? SRC has to maintain the dialog history information like Call Detai= l records (CDR) then only, this requirement will be solved. This requiremen= t is not required to be mandated in all SRC It is import from compliance recording point of view to indicate that RS do= es not cover complete CS. Could you please provide the name of compliance which mandate CS s= tart/stop time Hope it helps Leon From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi Sent: Thursday, January 05, 2012 7:16 PM To: siprec@ietf.org Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] Hi all, Associate/disassociate time helps to understand how long CS is associated w= ith RS. Initial association time shall be considered as start time and fin= al disassociation time shall be considered as stop time. As we could not co= nclude this open item during IETF-82, I'm starting this mail thread for dis= cussion. I could not see any other strong reason for having start/stop time for CS a= part from associate/disassociate time. Please provide usecase for including= start/stop time attribute in CS. In case we could not see the proper usecase, it is better to remove from me= tadata draft. Thanks Partha Note: "Relevant IETF-82 notes" There was a comment to include start/Stop time also. Is it needed ? Start time seems to makes since RS may have started only after CS was start= ed. Stop time seems to be problematic in case of missing association. Probl= em to define start/stop time since a CS may include multiple SIP dialogs. Leon: start is useful, but there is a problem with stop - how is stop sent? Ram: Are there any use cases? Paul: Can do it for a dialog, but not for a CS which can be many dialogs, s= o not clear how you would define when the start time was but can identify w= hen participants join and leave. Brian: What do we need this for? Is there a need to track the times a CS is part of CS-Group ? Leon: This is needed for snapshot Paul: Example could be supervisor who joins a call center call to listen or= whisper might need to now when this happens. - might need this. Chairs: Need more discussion on use cases and whether this needs to be spec= ified or whether it is an extension. From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of H= utton, Andrew Sent: Friday, December 09, 2011 5:28 PM To: siprec@ietf.org Subject: [siprec] IETF 82 Minutes. SIPREC IETF82 minutes can be found at http://www.ietf.org/proceedings/82/mi= nutes/siprec.txt. Any issues with these then please let me know and I will check against the = audio and correct if necessary. Lets kick start some discussion on the open issues since we have all had a = few weeks now to recover after Taipei. Regards Andy --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD050Ainbamail02sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Leon,

 <= /p>

In case media level, it i= s possible to find the start/stop time using participantstream association = or SDP attribute change for a specific stream. In case of participant to CS, association & disassociation  attribute helps = to identify how long participant is associated with CS during the recording= .

 <= /p>

Please read inline for mo= re comments.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: Leon Por= tman [mailto:Leon.Portman@nice.com]
Sent: Tuesday, January 10, 2012 8:16 PM
To: Ravindran, Parthasarathi; siprec@ietf.org
Subject: RE: Start & stop time for CS [was RE: IETF 82 Minutes.]=

 

First couple of comments:=

1. = ;      We need it also o= n the media level – for example when video or text sharing started/en= ded and not only complete CS

2. = ;      Same for particip= ants – joining/leaving CS

 <= /p>

For the scenarios where R= S covers on part of CS – like record on demand, how SRS will know whe= n CS have started?

<partha> SRC has to= maintain the dialog history information like Call Detail records (CDR) the= n only, this requirement will be solved. This requirement is not required to be mandated in all SRC </partha>

 <= /p>

It is import from complia= nce recording point of view to indicate that RS does not cover complete CS.=

<partha> Could you = please provide the name of compliance which mandate CS start/stop time <= /partha>

 <= /p>

Hope it helps<= /span>

 <= /p>

Leon

 <= /p>

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi
Sent: Thursday, January 05, 2012 7:16 PM
To: siprec@ietf.org
Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minu= tes.]

 

Hi all,

 

Associate/disassociate time helps to understand how long C= S is associated with RS. Initial association time shall be considered = as start time and final disassociation time shall be considered as stop time. As we could not conclude this open item during= IETF-82, I’m starting this mail thread for discussion.

 

I could not see any other strong reason for having start/s= top time for CS apart from associate/disassociate time. Please provide usec= ase for including start/stop time attribute in CS.

 

In case we could not see the proper usecase, it is better = to remove from metadata draft.

 

Thanks

Partha

 

Note: “Relevant IETF-82 notes”

 

There was a comment to include start/Stop time also. Is it= needed ?

Start time seems to makes since RS may have started only a= fter CS was started. Stop time seems to be problematic in case of missing a= ssociation. Problem to define start/stop time since a CS may include multiple SIP dialogs.

 

Leon: start is useful, but there is a problem with stop - = how is stop sent?

Ram: Are there any use cases?

Paul: Can do it for a dialog, but not for a CS which can b= e many dialogs, so not clear how you would define when the start time was b= ut can identify when participants join and leave.

Brian: What do we need this for?

 

Is there a need to track the times a CS is part of CS-Grou= p ?

Leon: This is needed for snapshot

Paul: Example could be supervisor who joins a call center = call to listen or whisper might need to now when this happens. - might need= this.

Chairs: Need more discussion on use cases and whether this= needs to be specified or whether it is an extension.

 

 

 <= /p>

 <= /p>

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: Friday, December 09, 2011 5:28 PM
To: siprec@ietf.org
Subject: [siprec] IETF 82 Minutes.

 

SIPREC IETF82 minutes can be found at http://ww= w.ietf.org/proceedings/82/minutes/siprec.txt.<= /p>

 

Any issues with these then please let m= e know and I will check against the audio and correct if necessary.

 

Lets kick start some discussion on the = open issues since we have all had a few weeks now to recover after Taipei.<= o:p>

 

Regards

Andy

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C01DD050Ainbamail02sonus_-- From leon.portman@gmail.com Thu Jan 12 01:47:51 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E3A21F85AF for ; Thu, 12 Jan 2012 01:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZTz67B+T1kiL for ; Thu, 12 Jan 2012 01:47:50 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B960721F85A7 for ; Thu, 12 Jan 2012 01:47:49 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1412477vcb.31 for ; Thu, 12 Jan 2012 01:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J376U0mix4k34qj5q4dF7xzy0SR2tEEbxK9UDm082s8=; b=MKbvaOMbN/3yuofsSuV3BAcA/dY40i/j0XUL8Hi6+24KuZVshuhkblEeS90UsGlxku /jgW0k9ZTChcIYBLL1nKLlW9MRaZOugxWQAMuuRpFoNFGWyGMG2rAAiY23Am1Zzn0pGm 11lJcybNlmLY+0pEy3kX+7Wi94AEDuK2r5Lyk= MIME-Version: 1.0 Received: by 10.220.155.212 with SMTP id t20mr1687189vcw.8.1326361669102; Thu, 12 Jan 2012 01:47:49 -0800 (PST) Received: by 10.220.178.193 with HTTP; Thu, 12 Jan 2012 01:47:48 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DD050A@inba-mail02.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E311FAE70EB6@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DC3F71@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C3927E3CF03@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C01DD050A@inba-mail02.sonusnet.com> Date: Thu, 12 Jan 2012 11:47:48 +0200 Message-ID: From: Leon Portman To: "Ravindran, Parthasarathi" , siprec@ietf.org Content-Type: multipart/alternative; boundary=f46d0438949f216b0004b651a46d Subject: Re: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] 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, 12 Jan 2012 09:47:51 -0000 --f46d0438949f216b0004b651a46d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Partha, Hi So based on below, participant and media association times are related to CS and not RS? In such case SRS can know when somebody joined conversation and not only when somebody got started to be recorded. Back to the question for specific regulations.They do not state explicitly to have distinction between recording and communication times - they are very high level and talking about keeping records of all communication and electronic interactions. But customer requirements that we have is to be able to search and view actual communications times and not only recording times. And current SRS implementations distinguish between these two. Regards Leon On Wed, Jan 11, 2012 at 7:09 PM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Leon,**** > > ** ** > > In case media level, it is possible to find the start/stop time using > participantstream association or SDP attribute change for a specific > stream. In case of participant to CS, association & disassociation > attribute helps to identify how long participant is associated with CS > during the recording. **** > > ** ** > > Please read inline for more comments.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Leon Portman [mailto:Leon.Portman@nice.com] > *Sent:* Tuesday, January 10, 2012 8:16 PM > *To:* Ravindran, Parthasarathi; siprec@ietf.org > *Subject:* RE: Start & stop time for CS [was RE: IETF 82 Minutes.]**** > > ** ** > > First couple of comments:**** > > **1. **We need it also on the media level =96 for example when vide= o > or text sharing started/ended and not only complete CS**** > > **2. **Same for participants =96 joining/leaving CS**** > > ** ** > > For the scenarios where RS covers on part of CS =96 like record on demand= , > how SRS will know when CS have started? **** > > SRC has to maintain the dialog history information like Call > Detail records (CDR) then only, this requirement will be solved. This > requirement is not required to be mandated in all SRC **** > > ** ** > > It is import from compliance recording point of view to indicate that RS > does not cover complete CS.**** > > Could you please provide the name of compliance which mandate CS > start/stop time **** > > ** ** > > Hope it helps**** > > ** ** > > Leon**** > > ** ** > > *From:* siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > *On Behalf Of *Ravindran, Parthasarathi > *Sent:* Thursday, January 05, 2012 7:16 PM > *To:* siprec@ietf.org > *Subject:* [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.]**= * > * > > ** ** > > Hi all,**** > > ** ** > > Associate/disassociate time helps to understand how long CS is associated > with RS. Initial association time shall be considered as start time and > final disassociation time shall be considered as stop time. As we could n= ot > conclude this open item during IETF-82, I=92m starting this mail thread f= or > discussion.**** > > ** ** > > I could not see any other strong reason for having start/stop time for CS > apart from associate/disassociate time. Please provide usecase for > including start/stop time attribute in CS.**** > > ** ** > > In case we could not see the proper usecase, it is better to remove from > metadata draft.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > Note: =93Relevant IETF-82 notes=94**** > > ** ** > > There was a comment to include start/Stop time also. Is it needed ?**** > > Start time seems to makes since RS may have started only after CS was > started. Stop time seems to be problematic in case of missing association= . > Problem to define start/stop time since a CS may include multiple SIP > dialogs.**** > > ** ** > > Leon: start is useful, but there is a problem with stop - how is stop sen= t? > **** > > Ram: Are there any use cases?**** > > Paul: Can do it for a dialog, but not for a CS which can be many dialogs, > so not clear how you would define when the start time was but can identif= y > when participants join and leave.**** > > Brian: What do we need this for?**** > > ** ** > > Is there a need to track the times a CS is part of CS-Group ?**** > > Leon: This is needed for snapshot**** > > Paul: Example could be supervisor who joins a call center call to listen > or whisper might need to now when this happens. - might need this.**** > > Chairs: Need more discussion on use cases and whether this needs to be > specified or whether it is an extension.**** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Hutton, Andrew > *Sent:* Friday, December 09, 2011 5:28 PM > *To:* siprec@ietf.org > *Subject:* [siprec] IETF 82 Minutes.**** > > ** ** > > SIPREC IETF82 minutes can be found at > http://www.ietf.org/proceedings/82/minutes/siprec.txt*.***** > > **** > > Any issues with these then please let me know and I will check against th= e > audio and correct if necessary.**** > > **** > > Lets kick start some discussion on the open issues since we have all had = a > few weeks now to recover after Taipei.**** > > **** > > Regards**** > > Andy**** > > **** > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > --f46d0438949f216b0004b651a46d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Partha, Hi

So based on below, participa= nt and media association times are related to CS and not RS? In such case S= RS can know when somebody joined conversation and not only when somebody go= t started to be recorded.=A0

Back to the question for specific regulations.They do n= ot state explicitly to have distinction between recording and communication= times - they are very high level and talking about keeping records of all = communication and electronic interactions. But customer requirements that w= e have is to be able to search and view actual communications times and not= only recording times. And current SRS=A0implementations distinguish betwee= n these two.=A0

Regards

Leon

On Wed, Jan 11, 2012 at 7:09 PM, Ravindran, Parthasarathi = <pravindran= @sonusnet.com> wrote:

Leon,

=A0<= /p>

In case media level, it i= s possible to find the start/stop time using participantstream association = or SDP attribute change for a specific stream. In case of participant to CS, association & disassociation=A0 attribute helps to = identify how long participant is associated with CS during the recording.

=A0<= /p>

Please read inline for mo= re comments.

=A0<= /p>

Thanks

Partha

=A0<= /p>

From: Leon Por= tman [mailto:Leo= n.Portman@nice.com]
Sent: Tuesday, January 10, 2012 8:16 PM
To: Ravindran, Parthasarathi; siprec@ietf.org
Subject: RE: Start & stop time for CS [was RE: IETF 82 Minutes.]=

=A0

First couple of comments:=

1.=A0=A0=A0=A0=A0=A0 We need it also on t= he media level =96 for example when video or text sharing started/ended and= not only complete CS

2.=A0=A0=A0=A0=A0=A0 Same for participant= s =96 joining/leaving CS

=A0<= /p>

For the scenarios where R= S covers on part of CS =96 like record on demand, how SRS will know when CS= have started?

<partha> SRC = has to maintain the dialog history information like Call Detail records (CD= R) then only, this requirement will be solved. This requirement is not required to be mandated in all SRC </partha>

=A0<= /p>

It is import from complia= nce recording point of view to indicate that RS does not cover complete CS.=

<partha> Coul= d you please provide the name of compliance which mandate CS start/stop tim= e </partha>

=A0<= /p>

Hope it helps

=A0<= /p>

Leon=

=A0<= /p>

From: siprec-bounces= @ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi
Sent: Thursday, January 05, 2012 7:16 PM
To: siprec@ietf= .org
Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minu= tes.]

=A0

Hi all,

=A0

Associate/disassociate time helps to understand how long C= S is associated with RS. Initial association time shall be considered=A0 as= start time and final disassociation time shall be considered as stop time. As we could not conclude this open item during= IETF-82, I=92m starting this mail thread for discussion.

=A0

I could not see any other strong reason for having start/s= top time for CS apart from associate/disassociate time. Please provide usec= ase for including start/stop time attribute in CS.

=A0

In case we could not see the proper usecase, it is better = to remove from metadata draft.

=A0

Thanks

Partha

=A0

Note: =93Relevant IETF-82 notes=94

=A0

There was a comment to include start/Stop time also. Is it= needed ?

Start time seems to makes since RS may have started only a= fter CS was started. Stop time seems to be problematic in case of missing a= ssociation. Problem to define start/stop time since a CS may include multiple SIP dialogs.

=A0

Leon: start is useful, but there is a problem with stop - = how is stop sent?

Ram: Are there any use cases?

Paul: Can do it for a dialog, but not for a CS which can b= e many dialogs, so not clear how you would define when the start time was b= ut can identify when participants join and leave.

Brian: What do we need this for?

=A0

Is there a need to track the times a CS is part of CS-Grou= p ?

Leon: This is needed for snapshot

Paul: Example could be supervisor who joins a call center = call to listen or whisper might need to now when this happens. - might need= this.

Chairs: Need more discussion on use cases and whether this= needs to be specified or whether it is an extension.<= /p>

=A0

=A0

=A0<= /p>

=A0<= /p>

From: siprec-bounces= @ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: Friday, December 09, 2011 5:28 PM
To: siprec@ietf= .org
Subject: [siprec] IETF 82 Minutes.

=A0

SIPREC IETF82 minutes can be found at http://www.ietf.org/proceedings/82/minutes/siprec.txt.<= u>

=A0

Any issues with these then please let m= e know and I will check against the audio and correct if necessary.<= u>

=A0

Lets kick start some discussion on the = open issues since we have all had a few weeks now to recover after Taipei.<= u>

=A0

Regards

Andy

=A0


_______________________________________________
siprec mailing list
siprec@ietf.org
= https://www.ietf.org/mailman/listinfo/siprec


--f46d0438949f216b0004b651a46d-- From andrew.hutton@siemens-enterprise.com Thu Jan 12 11:23:38 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8421C21F8675 for ; Thu, 12 Jan 2012 11:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 kn3t0nvqGvcV for ; Thu, 12 Jan 2012 11:23:38 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B5F5421F8667 for ; Thu, 12 Jan 2012 11:23:37 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 1DC6B23F04B3; Thu, 12 Jan 2012 20:23:34 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 12 Jan 2012 20:23:34 +0100 From: "Hutton, Andrew" To: "leonp@nice.com" Date: Thu, 12 Jan 2012 20:24:12 +0100 Thread-Topic: [siprec] #80: How to identify CS in SRS Initiated recording. Thread-Index: AczPpzFy7xaifiWpRfSpsHIV8W2KoQBtstMg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3120046E720@MCHP058A.global-ad.net> References: <077.46a021a77843bb47f233c7c1c87f9c9c@trac.tools.ietf.org> <092.7b6d0d9dc36a442d345fbb85223083ab@trac.tools.ietf.org> In-Reply-To: <092.7b6d0d9dc36a442d345fbb85223083ab@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] #80: How to identify CS in SRS Initiated recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:23:38 -0000 SGkgTGVvbiwNCg0KVGhpcyBpc3N1ZSB3YXMgcmFpc2VkIGFnYWluc3QgdGhlIGFyY2hpdGVjdHVy ZSBkcmFmdCBiZWNhdXNlIGFzIHdlIGRpc2N1c3NlZCBpbiBUYWlwZWkgc2VjdGlvbiAzLjIuMiBu ZWVkcyB1cGRhdGluZyBldmVuIGlmIGl0IGlzIGp1c3QgdG8gcmVtb3ZlIHNvbWUgb2YgdGhlIGV4 aXN0aW5nIHRleHQuDQoNCldlIGFsc28gc3RhdGVkIHRoYXQgd2UgbmVlZGVkIG1vcmUgZGlzY3Vz c2lvbiBvbiB3aGF0IHRvIHNheSBhYm91dCB0aGUgU1JTIGlkZW50aWZ5aW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLiBJIHBlcnNvbmFsbHkgdGhpbmsgd2Ugc2hvdWxkIHN0YXRlIHRoYXQg b25lIG9wdGlvbiBpcyB0aGF0IHRoaXMgaXMgZG93biB0byBwb2xpY3kgYXQgdGhlIFNSQy4gIFdl IGNvdWxkIGFsc28gZGVmaW5lIGEgbmV3IGhlYWRlciBzb21ldGhpbmcgbGlrZSBqb2luIG9yIGV2 ZW4gdXNlIHRoZSBqb2luIGhlYWRlciBhbmQgZGVmaW5lIGhvdyBpdCB1cyB1c2VkIGluIHRoZSBj b250ZXh0IG9mIGEgcmVjb3JkaW5nIHNlc3Npb24uDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIGlzc3Vl IGlzIGNsb3NlZCB1bnRpbCB3ZSBhZ3JlZSBvbiB0ZXh0IGZvciBzZWN0aW9uIDMuMi4yIG9mIHRo ZSBhcmNoaXRlY3R1cmUgZHJhZnQuDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQoNCg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcHJlYyBpc3N1ZSB0cmFja2VyIFttYWls dG86dHJhYytzaXByZWNAdHJhYy50b29scy5pZXRmLm9yZ10NCj4gU2VudDogMTAgSmFudWFyeSAy MDEyIDE0OjUwDQo+IFRvOiBIdXR0b24sIEFuZHJldzsgbGVvbnBAbmljZS5jb20NCj4gQ2M6IHNp cHJlY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcHJlY10gIzgwOiBIb3cgdG8gaWRlbnRp ZnkgQ1MgaW4gU1JTIEluaXRpYXRlZA0KPiByZWNvcmRpbmcuDQo+IA0KPiAjODA6IEhvdyB0byBp ZGVudGlmeSBDUyBpbiBTUlMgSW5pdGlhdGVkIHJlY29yZGluZy4NCj4gDQo+IENoYW5nZXMgKGJ5 IGxlb25wQOKApik6DQo+IA0KPiAgKiBzdGF0dXM6ICBuZXcgPT4gY2xvc2VkDQo+ICAqIHJlc29s dXRpb246ICAgPT4gZml4ZWQNCj4gDQo+IA0KPiBDb21tZW50Og0KPiANCj4gIEl0IHdhcyBkZWNp ZGVkIGR1cmluZyBJRVRGODIgdG8gY292ZXIgaXQgaW4gdGhlIHByb3RvY29sIGRyYWZ0DQo+IA0K PiAtLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gIFJlcG9ydGVyOiAgYW5kcmV3Lmh1dHRvbkDigKYgICAgIHwgICAg ICAgT3duZXI6ICBhbmRyZXcuaHV0dG9uQOKApg0KPiAgICAgIFR5cGU6ICBlbmhhbmNlbWVudCAg ICAgICAgIHwgICAgICBTdGF0dXM6ICBjbG9zZWQNCj4gIFByaW9yaXR5OiAgbWFqb3IgICAgICAg ICAgICAgICB8ICAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBBcmNoaXRlY3R1cmUgICAgICAg IHwgICAgIFZlcnNpb246DQo+ICBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgfCAgUmVz b2x1dGlvbjogIGZpeGVkDQo+ICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgfA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+IFRpY2tldCBVUkw6DQo+IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93 Zy9zaXByZWMvdHJhYy90aWNrZXQvODAjY29tbWVudDoxPg0KPiBzaXByZWMgPGh0dHA6Ly90b29s cy5pZXRmLm9yZy9zaXByZWMvPg0KDQo= From andrew.hutton@siemens-enterprise.com Fri Jan 13 11:23:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A727D21F8565 for ; Fri, 13 Jan 2012 11:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.228, 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 u8IQtj7tPMJQ for ; Fri, 13 Jan 2012 11:23:25 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CEAC321F8579 for ; Fri, 13 Jan 2012 11:23:24 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 5CF241EB8447 for ; Fri, 13 Jan 2012 20:23:21 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 13 Jan 2012 20:23:21 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 13 Jan 2012 20:23:19 +0100 Thread-Topic: Update on meeting in Boston 17th Feb 2012. Thread-Index: AczSKM7APyVpoo/nTNKRBA9WsGvLJA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312004F880A@MCHP058A.global-ad.net> 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_101C6067BEC68246B0C3F6843BCCC1E312004F880AMCHP058Agloba_" MIME-Version: 1.0 Subject: [siprec] Update on meeting in Boston 17th Feb 2012. 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, 13 Jan 2012 19:23:25 -0000 --_000_101C6067BEC68246B0C3F6843BCCC1E312004F880AMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, My proposal is not to call a formal SIPREC interim meeting but instead to h= ave a more informal design team type meeting if we can get enough people to= gether. I am not sure whether I can make it to Boston and probably Brian will not a= ttend so it may be that we will be without any chairs at the meeting and I = would like to avoid remote participation at least trying to chair the meeti= ng remotely would I think not work. An informal design team meeting is I think what would work best anyway givi= ng the chance for making some real progress with the RTP/RTCP, architecture= and protocol drafts. Probably the right people will not be there to progre= ss the metadata draft. If we can get enough people together we can hopeful= ly make enough progress to be in good shape for Paris when more people will= be able to attend. So far I know Charles Eckel, Paul Kyzivat and Mary are going to be at the C= LUE meeting if others can confirm on the list that they would attend that w= ould be great. Regards Andy --_000_101C6067BEC68246B0C3F6843BCCC1E312004F880AMCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

My proposal is not to call a formal= SIPREC interim meeting but instead to have a more informal design team type meetin= g if we can get enough people together. 

 

I am not sure whether I can make it= to Boston and probably Brian will not attend so it may be that we will be with= out any chairs at the meeting and I would like to avoid remote participation at lea= st trying to chair the meeting remotely would I think not work.

 

An informal design team meeting is = I think what would work best anyway giving the chance for making some real progress= with the RTP/RTCP, architecture and protocol drafts. Probably the right people w= ill not be there to progress the metadata draft.  If we can get enough peo= ple together we can hopefully make enough progress to be in good shape for Paris when mo= re people will be able to attend.

 

So far I know Charles Eckel, Paul K= yzivat and Mary are going to be at the CLUE meeting if others can confirm on the list = that they would attend that would be great.

 

Regards

Andy

 

--_000_101C6067BEC68246B0C3F6843BCCC1E312004F880AMCHP058Agloba_-- From leon.portman@gmail.com Fri Jan 13 11:28:04 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29A421F85FB for ; Fri, 13 Jan 2012 11:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HrCNdKHQvgYB for ; Fri, 13 Jan 2012 11:28:04 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1B21F85D3 for ; Fri, 13 Jan 2012 11:28:03 -0800 (PST) Received: by wgbdt14 with SMTP id dt14so1694389wgb.1 for ; Fri, 13 Jan 2012 11:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=FVmbkMZOWsjoAArOympnSsjVJpurEFzL/L6KIUm30P0=; b=hcd+7HtPwbsH6oFH4HNMxt/gamv/FVCX3jC0nddLV9XG/HHWS8jas4yAI1kzMXiDd5 4RXoChLRndH81E0Ssq8ND/fvZL60dG1zlVUo06/Ll9YKmwuBTTnt0vdzJIVqoUdZ/JPp 6XuQulmRQDmrQJNuqEfiFKLryifog/SYDbMq8= Received: by 10.180.20.18 with SMTP id j18mr4297280wie.20.1326482882861; Fri, 13 Jan 2012 11:28:02 -0800 (PST) Received: from [192.168.1.106] ([212.150.140.190]) by mx.google.com with ESMTPS id em13sm4863623wid.7.2012.01.13.11.28.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 11:28:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1256) Content-Type: multipart/alternative; boundary="Apple-Mail=_953D29C8-315B-4386-AAA3-F892B4ED4D38" From: Leon Portman In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312004F880A@MCHP058A.global-ad.net> Date: Fri, 13 Jan 2012 21:28:00 +0200 Message-Id: <36148A0C-293E-4A78-9FAE-BE2A6C2908EA@gmail.com> References: <101C6067BEC68246B0C3F6843BCCC1E312004F880A@MCHP058A.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1256) Cc: "siprec@ietf.org" Subject: Re: [siprec] Update on meeting in Boston 17th Feb 2012. 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, 13 Jan 2012 19:28:04 -0000 --Apple-Mail=_953D29C8-315B-4386-AAA3-F892B4ED4D38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I plan to be there if SIPREC will meet Leon On Jan 13, 2012, at 9:23 PM, Hutton, Andrew wrote: > Hi All, > =20 > My proposal is not to call a formal SIPREC interim meeting but instead = to have a more informal design team type meeting if we can get enough = people together.=20 > =20 > I am not sure whether I can make it to Boston and probably Brian will = not attend so it may be that we will be without any chairs at the = meeting and I would like to avoid remote participation at least trying = to chair the meeting remotely would I think not work. > =20 > An informal design team meeting is I think what would work best anyway = giving the chance for making some real progress with the RTP/RTCP, = architecture and protocol drafts. Probably the right people will not be = there to progress the metadata draft. If we can get enough people = together we can hopefully make enough progress to be in good shape for = Paris when more people will be able to attend. > =20 > So far I know Charles Eckel, Paul Kyzivat and Mary are going to be at = the CLUE meeting if others can confirm on the list that they would = attend that would be great. > =20 > Regards > Andy > =20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec --Apple-Mail=_953D29C8-315B-4386-AAA3-F892B4ED4D38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I plan to be there if SIPREC will = meet

Leon

On Jan 13, 2012, at = 9:23 PM, Hutton, Andrew wrote:

Hi = All,
 
My proposal is not to call a formal SIPREC interim = meeting but instead to have a more informal design team type meeting if = we can get enough people together. 
 
I am not sure whether I can make it = to Boston and probably Brian will not attend so it may be that we will = be without any chairs at the meeting and I would like to avoid remote = participation at least trying to chair the meeting remotely would I = think not work.
 
An informal design team meeting is I think what would = work best anyway giving the chance for making some real progress with = the RTP/RTCP, architecture and protocol drafts. Probably the right = people will not be there to progress the metadata draft.  If we can = get enough people together we can hopefully make enough progress to be = in good shape for Paris when more people will be able to = attend.
 
So far I know Charles Eckel, Paul Kyzivat and Mary are = going to be at the CLUE meeting if others can confirm on the list that = they would attend that would be great.
 
Regards
Andy
 
_______________________= ________________________
siprec mailing list
siprec@ietf.org
X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: andrew.hutton@siemens-enterprise.com, leonp@nice.com X-Trac-Project: siprec Date: Sun, 15 Jan 2012 07:47:23 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/81 Message-ID: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: andrew.hutton@siemens-enterprise.com, leonp@nice.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: [siprec] #81: CS identification in SRS initiated recording 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: Sun, 15 Jan 2012 07:47:32 -0000 #81: CS identification in SRS initiated recording We should finalize text describing architecture of SRS initiated recording in section 3.2.2 of architecture draft. The actual protocol definition will be defined in the protocol draft. -- --------------------------+----------------------------- Reporter: leonp@… | Owner: andrew.hutton@… Type: defect | Status: new Priority: major | Milestone: Component: Architecture | Version: Severity: - | Keywords: --------------------------+----------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Sat Jan 14 23:48:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E780021F847B for ; Sat, 14 Jan 2012 23:48:49 -0800 (PST) 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=[AWL=0.000, 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 O8fPK5D8STBh for ; Sat, 14 Jan 2012 23:48:49 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 82A1E21F8468 for ; Sat, 14 Jan 2012 23:48:49 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RmKpd-0002yp-7X; Sun, 15 Jan 2012 02:48:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: leonp@nice.com X-Trac-Project: siprec Date: Sun, 15 Jan 2012 07:48:49 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/siprec/trac/ticket/81#comment:1 Message-ID: <070.6d16f47b90d2f35b3a78b17ef2e55f88@trac.tools.ietf.org> References: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leonp@nice.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #81: CS identification in SRS initiated recording 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: Sun, 15 Jan 2012 07:48:50 -0000 #81: CS identification in SRS initiated recording Changes (by leonp@…): * owner: andrew.hutton@… => leonp@… -- --------------------------+---------------------- Reporter: leonp@… | Owner: leonp@… Type: defect | Status: new Priority: major | Milestone: Component: Architecture | Version: Severity: - | Resolution: Keywords: | --------------------------+---------------------- Ticket URL: siprec From friso.feenstra@logica.com Sun Jan 15 11:24:09 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA94921F847A for ; Sun, 15 Jan 2012 11:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8L09OD4ebUYy for ; Sun, 15 Jan 2012 11:24:08 -0800 (PST) Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 64C1921F8432 for ; Sun, 15 Jan 2012 11:24:08 -0800 (PST) Received: from mail25-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 15 Jan 2012 19:24:05 +0000 Received: from mail25-va3 (localhost [127.0.0.1]) by mail25-va3-R.bigfish.com (Postfix) with ESMTP id 2E3AC5C0051 for ; Sun, 15 Jan 2012 19:24:05 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1202hzz8275bh8275dhz2fhc1ahc1bhc1ahc1bh2a8h668h839h) X-Forefront-Antispam-Report: CIP:78.41.242.18; KIP:(null); UIP:(null); IPV:NLI; H:smtp-edge02.logica.com; RD:none; EFVD:NLI Received-SPF: pass (mail25-va3: domain of logica.com designates 78.41.242.18 as permitted sender) client-ip=78.41.242.18; envelope-from=friso.feenstra@logica.com; helo=smtp-edge02.logica.com ; 2.logica.com ; Received: from mail25-va3 (localhost.localdomain [127.0.0.1]) by mail25-va3 (MessageSwitch) id 1326655442684740_27990; Sun, 15 Jan 2012 19:24:02 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.247]) by mail25-va3.bigfish.com (Postfix) with ESMTP id 98E3A4A004B for ; Sun, 15 Jan 2012 19:24:02 +0000 (UTC) Received: from smtp-edge02.logica.com (78.41.242.18) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sun, 15 Jan 2012 19:24:01 +0000 Received: from smtp-hub-se.global.logica.com (158.234.96.12) by smtp-edge02.global.logica.com (83.174.99.227) with Microsoft SMTP Server (TLS) id 8.2.234.1; Sun, 15 Jan 2012 20:24:01 +0100 Received: from SE-EX019.groupinfra.com ([169.254.1.183]) by SE-EX013.groupinfra.com ([158.234.96.12]) with mapi id 14.01.0323.000; Sun, 15 Jan 2012 20:24:01 +0100 From: "Feenstra, Friso" To: "siprec@ietf.org" Thread-Topic: Drawings in siprec-architecture-03 Thread-Index: AczTuzolh9BcrHB6TPqCGY6DSa9FCQ== Date: Sun, 15 Jan 2012 19:24:00 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.234.119.34] Content-Type: multipart/alternative; boundary="_000_A4E1C77AFA24EF4A9DBDF6CB6491D0E741DBF9EBSEEX019groupinf_" MIME-Version: 1.0 X-OriginatorOrg: logica.com Subject: [siprec] Drawings in siprec-architecture-03 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, 15 Jan 2012 19:24:09 -0000 --_000_A4E1C77AFA24EF4A9DBDF6CB6491D0E741DBF9EBSEEX019groupinf_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I am visually oriented and as such always look first at pictures and after = that study the text. On the drawings in siprec-architecture-03 I have the f= ollowing remarks. 1. In some drawings for the voice stream the abbreviation RTP is used,= while for others the abbreviation RTP/RTCP is used. Is there a reason for = this, if not I would recommend to standardize on RTP. 2. In figure 3, it is suggested that the RTP/RTCP stream flows from SR= C to SRS and vice versa. Other figures suggest that the stream only flows f= rom SRC to SRS. 3. In figure 4, it is suggested that the RTP stream flows from SRS to = SRC and that the SIP session is only established from SRC to SRS (and not v= ice versa) 4. In figure 5, I would recommend to draw lines for both SIP and RTP s= treams per dialog and indicate SIP for the top recording session connection= . Alternatives Figure 1 +-----------+ (Recording Session) | Session | +------SIP------>| Recording | | | Server | | +---RTP------>| (SRS) | | | +-----------+ V | ^ +-------------+ | | | | | |-- MetaData -+ | | | B2BUA | | | | Session | +--------+ | Recording | +---------+ | |<- SIP ->| Client |<- SIP ->| | | UA-A | | (SRC) | | UA-B | | |<- RTP ->| |<- RTP ->| | +--------+ | | +---------+ +-------------+ |____________________________________________________| (Communication Session) Figure 2 (Recording Session) +-----------+ +----------SIP------>| | | +-------RTP------>| Session | | | | Recording | | | | Server | | | +-- Metadata -->| (SRS) | | | | | | | | | +-----------+ | | | | | | | | | | | | V | | (Communication Session) +--+------+ +---------+ | |<-------SIP--------->| | | UA-A | | UA-B | | (SRC) |<-------RTP--------->| | +---------+ +---------+ Figure 3 Session Recording Server (SRS) +----------------------------------------+ | | (Recording Session) | +-----------+ +------------+ | +------------SIP----|->| | | | | | | | MediaCtrl |MEDIACTRL | Media | | | | |Application|<-------->| Server | | | +-----Metadata--->| Server | | (Recorder)| | | | | | | | | | | | | +-----------+ +------------+ | | | | ^ | | | +------------------------------|---------+ | | +-----------------RTP----------------------+ | | | V | | +---+------+ +---------+ | |<-------SIP-------------->| | | UA-A | (Communication Session) | UA-B | | (SRC) |<-------RTP-------------->| | +----------+ +---------+ Figure 4 +----------+ (Recording Session) | Session | +-----------SIP------------------------->|Recording | | | Server | | | (SRS) | V UA-A Session Recording Client (SRC) +----------+ +----------------------------------------+ ^ ^ | | | | | +-----------+ +------------+ |---RTP---+ | | | | Control | | | | | | UA | Protocol | Media | |---Metadata-+ | |Application|<-------->| Server | | +---------+ | | Server | | | | | | | | | | | |<----SIP----->| UA-B | | +-----------+ +------------+ |<----RTP----->| | | | +---------+ +----------------------------------------+ Figure 5 User 1 +-----------+ | | | | |Participant| | 1 | | | +-----------+ ^ ^ | | Dialog RTP SIP 1 | | User 2 V V Recording +-----------+ +-----------+ Session ************* | | | |<---SIP------>* * | |<---SIP--->| |----RTP 1 --->* * |Participant| | Focus/SRC |----RTP 2 --->* SRS * | 2 |<---RIP--->| |----RTP 3 --->* * | | Dialog | |--Metadata--->* * +-----------+ 2 +-----------+ ************* ^ ^ | | Dialog RTP SIP 3 | | V V +-----------+ | | | | |Participant| | 3 | | | +-----------+ User 3 Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipi= ent(s) only. It may contain proprietary material, confidential information = and/or be subject to legal privilege. It should not be copied, disclosed to= , retained or used by, any other party. If you are not an intended recipien= t then please promptly delete this e-mail and any attachment and all copies= and inform the sender. Thank you. --_000_A4E1C77AFA24EF4A9DBDF6CB6491D0E741DBF9EBSEEX019groupinf_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I am visually oriented and as such always look first= at pictures and after that study the text. On the drawings in siprec-archi= tecture-03 I have the following remarks.

 

1.      In some drawings for the voice stream the abbreviat= ion RTP is used, while for others the abbreviation RTP/RTCP is used. Is the= re a reason for this, if not I would recommend to standardize on RTP.<= /o:p>

2.      In figure 3, it is suggested that the RTP/RTCP stre= am flows from SRC to SRS and vice versa. Other figures suggest that the str= eam only flows from SRC to SRS.

3.      In figure 4, it is suggested that the RTP stream fl= ows from SRS to SRC and that the SIP session is only established from SRC t= o SRS (and not vice versa)

4.      In figure 5, I would recommend to draw lines for bo= th SIP and RTP streams per dialog and indicate SIP for the top recording se= ssion connection.

 

 

Alternatives

 

Figure 1

&nbs= p;

 <= /o:p>

  =             &nb= sp;            =             &nb= sp;      +-----------+

  =             &nb= sp;           (Recording = Session) |  Session  |

  =             &nb= sp;            =   +------SIP------>| Recording |

  =             &nb= sp;            =   |           &= nbsp;    |  Server   |

  =             &nb= sp;            =   |  +---RTP------>|  (SRS)    |<= /o:p>

  =             &nb= sp;            =   |  |          = ;   +-----------+

  =             &nb= sp;            =   V  |          = ;         ^

  =              &n= bsp;        +-------------+=              |<= o:p>

  =             &nb= sp;         |   &nbs= p;         |    = ;         |

  =             &nb= sp;         |   &nbs= p;         |-- MetaData -+=

  =             &nb= sp;         |   &nbs= p;         |

  =             &nb= sp;         |    B2B= UA    |

  =             &nb= sp;         |   &nbs= p;         |

  =             &nb= sp;         |   Session&n= bsp;  |

  =    +--------+       &n= bsp; |  Recording  |       &nb= sp; +---------+

  =    |        |<- SIP ->|&= nbsp;  Client    |<- SIP ->|   &nb= sp;     |

  =    |  UA-A  |       =   |   (SRC)     |    = ;     |  UA-B   |

  =    |        |<- RTP ->|&= nbsp;            |&l= t;- RTP ->|         |=

  =    +--------+       &n= bsp; |           &nb= sp; |         +---------+

  =             &nb= sp;         +-------------+=

  =    |____________________________________________________|

  =             &nb= sp;     (Communication Session)

 <= /o:p>

Figure 2

 

 
          (Recording =
Session) +-----------+
         +----------SI=
P------>|           |<=
o:p>
         |  +----=
---RTP------>|  Session  |
         |  | &n=
bsp;            =
;   | Recording |
         |  | &n=
bsp;            =
;   |  Server   |
         |  | +--=
 Metadata -->|   (SRS)   |
         |  | | =
            &nb=
sp; |           |
         |  | | =
            &nb=
sp; +-----------+
         |  | |<=
/o:p>
         |  | |<=
/o:p>
         |  | |<=
/o:p>
         |  | |<=
/o:p>
         V  | | =
 (Communication Session)
      +--+------+  =
            &nb=
sp;      +---------+

      |      &nb=
sp;  |<-------SIP--------->|     &=
nbsp;   |


      |  UA-A   | &nb=
sp;            =
       |  UA-B   |<=
/span>


      |  (SRC)  |<-------RTP=
--------->|         |=



      +---------+  &nbs=
p;            &=
nbsp;     +---------+


 


 


Figure 3


 


 


           =
            &nb=
sp;            =
 Session Recording Server (SRS)


           =
            &nb=
sp;      +------------------------------------=
----+


           =
            &nb=
sp;      |      &nbs=
p;            &=
nbsp;           &nbs=
p;        |


          (Recording =
Session) |  +-----------+      &=
nbsp;   +------------+ |


          +------=
------SIP----|->|         &=
nbsp; |          |  =
          | |


          | &nbs=
p;            &=
nbsp;    |  | MediaCtrl |MEDIACTRL |   Media&=
nbsp;   | |


          | &nbs=
p;            &=
nbsp;    |  |Application|<-------->|   =
Server   | |


          | &nbs=
p;  +-----Metadata--->|  Server   |  &=
nbsp;       |  (Recorder)| |<=
/span>


          | &nbs=
p;  |           =
;   |  |        &nbs=
p;  |          | &nb=
sp;          | |


          | &nbs=
p;  |           =
;   |  +-----------+     &n=
bsp;    +------------+ |


          | &nbs=
p;  |           =
;   |          =
            &nb=
sp;       ^     &nbs=
p;   |


          | &nbs=
p;  |           =
;   +------------------------------|---------+=



          | &nbs=
p;  |  +-----------------RTP----------------------+<=
/o:p>


          |    |  |<=
/o:p>


          V &nbs=
p;  |  |


        +---+------+=
;            &n=
bsp;            =
; +---------+


        |   &nbs=
p;      |<-------SIP-------------->| &n=
bsp;       |


        |   UA-A =
;  | (Communication Session)  |  UA-B   |


        |   (SRC)  |<-------RTP------=
-------->|         |<=
/span>


        +----------+&nb=
sp;            =
             &#=
43;---------+


 


 


Figure 4


 


           =
            &nb=
sp;            =
            &nb=
sp;   +----------+


           =
      (Recording Session)    &=
nbsp;           | Session=
  |


           +=
-----------SIP------------------------->|Recording |

           |&nbs=
p;            &=
nbsp;            &nb=
sp;            =
 |  Server  |


           |&nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp; |   (SRS)  |


           V&nbs=
p; UA-A Session Recording Client (SRC)   +----------+


    +----------------------------------------&#=
43;         ^  ^


    |       &nbs=
p;            &=
nbsp;           &nbs=
p;       |      =
;   |  |


    |  +-----------+   =
       +------------+ |---RTP---+=
  |


    |  |      &n=
bsp;    | Control  |      =
;      | |      &nbs=
p;     |


    |  |    UA   =
;  | Protocol |   Media    | |---Metadata-=
3;


    |  |Application|<-------->|  Se=
rver    | |        &=
nbsp;     +---------+


    |  |  Server   |  =
;        |     =
       | |      =
;        |     =
    |


    |  |      &n=
bsp;    |        &nb=
sp; |            | |=
<----SIP----->|  UA-B   |


    |  +-----------+   =
       +------------+ |<----RTP---=
-->|         |=



    |       &nbs=
p;            &=
nbsp;            &nb=
sp;      |      =
;        +---------+<=
/span>


    +----------------------------------------&#=
43;


 


 

Figure 5


 


 


           =
            &nb=
sp;        User 1

           =
            &nb=
sp;    +-----------+


           =
            &nb=
sp;    |        &nbs=
p;  |


           =
            &nb=
sp;    |        &nbs=
p;  |


           =
            &nb=
sp;    |Participant|


           =
            &nb=
sp;    |     1     |=



           =
            &nb=
sp;    |        &nbs=
p;  |


           =
            &nb=
sp;    +-----------+


           =
            &nb=
sp;       ^     ^


           =
             &n=
bsp;      |     |


           =
          Dialog   R=
TP   SIP


           =
             1&=
nbsp;     |     |=



       User 2    =
;            &n=
bsp; V     V     Recording


    +-----------+    &n=
bsp;      +-----------+  Session =
;    *************


    |       &nbs=
p;   |          =
; |           |<---SIP=
------>*           *


    |       &nbs=
p;   |<---SIP--->|       =
;    |----RTP 1 --->*       =
;    *


    |Participant|     &nbs=
p;     | Focus/SRC |----RTP 2 --->*   =
; SRS    *


    |     2   &n=
bsp; |<---RIP--->|        &nb=
sp;  |----RTP 3 --->*       &nbs=
p;   *


    |       &nbs=
p;   |  Dialog   |     &n=
bsp;     |--Metadata--->*    &nb=
sp;      *


    +-----------+    2  =
;    +-----------+     =
;         *************<=
/span>


           =
            &nb=
sp;       ^    ^


           =
            &nb=
sp;       |    |


           =
          Dialog   R=
TP  SIP


           =
             3&=
nbsp;     |    |
=


           =
            &nb=
sp;       V    V


           =
            &nb=
sp;    +-----------+


           =
            &nb=
sp;    |        &nbs=
p;  |


           =
            &nb=
sp;    |        &nbs=
p;  |


           =
            &nb=
sp;    |Participant|


           =
            &nb=
sp;    |    3      |=



           =
            &nb=
sp;    |        &nbs=
p;  |


           =
            &nb=
sp;    +-----------+


           =
            &nb=
sp;       User 3


 


 


 

Think green - keep it on the screen.=0D =0D This e-mail and any attachment is for authorised use by the intended recipi= ent(s) only. It may contain proprietary material, confidential information = and/or be subject to legal privilege. It should not be copied, disclosed to= , retained or used by, any other party. If you are not an intended recipien= t then please promptly delete this e-mail and any attachment and all copies= and inform the sender. Thank you.=0D --_000_A4E1C77AFA24EF4A9DBDF6CB6491D0E741DBF9EBSEEX019groupinf_-- From Leon.Portman@nice.com Mon Jan 16 00:55:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FD321F8592 for ; Mon, 16 Jan 2012 00:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 biwvQR4UMoVv for ; Mon, 16 Jan 2012 00:55:27 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 607B321F858A for ; Mon, 16 Jan 2012 00:55:25 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 16 Jan 2012 10:55:22 +0200 From: Leon Portman To: "Feenstra, Friso" , "siprec@ietf.org" Date: Mon, 16 Jan 2012 10:55:21 +0200 Thread-Topic: Drawings in siprec-architecture-03 Thread-Index: AczTuzolh9BcrHB6TPqCGY6DSa9FCQAcCiWg Message-ID: <07465C1D981ABC41A344374066AE1A2C39D32BD995@TLVMBX01.nice.com> References: In-Reply-To: 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_07465C1D981ABC41A344374066AE1A2C39D32BD995TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Drawings in siprec-architecture-03 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, 16 Jan 2012 08:55:29 -0000 --_000_07465C1D981ABC41A344374066AE1A2C39D32BD995TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Friso Hello Thank you very much for comments. 1. Regarding showing RTP or RTP/RTCP in the figures. This was one of = the recent changes in order to show best practice from MMUSIC to always sup= port RTCP. I think we should to show RTP/RTCP on every figures. Or is it enough only t= o mention it in the text? 2. RTP/RTCP direction. This is very good point. RTP will be one direc= tion (SRC to SRS) but RTCP is bi-directional. So if we will user RTP/RTCP a= s one label, line should be bi-directional as well. Any opinions? 3. Figure 4 is mistake, I will fix it. 4. Figure 5, I agree as well. Thank you for the figure proposals. Any comments from the list? Most important is to finalize RTP or RTP/RTPC = labels in the figures from my point of view. Regards Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Feenstra, Friso Sent: Sunday, January 15, 2012 9:24 PM To: siprec@ietf.org Subject: [siprec] Drawings in siprec-architecture-03 All, I am visually oriented and as such always look first at pictures and after = that study the text. On the drawings in siprec-architecture-03 I have the f= ollowing remarks. 1. In some drawings for the voice stream the abbreviation RTP is used= , while for others the abbreviation RTP/RTCP is used. Is there a reason for= this, if not I would recommend to standardize on RTP. 2. In figure 3, it is suggested that the RTP/RTCP stream flows from S= RC to SRS and vice versa. Other figures suggest that the stream only flows = from SRC to SRS. 3. In figure 4, it is suggested that the RTP stream flows from SRS to= SRC and that the SIP session is only established from SRC to SRS (and not = vice versa) 4. In figure 5, I would recommend to draw lines for both SIP and RTP = streams per dialog and indicate SIP for the top recording session connectio= n. Alternatives Figure 1 +-----------+ (Recording Session) | Session | +------SIP------>| Recording | | | Server | | +---RTP------>| (SRS) | | | +-----------+ V | ^ +-------------+ | | | | | |-- MetaData -+ | | | B2BUA | | | | Session | +--------+ | Recording | +---------+ | |<- SIP ->| Client |<- SIP ->| | | UA-A | | (SRC) | | UA-B | | |<- RTP ->| |<- RTP ->| | +--------+ | | +---------+ +-------------+ |____________________________________________________| (Communication Session) Figure 2 (Recording Session) +-----------+ +----------SIP------>| | | +-------RTP------>| Session | | | | Recording | | | | Server | | | +-- Metadata -->| (SRS) | | | | | | | | | +-----------+ | | | | | | | | | | | | V | | (Communication Session) +--+------+ +---------+ | |<-------SIP--------->| | | UA-A | | UA-B | | (SRC) |<-------RTP--------->| | +---------+ +---------+ Figure 3 Session Recording Server (SRS) +----------------------------------------+ | | (Recording Session) | +-----------+ +------------+ | +------------SIP----|->| | | | | | | | MediaCtrl |MEDIACTRL | Media | | | | |Application|<-------->| Server | | | +-----Metadata--->| Server | | (Recorder)| | | | | | | | | | | | | +-----------+ +------------+ | | | | ^ | | | +------------------------------|---------+ | | +-----------------RTP----------------------+ | | | V | | +---+------+ +---------+ | |<-------SIP-------------->| | | UA-A | (Communication Session) | UA-B | | (SRC) |<-------RTP-------------->| | +----------+ +---------+ Figure 4 +----------+ (Recording Session) | Session | +-----------SIP------------------------->|Recording | | | Server | | | (SRS) | V UA-A Session Recording Client (SRC) +----------+ +----------------------------------------+ ^ ^ | | | | | +-----------+ +------------+ |---RTP---+ | | | | Control | | | | | | UA | Protocol | Media | |---Metadata-+ | |Application|<-------->| Server | | +---------+ | | Server | | | | | | | | | | | |<----SIP----->| UA-B | | +-----------+ +------------+ |<----RTP----->| | | | +---------+ +----------------------------------------+ Figure 5 User 1 +-----------+ | | | | |Participant| | 1 | | | +-----------+ ^ ^ | | Dialog RTP SIP 1 | | User 2 V V Recording +-----------+ +-----------+ Session ************* | | | |<---SIP------>* * | |<---SIP--->| |----RTP 1 --->* * |Participant| | Focus/SRC |----RTP 2 --->* SRS * | 2 |<---RIP--->| |----RTP 3 --->* * | | Dialog | |--Metadata--->* * +-----------+ 2 +-----------+ ************* ^ ^ | | Dialog RTP SIP 3 | | V V +-----------+ | | | | |Participant| | 3 | | | +-----------+ User 3 Think green - keep it on the screen. This e-mail and any attachment is for = authorised use by the intended recipient(s) only. It may contain proprietar= y material, confidential information and/or be subject to legal privilege. = It should not be copied, disclosed to, retained or used by, any other party= . If you are not an intended recipient then please promptly delete this e-m= ail and any attachment and all copies and inform the sender. Thank you. --_000_07465C1D981ABC41A344374066AE1A2C39D32BD995TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Friso Hello

 

Thank you very much for comments.

 

1.&= nbsp;      Regarding showing RTP or RTP/R= TCP in the figures. This was one of the recent changes in order to show bes= t practice from MMUSIC to always support RTCP.

I think we should to show RTP/R= TCP on every figures. Or is it enough only to mention it in the text?<= /o:p>

&nb= sp;

2.       = RTP/RTCP direction. Th= is is very good point. RTP will be one direction (SRC to SRS) but RTCP is b= i-directional. So if we will user RTP/RTCP as one label, line should be bi-= directional as well. Any opinions?

3.     &n= bsp; Figure 4 is mistake, I will fix it.

4.  &nbs= p;    = Figure 5, I agree as well.<= /p>

 

Thank you for the= figure  proposals.

 

Any comments from the list?  Most important= is to finalize RTP or RTP/RTPC labels in the figures from my point of view= .

<= o:p> 

Regards

 

Leon

 

 

 

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org]= On Behalf Of Feenstra, Friso
Sent: Sunday, January 15, 20= 12 9:24 PM
To: siprec@ietf.org
Subject: [siprec] Drawin= gs in siprec-architecture-03

 

All,

 

I am visually oriented= and as such always look first at pictures and after that study the text. O= n the drawings in siprec-architecture-03 I have the following remarks.=

 <= /span>

1.  &n= bsp;    In some drawings for the voice stream the abbreviation= RTP is used, while for others the abbreviation RTP/RTCP is used. Is there = a reason for this, if not I would recommend to standardize on RTP.

2.  = ;     In figure 3, it is suggested that the RTP/RTCP stre= am flows from SRC to SRS and vice versa. Other figures suggest that the str= eam only flows from SRC to SRS.

3.       In figure 4= , it is suggested that the RTP stream flows from SRS to SRC and that the SI= P session is only established from SRC to SRS (and not vice versa)

4.  = ;     In figure 5, I would recommend to draw lines for bo= th SIP and RTP streams per dialog and indicate SIP for the top recording se= ssion connection.

 

 

Alternativ= es

 =

Figure 1

=  

            = ;            &n= bsp;            = ;         +-----------+<= /span>

  &nbs= p;            &= nbsp;          (Recording Sess= ion) |  Session  |

        &nb= sp;            =         +------SIP------>| Recording = |

&nb= sp;            =             &nb= sp;   |         &nbs= p;      |  Server   |

   = ;            &n= bsp;            = ; |  +---RTP------>|  (SRS)    |

   = ;            &n= bsp;            = ; |  |          &nbs= p;  +-----------+

         &nb= sp;            =        V  |     = ;            &n= bsp; ^

            &n= bsp;           | &nb= sp;           | &nbs= p;           |=

  &nb= sp;            =          |    &= nbsp;        |-- MetaData -+<= /span>

  &nbs= p;            &= nbsp;        |    &n= bsp;        |

     &= nbsp;           &nbs= p;      |    B2BUA   = ; |

&= nbsp;           &nbs= p;           |  = ;           |<= /span>

  &nbs= p;            &= nbsp;        |   Session =   |

     +--------+      =    |  Recording  |      &= nbsp;  +---------+

     |     =    |<- SIP ->|   Client    |<- = SIP ->|         |

   = ;  |  UA-A  |        = ; |   (SRC)     |    &nbs= p;    |  UA-B   |

     | =        |<- RTP ->|   &nb= sp;         |<- RTP ->| =         |

     +--------= +         |    =          |    &= nbsp;    +---------+

       &n= bsp;            = ;    +-------------+

     |__________________= __________________________________|

       &n= bsp;            (Com= munication Session)

 

 

Figure 2

 

 
          (Recording Session)=
 +-----------+
     =
    +----------SIP------>|     &=
nbsp;     |
  &=
nbsp;      |  +-------RTP------>|  Se=
ssion  |
     &=
nbsp;   |  |        =
         | Recording |
         |  =
|            &n=
bsp;    |  Server   |
= 
         |  | +-- Metad=
ata -->|   (SRS)   |
&=
nbsp;        |  | |  &nbs=
p;            | =
;          |=

         |  | |&n=
bsp;            =
;  +-----------+
    =
;     |  | |
 &=
nbsp;       |  | |
         |  | |<=
/o:p>
         |=
  | |
<=
span lang=3DEN style=3D'font-size:8.0pt'>     &nbs=
p;   V  | |  (Communication Session)<=
/pre>
      +--+------+   &nb=
sp;            =
     +---------+
 &n=
bsp;    |         |&=
lt;-------SIP--------->|        =
 |
      |  UA-=
A   |          =
           |  UA-B&n=
bsp;  |
      |=
  (SRC)  |<-------RTP--------->|    &nb=
sp;    |
   &nb=
sp;  +---------+         =
            +-------=
--+
 
 
Figur=
e 3
 
 
&n=
bsp;            =
;            &n=
bsp;           Session Re=
cording Server (SRS)
    =
            &nb=
sp;            =
 +----------------------------------------+
&=
nbsp;           &nbs=
p;            &=
nbsp;    |        &n=
bsp;            =
;            &n=
bsp;      |
 &n=
bsp;        (Recording Session) |  =
+-----------+          +------=
------+ |
      &nbs=
p;   +------------SIP----|->|    &nbs=
p;      |       =
;   |          =
  | |
<=
span lang=3DEN style=3D'font-size:8.0pt'>     &nbs=
p;    |         =
;          |  | MediaCtrl=
 |MEDIACTRL |   Media    | |
          | &nbs=
p;            &=
nbsp;    |  |Application|<-------->|   =
Server   | |
   &nbs=
p;      |    +-----Metadata--->|=
  Server   |        =
  |  (Recorder)| |
  &nbs=
p;       |    |  &nb=
sp;           |  |&n=
bsp;          |  &nb=
sp;       |     &nbs=
p;      | |
 &n=
bsp;        |    | &=
nbsp;            |&n=
bsp; +-----------+          +-=
-----------+ |
     =
     |    |     =
;         |    =
            &nb=
sp;            =
 ^         |
          |  =
;  |           =
   +------------------------------|---------+
          | &n=
bsp;  |  +-----------------RTP----------------------+<=
/span>
         =
 |    |&nbs=
p; |
      &nbs=
p;   V    |  |
=
        +---+------+   &n=
bsp;            =
;          +---------+
        | &n=
bsp;        |<-------SIP-------------=
->|         |<=
/pre>
        |   UA-A&n=
bsp;  | (Communication Session)  |  UA-B   |<=
/o:p>
        =
|   (SRC)  |<--=
-----RTP-------------->|        =
 |
       =
 +----------+          &n=
bsp;            =
;   +---------+
 
 
Figure 4
<=
span lang=3DEN-GB> 
   =
            &nb=
sp;            =
            &nb=
sp;           +----------=
+
       &=
nbsp;         (Recording Session)&n=
bsp;            =
;   | Session  |
  &=
nbsp;        +-----------SIP------------=
------------->|Recording |
  &nb=
sp;        |    &nbs=
p;            &=
nbsp;            &nb=
sp;         |  Server&nbs=
p; |
      &nbs=
p;    |         =
;            &n=
bsp;            =
;      |   (SRS)  |
          =
 V  UA-A Session Recording Client (SRC)   +----------+<=
/o:p>
    +------------------------------=
----------+         ^  ^<=
/o:p>
    |     =
            &nb=
sp;            =
          |   &=
nbsp;     |  |
&nb=
sp;   |  +-----------+      &n=
bsp;   +------------+ |---RTP---+  |
=

    |  |      &nbs=
p;    | Control  |      &=
nbsp;     | |       =
     |
   =
 |  |    UA     | Protocol | &=
nbsp; Media    | |---Metadata-+
    |  |Application|<-------->|  Server&nb=
sp;   | |         &n=
bsp;    +---------+
 &nbs=
p;  |  |  Server   |     =
     |        &=
nbsp;   | |         =
     |         =
|
    |  |  &nb=
sp;        |    &nbs=
p;     |        =
;    | |<----SIP----->|  UA-B   |<=
/o:p>
    |  +-----------+ &nbs=
p;        +------------+ |<----RTP---=
-->|         |=

    |       =
            &nb=
sp;             =
;       |     &=
nbsp;        +---------+
    +----------------------------------------=
+
&n=
bsp;
 =
;
Figure 5
 =

 
  &n=
bsp;            =
;            &n=
bsp;    User 1
  &nb=
sp;            =
             +-=
----------+
=
     &nb=
sp;            =
          |   &=
nbsp;       |
&=
nbsp;           &nbs=
p;            &=
nbsp;  |           |=

       &=
nbsp;           &nbs=
p;        |Participant|
          &=
nbsp;           &nbs=
p;     |     1   &nb=
sp; |
      &nb=
sp;            =
         |    &=
nbsp;      |
 &=
nbsp;           &nbs=
p;            &=
nbsp; +-----------+
    &=
nbsp;           &nbs=
p;            &=
nbsp; ^     ^
  =
;            &n=
bsp;            &nbs=
p;   |     |
            =
         Dialog   RTP &nb=
sp; SIP
     &n=
bsp;            =
;      1      |  &nb=
sp;  |
    &nbs=
p;  User 2          =
        V     V =
;    Recording
  &nb=
sp; +-----------+         &nbs=
p; +-----------+  Session     *************
    |     &=
nbsp;     |       &n=
bsp;   |         &nb=
sp; |<---SIP------>*        &=
nbsp;  *
    |  =
;         |<---SIP--->| =
          |----RTP 1 --->*&=
nbsp;          *
    |Participant|    &n=
bsp;      | Focus/SRC |----RTP 2 --->* &nb=
sp;  SRS    *
  =
;  |     2     |<---RIP---&=
gt;|           |----RTP 3=
 --->*           *
    |    &nbs=
p;      |  Dialog   |  &n=
bsp;        |--Metadata--->* &nb=
sp;         *
    +-----------+    2   &=
nbsp;  +-----------+       &nb=
sp;      *************
            =
            &nb=
sp;      ^    ^
          &nbs=
p;            &=
nbsp;       |    |<=
/span>
         =
            Dialog&n=
bsp;  RTP  SIP
   &n=
bsp;            =
;        3     =
 |    |
   &nbs=
p;            &=
nbsp;           &nbs=
p;  V    V
  &n=
bsp;            =
;             +=
-----------+
     &n=
bsp;            =
;          |   =
        |
=
            &nb=
sp;            =
   |           =
|
       &=
nbsp;           &nbs=
p;        |Participant|
          &=
nbsp;           &nbs=
p;     |    3    &nb=
sp; |
      &nb=
sp;            =
         |    &=
nbsp;      |
 &=
nbsp;           &nbs=
p;            &=
nbsp; +-----------+
    &=
nbsp;           &nbs=
p;            &=
nbsp; User 3
 
 
 

Think green - keep it on the screen. This e-=
mail and any attachment is for authorised use by the intended recipient(s) =
only. It may contain proprietary material, confidential information and/or =
be subject to legal privilege. It should not be copied, disclosed to, retai=
ned or used by, any other party. If you are not an intended recipient then =
please promptly delete this e-mail and any attachment and all copies and in=
form the sender. Thank you.
= --_000_07465C1D981ABC41A344374066AE1A2C39D32BD995TLVMBX01nicec_-- From rmohanr@cisco.com Mon Jan 16 07:58:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD2C21F8607 for ; Mon, 16 Jan 2012 07:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bhp7uawEOCr for ; Mon, 16 Jan 2012 07:58:39 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4263921F8606 for ; Mon, 16 Jan 2012 07:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=16080; q=dns/txt; s=iport; t=1326729519; x=1327939119; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=oe/7f7Te+SdFs5+EwVWMn2APXSYLly3sR33kHXFzkAk=; b=RYEyDToOOv1AJyXdSaCj8D2w371j09NCdQR6MyWxIA0OlxTDv3xCDwMv K1+/43+YWwfJpgFWu3MWcpY84auGL9q+75C4sfThKIst0gOqDwE2eyGL9 IsO9vNquYMteUOHjDEy51q4QmohrKybOs8uWDRGHRzTFfNLTJjT8KJ4yF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIdIFE+rRDoH/2dsb2JhbABDrC6BC4EFgXIBAQEDARIBFAlOBwQCAQgRAQMBAQsGFwEGAUUDBggBAQQLCAgah1iXZwGeBohyAQQDBQ4BBQQBCwMENgEFUAEEBwELAQIBAQgBAQFMCkqBaCgEAgILAQkSFgEBAQKCR2MEiAgxnyE X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="25624191" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 16 Jan 2012 15:58:39 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0GFwTtA010561 for ; Mon, 16 Jan 2012 15:58:38 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jan 2012 21:28:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jan 2012 21:28:31 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0916956D@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD09169569@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Drawings in siprec-architecture-03 Thread-Index: AczTuzolh9BcrHB6TPqCGY6DSa9FCQAcCiWgAA7+OTAAAAXeEA== References: <07465C1D981ABC41A344374066AE1A2C39D32BD995@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD09169569@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 16 Jan 2012 15:58:33.0233 (UTC) FILETIME=[B2BCA810:01CCD467] Subject: Re: [siprec] Drawings in siprec-architecture-03 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, 16 Jan 2012 15:58:40 -0000 Hi Leon,=20 Please see inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Monday, January 16, 2012 2:25 PM > To: Feenstra, Friso; siprec@ietf.org > Subject: Re: [siprec] Drawings in siprec-architecture-03 >=20 > Friso Hello >=20 > Thank you very much for comments. >=20 > 1. Regarding showing RTP or RTP/RTCP in the figures. This was one of > the recent changes in order to show best practice from MMUSIC to = always > support RTCP. > I think we should to show RTP/RTCP on every figures. Or is it enough > only to mention it in the text? I don't see any issues in showing RTP/RTCP in the figures. Where ever = possible SRC can record RTCP >=20 > 2. RTP/RTCP direction. This is very good point. RTP will be one > direction (SRC to SRS) but RTCP is bi-directional. So if we will user > RTP/RTCP as one label, line should be bi-directional as well. Any > opinions? Yes. Make sense. RTCP should be bi-directional. Regards, Ram > 3. Figure 4 is mistake, I will fix it. > 4. Figure 5, I agree as well. >=20 > Thank you for the figure =A0proposals. >=20 > Any comments from the list? =A0Most important is to finalize RTP or > RTP/RTPC labels in the figures from my point of view. >=20 > Regards >=20 > Leon >=20 >=20 >=20 >=20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Feenstra, Friso > Sent: Sunday, January 15, 2012 9:24 PM > To: siprec@ietf.org > Subject: [siprec] Drawings in siprec-architecture-03 >=20 > All, >=20 > I am visually oriented and as such always look first at pictures and > after that study the text. On the drawings in siprec-architecture-03 I > have the following remarks. >=20 > 1. In some drawings for the voice stream the abbreviation RTP is used, > while for others the abbreviation RTP/RTCP is used. Is there a reason > for this, if not I would recommend to standardize on RTP. > 2. In figure 3, it is suggested that the RTP/RTCP stream flows from = SRC > to SRS and vice versa. Other figures suggest that the stream only = flows > from SRC to SRS. > 3. In figure 4, it is suggested that the RTP stream flows from SRS to > SRC and that the SIP session is only established from SRC to SRS (and > not vice versa) > 4. In figure 5, I would recommend to draw lines for both SIP and RTP > streams per dialog and indicate SIP for the top recording session > connection. >=20 >=20 > Alternatives >=20 > Figure 1 >=20 >=20 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = +-----------+ > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= (Recording Session) |=A0 Session=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 +------SIP------>| Recording | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = Server=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |=A0 +---RTP------>|=A0 (SRS)=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------+ > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 V=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^ > =A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+-------------+=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |-- MetaData -+ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0 B2BUA=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0 Session=A0=A0 | > =A0=A0=A0=A0 +--------+=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 Recording=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0 +---------+ > =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 |<- SIP ->|=A0=A0 Client=A0=A0=A0 = |<- SIP ->|=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0 |=A0 UA-A=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 = (SRC)=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 UA-B=A0=A0 | > =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 |<- RTP = ->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<- RTP = ->|=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0 +--------+=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 = +---------+ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = +-------------+ > =A0=A0=A0=A0 |____________________________________________________| > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = (Communication Session) >=20 >=20 > Figure 2 >=20 >=20 > =A0=A0=A0=A0=A0=A0=A0 =A0=A0(Recording Session) +-----------+ > =A0=A0=A0=A0=A0=A0=A0=A0 = +----------SIP------>|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +-------RTP------>|=A0 Session=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Recording | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 Server=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | +-- Metadata -->|=A0=A0 (SRS)=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------+ > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | | > =A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | | > =A0=A0=A0=A0=A0=A0=A0=A0 V=A0 | |=A0 (Communication Session) > =A0=A0=A0=A0=A0 = +--+------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = +---------+ > =A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 = =A0=A0=A0|<-------SIP--------->|=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0 |=A0 UA-A=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = UA-B=A0=A0 | > =A0=A0=A0=A0=A0 |=A0 (SRC)=A0 = |<-------RTP--------->|=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0 = +---------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = +---------+ >=20 >=20 > Figure 3 >=20 >=20 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Session Recording Server (SRS) > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 +---------------------------------------- > + > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 | > | > =A0=A0=A0=A0=A0=A0=A0=A0=A0 (Recording Session) |=A0 = +-----------+=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------+ > | > =A0=A0=A0=A0=A0 = =A0=A0=A0=A0+------------SIP----|->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > | > =A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | MediaCtrl = |MEDIACTRL |=A0=A0 Media=A0=A0=A0 | > | > =A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = |Application|<-------->|=A0=A0 Server=A0=A0 | > | > =A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 +-----Metadata--->|=A0 Server = =A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 (Recorder)| > | > =A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > | > =A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = +-----------+=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------+ > | > =A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 ^ > | > =A0=A0=A0=A0=A0=A0 =A0=A0=A0|=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = +------------------------------|--------- > + > =A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 |=A0 = +-----------------RTP----------------------+ > =A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 |=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0 V=A0=A0=A0 |=A0 | > =A0=A0=A0=A0=A0=A0=A0 = +---+------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 +---------+ > =A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |<-------SIP-------------->|=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0 |=A0=A0 UA-A=A0=A0 | (Communication Session)=A0 = |=A0 UA-B=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0 |=A0=A0 (SRC)=A0 = |<-------RTP-------------->|=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0 = +----------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 +---------+ >=20 >=20 > Figure 4 >=20 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 +----------+ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (Recording = Session)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Session=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = +-----------SIP------------------------->|Recording | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0 Server=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 (SRS)=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 V=A0 UA-A Session Recording Client = (SRC)=A0=A0 +----------+ > =A0=A0=A0 = +----------------------------------------+=A0=A0=A0=A0=A0=A0=A0=A0 ^=A0 = ^ > =A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0 | > =A0=A0=A0 |=A0 +-----------+=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------+ = |---RTP---+=A0 | > =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Control=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | |=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0| > =A0=A0=A0 |=A0 |=A0=A0=A0 UA=A0=A0=A0=A0 | Protocol |=A0=A0 = Media=A0=A0=A0 | |---Metadata-+ > =A0=A0=A0 |=A0 |Application|<-------->|=A0 Server=A0=A0=A0 | = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +---------+ > =A0=A0=A0 |=A0 |=A0 Server=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | = |<----SIP----->|=A0 UA-B=A0=A0 | > =A0=A0=A0 |=A0 +-----------+=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------+ = |<----RTP----->|=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 +---------+ > =A0=A0=A0 +----------------------------------------+ >=20 >=20 > Figure 5 >=20 >=20 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 User 1 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 +-----------+ > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0|Participant| > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0 1=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 +-----------+ > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 ^=A0=A0 =A0=A0^ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0=A0| > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Dialog=A0=A0 RTP =A0=A0SIP > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 1=A0 =A0=A0=A0=A0| =A0=A0=A0=A0| > =A0=A0=A0=A0=A0=A0 User = 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 V =A0=A0=A0=A0V=A0 = =A0=A0=A0Recording > =A0=A0=A0 +-----------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------+=A0 = Session=A0=A0=A0=A0 ************* > =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |<---SIP------>*=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * > =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |<---SIP--->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |----RTP 1 --->*=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0* > =A0=A0=A0 |Participant|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Focus/SRC = |----RTP 2 --->*=A0=A0=A0 SRS=A0=A0=A0 * > =A0=A0=A0 |=A0=A0=A0=A0 2=A0=A0=A0=A0 = |<---RIP--->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |----RTP 3 = --->*=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * > =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 Dialog=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |--Metadata--->*=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * > =A0=A0=A0 +-----------+=A0 =A0=A02 = =A0=A0=A0=A0=A0+-----------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ************* > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 ^=A0=A0=A0 ^ > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Dialog=A0=A0 RTP=A0 SIP > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 3=A0=A0=A0=A0=A0 |=A0 =A0=A0| > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 V =A0=A0=A0V > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 +-----------+ > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |Participant| > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0 3=A0=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 +-----------+ > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 User 3 >=20 >=20 >=20 >=20 > Think green - keep it on the screen. This e-mail and any attachment is > for authorised use by the intended recipient(s) only. It may contain > proprietary material, confidential information and/or be subject to > legal privilege. It should not be copied, disclosed to, retained or > used by, any other party. If you are not an intended recipient then > please promptly delete this e-mail and any attachment and all copies > and inform the sender. Thank you. From rmohanr@cisco.com Mon Jan 16 08:21:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF56721F8516 for ; Mon, 16 Jan 2012 08:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WbJwTGEQnFI for ; Mon, 16 Jan 2012 08:21:28 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id D5BB721F8487 for ; Mon, 16 Jan 2012 08:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=4071; q=dns/txt; s=iport; t=1326730887; x=1327940487; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=aXtQQoAXUiwz5T7IxFjdCaRcfNvlqPj60eaVfZmZcvk=; b=j1KFyLc1Tm+zTNmGtK0+4vyL7EHXjnZoUh47/3m7YoMyPhVc5tbvKzXV MnrA5nFh7pY3Zf2OoEUwvQmEA8zDlQwWTBc6lmR0+RFlJste+anrJSWSV nYJd3SwhaNeM+o3q2Tf9K0GHUJVaD9cytdgbkDtuF0tOY6tlQI7b8+KEs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAFtNFE9Io8UY/2dsb2JhbAA5CqwughCBcgEBAQMBEgEdTgcEAgEIEQQBAQsGFwEGAUUJCAIECwgIGodYl2sBngiIWlA2AQVQAQQHAQsBAgEBCAEBAQNJCkqBaCgEAgILAQkSFgEBAQKCR2MEiAgxnyE X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="3514138" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 16 Jan 2012 16:21:19 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0GGLIHY008678 for ; Mon, 16 Jan 2012 16:21:19 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jan 2012 21:51:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jan 2012 21:51:17 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0916957C@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD09169571@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] Thread-Index: AQHMy821FXG9hLEz0USKI87oImfqFpYFtG3QgAG4vPCAB8tCUIAAABdA References: <35BCE99A477D6A4986FB2216D8CF2CFD09169571@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 16 Jan 2012 16:21:19.0054 (UTC) FILETIME=[E0D466E0:01CCD46A] Subject: Re: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] 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, 16 Jan 2012 16:21:28 -0000 Hi Leon, Please see inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: Wednesday, January 11, 2012 10:39 PM > To: Leon Portman; siprec@ietf.org > Subject: Re: [siprec] Start & stop time for CS [was RE: IETF 82 > Minutes.] >=20 > Leon, >=20 > In case media level, it is possible to find the start/stop time using > participantstream association or SDP attribute change for a specific > stream. In case of participant to CS, association & disassociation > attribute helps to identify how long participant is associated with CS > during the recording. >=20 > Please read inline for more comments. >=20 > Thanks > Partha >=20 > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Tuesday, January 10, 2012 8:16 PM > To: Ravindran, Parthasarathi; siprec@ietf.org > Subject: RE: Start & stop time for CS [was RE: IETF 82 Minutes.] >=20 > First couple of comments: > 1. We need it also on the media level - for example when video or text > sharing started/ended and not only complete CS=20 I suppose you are asking for the times a media stream started / ended. = The information on when a video/text/audio has started can be known at a = participant level in the current model. In other words the = participantStreamAssoc element has associate/dis-associate time which = represents the times a participant starts/stops contributing to a = stream. IMO this is sufficient. What that does not cover is if you have a stream for which there are no = associated participants and still want to track start/stop. My question = is - Is there a need to know start/stop time for a stream for which = there are no associated participants ? Any use-case you have in mind for = such a thing ? > 2. Same for participants - joining/leaving CS The information on when a participant joins/leaves session is included = in participantCSAssociation element. Associate-time - associate-time is calculated by SRC as the time it sees = a participant is associated to CS Disassociate-time- Disassociate-time is calculated by SRC as the time it = see a participant disassociate from a CS. >=20 > For the scenarios where RS covers on part of CS - like record on > demand, how SRS will know when CS have started? I agree this could be one use-case where we need CS start time. As = partha mentioned for cases where SRC has knowledge of the CS start-time = it can convey the same. The challenge I see is CS is a logical and may = comprises of several SIP dialogs. In such cases what does start/stop = means ?=20 Regards, Ram > SRC has to maintain the dialog history information like Call > Detail records (CDR) then only, this requirement will be solved. This > requirement is not required to be mandated in all SRC >=20 > It is import from compliance recording point of view to indicate that > RS does not cover complete CS. > Could you please provide the name of compliance which mandate > CS start/stop time >=20 > Hope it helps >=20 > Leon >=20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: Thursday, January 05, 2012 7:16 PM > To: siprec@ietf.org > Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] >=20 > Hi all, >=20 > Associate/disassociate time helps to understand how long CS is > associated with RS. Initial association time shall be considered=A0 as > start time and final disassociation time shall be considered as stop > time. As we could not conclude this open item during IETF-82, I'm > starting this mail thread for discussion. >=20 > I could not see any other strong reason for having start/stop time for > CS apart from associate/disassociate time. Please provide usecase for > including start/stop time attribute in CS. >=20 > In case we could not see the proper usecase, it is better to remove > from metadata draft. >=20 > Thanks > Partha From Leon.Portman@nice.com Tue Jan 17 01:01:27 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4916121F847C for ; Tue, 17 Jan 2012 01:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 i-TENVM8eDJP for ; Tue, 17 Jan 2012 01:01:23 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 862B721F8468 for ; Tue, 17 Jan 2012 01:01:18 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 17 Jan 2012 11:01:16 +0200 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Tue, 17 Jan 2012 11:01:15 +0200 Thread-Topic: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] Thread-Index: AQHMy821FXG9hLEz0USKI87oImfqFpYFtG3QgAG4vPCAB8tCUIAAABdAgAEEXKA= Message-ID: <07465C1D981ABC41A344374066AE1A2C39D32BDF2C@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD09169571@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD0916957C@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD0916957C@XMB-BGL-417.cisco.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] 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, 17 Jan 2012 09:01:27 -0000 Ram Hi I am ok with the below regarding media and participant times.=20 Regarding local CS with multiple SIP sessions: it is depends on SRC logic -= may be start of first SIP dialog? Regards Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Monday, January 16, 2012 6:21 PM To: siprec@ietf.org Subject: Re: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] Hi Leon, Please see inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ravindran, Parthasarathi > Sent: Wednesday, January 11, 2012 10:39 PM > To: Leon Portman; siprec@ietf.org > Subject: Re: [siprec] Start & stop time for CS [was RE: IETF 82=20 > Minutes.] >=20 > Leon, >=20 > In case media level, it is possible to find the start/stop time using=20 > participantstream association or SDP attribute change for a specific=20 > stream. In case of participant to CS, association & disassociation=20 > attribute helps to identify how long participant is associated with CS=20 > during the recording. >=20 > Please read inline for more comments. >=20 > Thanks > Partha >=20 > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Tuesday, January 10, 2012 8:16 PM > To: Ravindran, Parthasarathi; siprec@ietf.org > Subject: RE: Start & stop time for CS [was RE: IETF 82 Minutes.] >=20 > First couple of comments: > 1. We need it also on the media level - for example when video or text=20 > sharing started/ended and not only complete CS I suppose you are asking for the times a media stream started / ended. The = information on when a video/text/audio has started can be known at a partic= ipant level in the current model. In other words the participantStreamAssoc= element has associate/dis-associate time which represents the times a part= icipant starts/stops contributing to a stream. IMO this is sufficient. What that does not cover is if you have a stream for which there are no ass= ociated participants and still want to track start/stop. My question is - I= s there a need to know start/stop time for a stream for which there are no = associated participants ? Any use-case you have in mind for such a thing ? > 2. Same for participants - joining/leaving CS The information on when a participant joins/leaves session is included in p= articipantCSAssociation element. Associate-time - associate-time is calculated by SRC as the time it sees a = participant is associated to CS Disassociate-time- Disassociate-time is calculated by SRC as the time it se= e a participant disassociate from a CS. >=20 > For the scenarios where RS covers on part of CS - like record on=20 > demand, how SRS will know when CS have started? I agree this could be one use-case where we need CS start time. As partha m= entioned for cases where SRC has knowledge of the CS start-time it can conv= ey the same. The challenge I see is CS is a logical and may comprises of se= veral SIP dialogs. In such cases what does start/stop means ?=20 Regards, Ram > SRC has to maintain the dialog history information like Call=20 > Detail records (CDR) then only, this requirement will be solved. This=20 > requirement is not required to be mandated in all SRC >=20 > It is import from compliance recording point of view to indicate that=20 > RS does not cover complete CS. > Could you please provide the name of compliance which mandate=20 > CS start/stop time >=20 > Hope it helps >=20 > Leon >=20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ravindran, Parthasarathi > Sent: Thursday, January 05, 2012 7:16 PM > To: siprec@ietf.org > Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.] >=20 > Hi all, >=20 > Associate/disassociate time helps to understand how long CS is=20 > associated with RS. Initial association time shall be considered=A0 as=20 > start time and final disassociation time shall be considered as stop=20 > time. As we could not conclude this open item during IETF-82, I'm=20 > starting this mail thread for discussion. >=20 > I could not see any other strong reason for having start/stop time for=20 > CS apart from associate/disassociate time. Please provide usecase for=20 > including start/stop time attribute in CS. >=20 > In case we could not see the proper usecase, it is better to remove=20 > from metadata draft. >=20 > Thanks > Partha _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From trac+siprec@trac.tools.ietf.org Thu Jan 19 04:04:00 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B77821F8623 for ; Thu, 19 Jan 2012 04:04:00 -0800 (PST) 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=[AWL=0.000, 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 2V-zAOOJenlD for ; Thu, 19 Jan 2012 04:04:00 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1921F8621 for ; Thu, 19 Jan 2012 04:03:59 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RnqiU-00047q-DN; Thu, 19 Jan 2012 07:03:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-siprec-protocol@tools.ietf.org, andrew.hutton@siemens-enterprise.com X-Trac-Project: siprec Date: Thu, 19 Jan 2012 12:03:41 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/82 Message-ID: <077.45a92b02c410d1c02070ca65d37bd2cc@trac.tools.ietf.org> X-Trac-Ticket-ID: 82 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-siprec-protocol@tools.ietf.org, andrew.hutton@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120119120400.02E1921F8621@ietfa.amsl.com> Resent-Date: Thu, 19 Jan 2012 04:03:59 -0800 (PST) Resent-From: trac+siprec@trac.tools.ietf.org Cc: siprec@ietf.org Subject: [siprec] #82: Support for RTP/RTCP Mux (RFC 5761) in SIPREC 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, 19 Jan 2012 12:04:00 -0000 #82: Support for RTP/RTCP Mux (RFC 5761) in SIPREC IETF82 presentation on protocol draft concluded that we need more discussion on what if anything to say about RFC 5761 support in SIPREC. -- -----------------------------+------------------------------------------ Reporter: andrew.hutton@… | Owner: draft-ietf-siprec-protocol@… Type: task | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------+------------------------------------------ Ticket URL: siprec From andrew.hutton@siemens-enterprise.com Thu Jan 19 04:10:20 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CD521F8645 for ; Thu, 19 Jan 2012 04:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 1VEoQr7hFNcn for ; Thu, 19 Jan 2012 04:10:19 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id BBCD221F8646 for ; Thu, 19 Jan 2012 04:10:18 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id BAEB223F05AF; Thu, 19 Jan 2012 13:10:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 19 Jan 2012 13:10:08 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Paul Kyzivat Date: Thu, 19 Jan 2012 13:10:06 +0100 Thread-Topic: [siprec] Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpswAFMHoA//+pN4D//0dmIIABG7MA//+jjoD//0SQEP/n2lCg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31200586D10@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net> <4F04A7E3.5060104@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com> <4F04FB04.9000203@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C01DC3BB3@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC3BB3@inba-mail01.sonusnet.com> 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 Cc: "siprec@ietf.org" Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 19 Jan 2012 12:10:20 -0000 Hi All, I am still of the view that we should not mandate support or the use of RFC= 5761 in SIPREC. Obviously in scenarios where there are a large number of recording sessions= between the SRC and SRS it may make sense to make use of this that is the = case for any scenario in which there are a large number of active sessions.= We should not burden all SIPREC implementation with having to implement RF= C 5761. I would be happy for the architecture draft to provide a hint towards using= RFC 5761 but don't think it needs to be mentioned in the protocol draft. Regards Andy (As an individual). -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ravindran, Parthasarathi Sent: 05 January 2012 01:34 To: Paul Kyzivat Cc: siprec@ietf.org Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC Correction - "Optional to support" instead "optional to use"=20 >-----Original Message----- >From: Ravindran, Parthasarathi >Sent: Thursday, January 05, 2012 7:00 AM >To: 'Paul Kyzivat' >Cc: siprec@ietf.org >Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC > >Paul, > >We are in the same page for having two port allocation for RTCP when the >offer is sent by SRC/SRS and make it to single port after the >negotiation is done with answer. These kind of SIPREC implementation is >inline with any other RFC 5761 implementation. Please let me know >whether it is fine to make RFC 5761 as optional to support for SIPREC. > >Thanks >Partha > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>Sent: Thursday, January 05, 2012 6:51 AM >>To: Ravindran, Parthasarathi >>Cc: siprec@ietf.org >>Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC >> >>On 1/4/12 8:02 PM, Ravindran, Parthasarathi wrote: >>> Paul, >>> >>> My understanding about rtcp-mux (RFC5761) attribute is optional to >>> support in SIPREC as per Sec 5.1.1 of RFC 5761 statement >>> >>> " If the answer does not contain an "a=3Drtcp-mux" attribute, the >>offerer >>> MUST NOT multiplex RTP and RTCP packets on a single port. >>Instead, >>> it should send and receive RTCP on a port allocated according to >>the >>> usual port-selection rules (either the port pair, or a signalled >>port >>> if the "a=3Drtcp:" attribute [10] is also included). This will >>occur >>> when talking to a peer that does not understand the "a=3Drtcp-mux" >>> attribute." >> >>> Here in case SRS does not support RFC 5761, the answer to SRC will >>> not >>have "a=3Drtcp-mux" and SRC will fallback as per RFC suggestion. >> >>This implies that the offerer must reserve a port on which to receive >>rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp-mux >>is accepted it can free up that port. >> >>And even though RTP is one-way for siprec, the RTCP is two-way, so this >>can't be avoided for siprec. >> >> Thanks, >> Paul >> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Thursday, January 05, 2012 12:56 AM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC >>>> >>>> On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: >>>>> Hi Andy, >>>>> >>>>> I agree with you, and I do not see a need for us to make RFC 5761 >>>>> RTP& RTCP multiplexing MANDATORY. There is currently no >>>>> recommendation for it in draft-eckelcu-siprec-rtp-rec. It is >>>>> mentioned only to differentiate it from symmetric RTP/RTCP, which >>>>> is MANDATORY when >>>> sending RTP/RTCP. >>>> >>>> I agree it probably doesn't make sense to make it mandatory, nor to >>>> ban it. So from a spec perspective it may not be necessary to >>>> mention it at all. >>>> >>>> But given that there might be a large number of streams, it could be >>>> desirable to use. I guess the question would be whether we want to >>>> make it mandatory to support but optional to use. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Hutton, Andrew >>>>>> Sent: Wednesday, January 04, 2012 8:38 AM >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC >>>>>> >>>>>> Hi, >>>>>> >>>>>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) and >>>>>> whether what we should say about this in the SIPREC protocol draft >>>>>> the conclusion was that this could be supported but we needed to >>>>>> confirm this. >>>>>> >>>>>> I am not sure we really need to say anything about this in the >>>>> protocol >>>>>> draft since support for it would of course be optional like many >>>>>> other SDP attributes and I don't see any specific relevant to >>>>>> SIPREC other than it being useful in reducing the number of ports >>>>>> used at the SRS and SRC. >>>>>> >>>>>> I think it would be ok for the protocol draft to say that support >>>>>> for this would be a good idea but don't think we should make it >>>> mandatory. >>>>>> >>>>>> Any comments? >>>>>> >>>>>> Regards >>>>>> Andy >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Thu Jan 19 08:48:05 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8D321F8608 for ; Thu, 19 Jan 2012 08:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.306 X-Spam-Level: X-Spam-Status: No, score=-6.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KAQtEwdxJeQ for ; Thu, 19 Jan 2012 08:48:04 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E220521F8634 for ; Thu, 19 Jan 2012 08:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7484; q=dns/txt; s=iport; t=1326991684; x=1328201284; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RNl9RgoTqeyb6dvZgJ2RHREZFkkvxuTYvCr7jwpZNZc=; b=BPGyL8PejZKQzZSGaWPk4rnmzsyrqO9X/r4cSjokwoVD+1QwnW6LcCcX +ChvcOzyZRqYFpIz3E88Nd+Y618u+mzIAqrlktmoxsUwjCoM4SW4HLIMY QRe7CCIr2XHCsINaiDZSuO2ldGVDINGp+Fnp9zoV4y7uI25m35SRistJA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAB9JGE+rRDoH/2dsb2JhbABEDqxRgQCBBYFyAQEBAwEBAQEPAR0KNAsFBwQCAQgRAQMBAQEKBhcBBgEmHwMGCAIEARIIGodaCJpAAZ5aBIk3MwIBAUICAgQBAwcBAQMNAQIDAQIBAQgBAQFADAoaMIFoVxYBAQECgkdjBIg7nm9Y X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="26217811" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 19 Jan 2012 16:47:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0JGlwug031868; Thu, 19 Jan 2012 16:47:58 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 08:47:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jan 2012 08:47:55 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31200586D10@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpswAFMHoA//+pN4D//0dmIIABG7MA//+jjoD//0SQEP/n2lCg/89q2WA= References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net><4F04A7E3.5060104@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com><4F04FB04.9000203@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C01DC3BB3@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31200586D10@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "Ravindran, Parthasarathi" , "Paul Kyzivat" X-OriginalArrivalTime: 19 Jan 2012 16:47:58.0527 (UTC) FILETIME=[196DDCF0:01CCD6CA] Cc: siprec@ietf.org Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 19 Jan 2012 16:48:06 -0000 I mostly agree, in that I do not believe we should mandate RFC 5761, nor do I think there is a real need to call it out explicitly in the protocol in the draft. It is mentioned in draft-eckel-siprec-rtp-rec-03 only for the purpose of differentiating it from symmetric RTP and symmetric RTCP, which are required. To me this means that, as with many other things, support for RFC 5761 RTP/RTCP multiplexing is optional, and there is nothing we need to say about it explicitly. However, my feeling is that if we were to decide to add a hint at RFC 5761 RTP/RTCP multiplexing in the architecture draft, then we actually do need to deal with it in the protocol draft, and therefore in draft-eckel-siprec-rtp-rec. It that point, I still feel we should not make it required, but we could make it recommended. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Thursday, January 19, 2012 4:10 AM > To: Ravindran, Parthasarathi; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC >=20 > Hi All, >=20 > I am still of the view that we should not mandate support or the use of > RFC 5761 in SIPREC. >=20 > Obviously in scenarios where there are a large number of recording > sessions between the SRC and SRS it may make sense to make use of this > that is the case for any scenario in which there are a large number of > active sessions. We should not burden all SIPREC implementation with > having to implement RFC 5761. >=20 > I would be happy for the architecture draft to provide a hint towards > using RFC 5761 but don't think it needs to be mentioned in the protocol > draft. >=20 > Regards > Andy (As an individual). >=20 >=20 >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: 05 January 2012 01:34 > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC >=20 > Correction - "Optional to support" instead "optional to use" >=20 > >-----Original Message----- > >From: Ravindran, Parthasarathi > >Sent: Thursday, January 05, 2012 7:00 AM > >To: 'Paul Kyzivat' > >Cc: siprec@ietf.org > >Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC > > > >Paul, > > > >We are in the same page for having two port allocation for RTCP when > the > >offer is sent by SRC/SRS and make it to single port after the > >negotiation is done with answer. These kind of SIPREC implementation > is > >inline with any other RFC 5761 implementation. Please let me know > >whether it is fine to make RFC 5761 as optional to support for SIPREC. > > > >Thanks > >Partha > > > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>Sent: Thursday, January 05, 2012 6:51 AM > >>To: Ravindran, Parthasarathi > >>Cc: siprec@ietf.org > >>Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC > >> > >>On 1/4/12 8:02 PM, Ravindran, Parthasarathi wrote: > >>> Paul, > >>> > >>> My understanding about rtcp-mux (RFC5761) attribute is optional to > >>> support in SIPREC as per Sec 5.1.1 of RFC 5761 statement > >>> > >>> " If the answer does not contain an "a=3Drtcp-mux" attribute, the > >>offerer > >>> MUST NOT multiplex RTP and RTCP packets on a single port. > >>Instead, > >>> it should send and receive RTCP on a port allocated according > to > >>the > >>> usual port-selection rules (either the port pair, or a > signalled > >>port > >>> if the "a=3Drtcp:" attribute [10] is also included). This = will > >>occur > >>> when talking to a peer that does not understand the "a=3Drtcp- > mux" > >>> attribute." > >> > >>> Here in case SRS does not support RFC 5761, the answer to SRC will > >>> not > >>have "a=3Drtcp-mux" and SRC will fallback as per RFC suggestion. > >> > >>This implies that the offerer must reserve a port on which to receive > >>rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp- > mux > >>is accepted it can free up that port. > >> > >>And even though RTP is one-way for siprec, the RTCP is two-way, so > this > >>can't be avoided for siprec. > >> > >> Thanks, > >> Paul > >> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Thursday, January 05, 2012 12:56 AM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC > >>>> > >>>> On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: > >>>>> Hi Andy, > >>>>> > >>>>> I agree with you, and I do not see a need for us to make RFC 5761 > >>>>> RTP& RTCP multiplexing MANDATORY. There is currently no > >>>>> recommendation for it in draft-eckelcu-siprec-rtp-rec. It is > >>>>> mentioned only to differentiate it from symmetric RTP/RTCP, which > >>>>> is MANDATORY when > >>>> sending RTP/RTCP. > >>>> > >>>> I agree it probably doesn't make sense to make it mandatory, nor > to > >>>> ban it. So from a spec perspective it may not be necessary to > >>>> mention it at all. > >>>> > >>>> But given that there might be a large number of streams, it could > be > >>>> desirable to use. I guess the question would be whether we want to > >>>> make it mandatory to support but optional to use. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Cheers, > >>>>> Charles > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>>>>> Behalf Of Hutton, Andrew > >>>>>> Sent: Wednesday, January 04, 2012 8:38 AM > >>>>>> To: siprec@ietf.org > >>>>>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) > and > >>>>>> whether what we should say about this in the SIPREC protocol > draft > >>>>>> the conclusion was that this could be supported but we needed to > >>>>>> confirm this. > >>>>>> > >>>>>> I am not sure we really need to say anything about this in the > >>>>> protocol > >>>>>> draft since support for it would of course be optional like many > >>>>>> other SDP attributes and I don't see any specific relevant to > >>>>>> SIPREC other than it being useful in reducing the number of > ports > >>>>>> used at the SRS and SRC. > >>>>>> > >>>>>> I think it would be ok for the protocol draft to say that > support > >>>>>> for this would be a good idea but don't think we should make it > >>>> mandatory. > >>>>>> > >>>>>> Any comments? > >>>>>> > >>>>>> Regards > >>>>>> Andy > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>> > >>>> > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>> >=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 andrew.hutton@siemens-enterprise.com Thu Jan 19 10:52:23 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E621F84B9 for ; Thu, 19 Jan 2012 10:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 K2+bYKS0w+z6 for ; Thu, 19 Jan 2012 10:52:22 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8E621F845C for ; Thu, 19 Jan 2012 10:52:22 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A05B41EB84DE for ; Thu, 19 Jan 2012 19:52:20 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 19 Jan 2012 19:52:20 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Thu, 19 Jan 2012 19:52:19 +0100 Thread-Topic: [siprec] Transport of snapshot request Thread-Index: AcyxGxzXGIYdGDtlTJKb6K2UVf17Vgltcoug Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31200587082@MCHP058A.global-ad.net> References: <6ACE27C1-E11E-4137-A0E9-81BDF6C0E524@gmail.com><622B0E14298DDE47ACA9E16B292F22A40F2F7EB2@Mail1.acmepacket.com><387F9047F55E8C42850AD6B3A7A03C6C01D9D17E@inba-mail02.sonusnet.com><4ED6EAA3.6060708@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Transport of snapshot request 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, 19 Jan 2012 18:52:23 -0000 Hi All, So let me try to summarize where we are on transporting the snapshot reques= t and the resulting metadata snapshot and give my own view on this. It seems that at least a couple of people (Paul & John) proposing that we n= eed to keep the snapshot request and the resulting snapshot separated in di= fferent transactions and I also think that would be a good idea.=20 We should however make sure we support the case when there is no metadata p= rovided via an XML body in which case I can see that a reINVITE without SDP= is effectively a snapshot request and must be supported but that is just b= asic SIP and maybe we just don't call this a snapshot request at all. Assuming we agree on the different transaction model then I see no benefit = to including the snapshot request in a reINVITE in fact it would be quite m= essy to do so given that the response would have to include an SDP offer an= d so would most likely the resulting snapshot itself. This would be a mess = so let's mandate that the snapshot request is made in an UPDATE request. The resulting snapshot which includes an SDP offer plus metadata could then= be included in either a reINVITE or an UPDATE. I am not sure there is much= benefit in mandating that this is always in an UPDATE because an SRS is al= most certainly going to support sending a reINVITE with metadata anyway but= we could. So in summary my thinking is: 1. An explicit snapshot request MUST be in an UPDATE without SDP. 2. The snaphot MUST be in either an UPDATE or a reINVITE both of which MUST= have SDP. I would be ok with mandating it be only in an UPDATE but I think= it is not necessary. 3. The SRS MAY generate a reINVITE without SDP but this MUST not include a = snapshot request. Regards Andy -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= John Elwell Sent: 02 December 2011 17:52 To: Hadriel Kaplan; Paul Kyzivat Cc: siprec@ietf.org Subject: Re: [siprec] Transport of snapshot request I am happy with the notion of keeping options to a minimum. However, I=20 prefer to decouple the snapshot request and the snapshot into different=20 transactions (rather like SUBSCRIBE and NOTIFY). The snapshot itself can=20 then be done the same way as any metadata update (except we might choose to= =20 mandate that a snapshot be accompanied by an SDP offer, even though a=20 regular update might be with or without an SDP offer). So a simple approach= =20 might be: - UPDATE request (without SDP offer) for snapshot request; - UPDATE request (with/without SDP offer) for metadata update or snapshot. John ----- Original Message -----=20 From: "Hadriel Kaplan" To: "Paul Kyzivat" Cc: Sent: Thursday, December 01, 2011 3:28 PM Subject: Re: [siprec] Transport of snapshot request > > The reason to "exclude" anything is to improve interoperability. I've=20 > seen countless issues with implementations not expecting another device t= o=20 > do something causing problems when the other device does it, and=20 > definitely for re-INVITEs and UPDATE scenarios. > > So unless there's some pressing need to support multiple possible=20 > scenarios, I don't see any reason not to just pick one and only one way t= o=20 > do something - it will improve interop to do so. > > If we think a snapshot request from the SRS will usually need SDP from th= e=20 > SRC, and we don't think the SRS can provide an SDP offer in the snapshot= =20 > request - and I don't think the SRS can in fact always provide an SDP=20 > offer in it because the whole reason it's asking for a snapshot is it=20 > forgot stuff - then we should pick a way to do it without requiring the=20 > SRS to send an SDP offer. > > Ergo, I vote we pick the snapshot request mechanism be an offerless=20 > re-INVITE, period. That will work in every scenario anyone has ever=20 > mentioned, afaict, and thus there's no reason to do anything else. No? > > -hadriel > > > On Nov 30, 2011, at 9:46 PM, Paul Kyzivat wrote: > >> On 12/1/11 8:47 AM, Ravindran, Parthasarathi wrote: >>> Hi all, >>> >>> I agree with UPDATE without SDP based snapshot request in case there is >>> an agreement that SRS will never generate offer as there is no=20 >>> possibility >>> of offer-answer race condition based on snapshot request mechanism. So, >>> I'm interested in hearing everybody opinion on "no offer from SRS"=20 >>> stance >>> For SIPREC. >> >> I don't see how it would ever make sense for the SRS to make an offer to= =20 >> the SRC, so I'm fine with declaring that invalid SRS behavior. >> >> As far as a snapshot without SDP, I agree it is unlikely that a snapshot= =20 >> would not require an SDP update. But I see no reason to exclude it in th= e=20 >> unlikely event that a case comes up when it is valid. >> >> This would be a problem if a snapshot request was in an UPDATE without=20 >> SDP and the snapshot was required to be in the reply. But as long as the= =20 >> SRC can wait and send the snapshot in a request it initiates, it can mak= e=20 >> any offer it needs to, or potentially it could do the snapshot in an=20 >> UPDATE without SDP if no SDP was needed. >> >> Thanks, >> Paul >> >>> Brad/John, >>> >>> Please read inline. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>> Behalf >>>> Of Brad Winslow >>>> Sent: Wednesday, November 23, 2011 10:23 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Transport of snapshot request >>>> >>>> Hi Folks, >>>> >>>> In the situation where the SRS needs a metadata update, it most likely >>>> will need an SDP update, as there is no guarantee the metadata-only >>>> update would be consistent with the current SDP label attributes of th= e >>>> SRS, aren't we asking for trouble if we allow a metadata-only update? >>> Snapshot request UPDATE without SDP from SRS is used to=20 >>> trigger >>> Metadata request in SRC using RE-INVITE or UPDATE method >>> >>> >>>> If we decide on a full update, metadata + SDP, should we settle on >>>> UPDATE or INVITE to transmit the update from SRC to SRS? >>> We have common understanding here >>> >>>> >>>> As an aside, there is an expectation that the SRC behaves as a SIP UA, >>>> in this case it should be able to respond to an offer-less re-INVITE >>>> from the SRS and provide metadata and SDP in the response. >>>> >>> offerless Re-INVITE with 100 + 200 response is currently=20 >>> considered >>> as alternative Proposal to UPDATE without SDP snapshot request >>> >>>> Finally, if the SRS receives an INVITE for a new recording session, >>>> should we have an error code response which indicates the SRS is not >>>> interested in recording the session, not as a failure status, just as = a >>>> status to terminate the recording. >>> >>> It will be negative response in case INVITE with=20 >>> require:siprec is >>> not accepted using 200 OK right? Do we need the new server negative 5xx >>> response code for this policy decision? >>> >>> This presupposes the SRS may make >>>> policy decisions for recording. >>>> >>>> Thanks in advance for your thoughts, >>>> Brad >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>> Behalf >>>> Of Leon Portman >>>> Sent: Thursday, November 17, 2011 4:47 AM >>>> To: John Elwell >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Transport of snapshot request >>>> >>>> John, Nice to have you back on the list. >>>> >>>> Actually discussion during IETF meeting was started to converge to >>>> similar as you describe below. >>>> >>>> Regards >>>> >>>> Leon >>>> >>>> On Nov 17, 2011, at 5:15 PM, John Elwell wrote: >>>> >>>>> There has been a long thread discussing the SIP messages for snapshot >>>> requests. >>>>> >>>>> First, I see no reason to tie the snapshot request and the metadata >>>> transmission to the same transaction (request/response). If they are >>>> tied together, this imposes unnecessary time and architectural >>>> constraints on the SRC. >>> >>> The model proposed is request/provisional response/response >>> Wherein RE-INVITE/100/200 trying shall be used wherein there is no >>> Immediate response to SRS. >>> >>> I much prefer an approach similar to the >>>> subscribe/notify approach of RFC 3265 - use different transactions. >>> >>> The downside of this approach is 4 SIP messages per every >>> Service. I'm seeing the middle ground of offerless RE-INVITE with >>> Provisional response (100) and final response wherein 3 messages are >>> Involved but there is no extra offer/answer race condition from SRS. >>> >>> Having said that, in case it is confirmed that SRS will never offer >>> Then I'm fine with UPDATE based snapshot request >>> >>> I am >>>> rather unsympathetic to allowing, as an option, metadata transmission= =20 >>>> in >>>> a response. Apart from the timing and architectural concerns, there is >>>> no means of responding to a response if anything is wrong. Keep it >>>> simple, and allow metadata transmission only in requests, as in NOTIFY= . >>>>> >>>>> Second, I think it is an SRC decision whether it needs a further >>>> offer-answer exchange. When sending the request containing the=20 >>>> metadata, >>>> the SRC must ensure that any references to media description labels ar= e >>>> consistent with the last SDP sent by the SRC - if not, the SRC can >>>> initiate a further offer-answer exchange at the same time as the >>>> metadata transmission. >>>>> >>>>> Perhaps it is my imagination, but I thought we had on the table at on= e >>>> time the notion of: >>>>> - SRS sends snapshot request in an UPDATE request. >>>>> - SRC sends medata in an UPDATE request (with offer if it needs to >>>> change SDP, otherwise without). >>>>> >>>>> I have lost track of how we came to diverge from this simple model. >>>>> >>>>> John >>>>> >>>>> _______________________________________________ >>>>> 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 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Thu Jan 19 11:07:14 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3221F84A2 for ; Thu, 19 Jan 2012 11:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 Awdp6CfkXlHZ for ; Thu, 19 Jan 2012 11:07:13 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3EE21F849D for ; Thu, 19 Jan 2012 11:07:12 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id D8A4623F0544; Thu, 19 Jan 2012 20:07:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 19 Jan 2012 20:07:09 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , "Ravindran, Parthasarathi" , Paul Kyzivat Date: Thu, 19 Jan 2012 20:07:08 +0100 Thread-Topic: [siprec] Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpswAFMHoA//+pN4D//0dmIIABG7MA//+jjoD//0SQEP/n2lCg/89q2WD/nqlHYA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31200587097@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net><4F04A7E3.5060104@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com><4F04FB04.9000203@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C01DC3BB3@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31200586D10@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 19 Jan 2012 19:07:14 -0000 Hi Charles, I was forgetting that your RTP stuff will go in to the protocol draft I am = ok with the text in your draft. A hint in the architecture draft just to make people think about the possib= ility would be good enough for me but I would also be happy if we said noth= ing at all about RFC 5761 in the architecture draft. I don't see the value in making it recommended. Regards Andy =20 -----Original Message----- From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 Sent: 19 January 2012 16:48 To: Hutton, Andrew; Ravindran, Parthasarathi; Paul Kyzivat Cc: siprec@ietf.org Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC I mostly agree, in that I do not believe we should mandate RFC 5761, nor do I think there is a real need to call it out explicitly in the protocol in the draft. It is mentioned in draft-eckel-siprec-rtp-rec-03 only for the purpose of differentiating it from symmetric RTP and symmetric RTCP, which are required. To me this means that, as with many other things, support for RFC 5761 RTP/RTCP multiplexing is optional, and there is nothing we need to say about it explicitly. However, my feeling is that if we were to decide to add a hint at RFC 5761 RTP/RTCP multiplexing in the architecture draft, then we actually do need to deal with it in the protocol draft, and therefore in draft-eckel-siprec-rtp-rec. It that point, I still feel we should not make it required, but we could make it recommended. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Thursday, January 19, 2012 4:10 AM > To: Ravindran, Parthasarathi; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC >=20 > Hi All, >=20 > I am still of the view that we should not mandate support or the use of > RFC 5761 in SIPREC. >=20 > Obviously in scenarios where there are a large number of recording > sessions between the SRC and SRS it may make sense to make use of this > that is the case for any scenario in which there are a large number of > active sessions. We should not burden all SIPREC implementation with > having to implement RFC 5761. >=20 > I would be happy for the architecture draft to provide a hint towards > using RFC 5761 but don't think it needs to be mentioned in the protocol > draft. >=20 > Regards > Andy (As an individual). >=20 >=20 >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: 05 January 2012 01:34 > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC >=20 > Correction - "Optional to support" instead "optional to use" >=20 > >-----Original Message----- > >From: Ravindran, Parthasarathi > >Sent: Thursday, January 05, 2012 7:00 AM > >To: 'Paul Kyzivat' > >Cc: siprec@ietf.org > >Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC > > > >Paul, > > > >We are in the same page for having two port allocation for RTCP when > the > >offer is sent by SRC/SRS and make it to single port after the > >negotiation is done with answer. These kind of SIPREC implementation > is > >inline with any other RFC 5761 implementation. Please let me know > >whether it is fine to make RFC 5761 as optional to support for SIPREC. > > > >Thanks > >Partha > > > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>Sent: Thursday, January 05, 2012 6:51 AM > >>To: Ravindran, Parthasarathi > >>Cc: siprec@ietf.org > >>Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC > >> > >>On 1/4/12 8:02 PM, Ravindran, Parthasarathi wrote: > >>> Paul, > >>> > >>> My understanding about rtcp-mux (RFC5761) attribute is optional to > >>> support in SIPREC as per Sec 5.1.1 of RFC 5761 statement > >>> > >>> " If the answer does not contain an "a=3Drtcp-mux" attribute, the > >>offerer > >>> MUST NOT multiplex RTP and RTCP packets on a single port. > >>Instead, > >>> it should send and receive RTCP on a port allocated according > to > >>the > >>> usual port-selection rules (either the port pair, or a > signalled > >>port > >>> if the "a=3Drtcp:" attribute [10] is also included). This will > >>occur > >>> when talking to a peer that does not understand the "a=3Drtcp- > mux" > >>> attribute." > >> > >>> Here in case SRS does not support RFC 5761, the answer to SRC will > >>> not > >>have "a=3Drtcp-mux" and SRC will fallback as per RFC suggestion. > >> > >>This implies that the offerer must reserve a port on which to receive > >>rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp- > mux > >>is accepted it can free up that port. > >> > >>And even though RTP is one-way for siprec, the RTCP is two-way, so > this > >>can't be avoided for siprec. > >> > >> Thanks, > >> Paul > >> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Thursday, January 05, 2012 12:56 AM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC > >>>> > >>>> On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: > >>>>> Hi Andy, > >>>>> > >>>>> I agree with you, and I do not see a need for us to make RFC 5761 > >>>>> RTP& RTCP multiplexing MANDATORY. There is currently no > >>>>> recommendation for it in draft-eckelcu-siprec-rtp-rec. It is > >>>>> mentioned only to differentiate it from symmetric RTP/RTCP, which > >>>>> is MANDATORY when > >>>> sending RTP/RTCP. > >>>> > >>>> I agree it probably doesn't make sense to make it mandatory, nor > to > >>>> ban it. So from a spec perspective it may not be necessary to > >>>> mention it at all. > >>>> > >>>> But given that there might be a large number of streams, it could > be > >>>> desirable to use. I guess the question would be whether we want to > >>>> make it mandatory to support but optional to use. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Cheers, > >>>>> Charles > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>>>>> Behalf Of Hutton, Andrew > >>>>>> Sent: Wednesday, January 04, 2012 8:38 AM > >>>>>> To: siprec@ietf.org > >>>>>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) > and > >>>>>> whether what we should say about this in the SIPREC protocol > draft > >>>>>> the conclusion was that this could be supported but we needed to > >>>>>> confirm this. > >>>>>> > >>>>>> I am not sure we really need to say anything about this in the > >>>>> protocol > >>>>>> draft since support for it would of course be optional like many > >>>>>> other SDP attributes and I don't see any specific relevant to > >>>>>> SIPREC other than it being useful in reducing the number of > ports > >>>>>> used at the SRS and SRC. > >>>>>> > >>>>>> I think it would be ok for the protocol draft to say that > support > >>>>>> for this would be a good idea but don't think we should make it > >>>> mandatory. > >>>>>> > >>>>>> Any comments? > >>>>>> > >>>>>> Regards > >>>>>> Andy > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>> > >>>> > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>> >=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 Jan 19 11:43:35 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10FF21F85AC for ; Thu, 19 Jan 2012 11:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcJX0iRW0jkc for ; Thu, 19 Jan 2012 11:43:34 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8C51021F85A4 for ; Thu, 19 Jan 2012 11:43:34 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id PTJq1i00327AodY57Xjbl0; Thu, 19 Jan 2012 19:43:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id PXja1i01B07duvL3fXjaeb; Thu, 19 Jan 2012 19:43:34 +0000 Message-ID: <4F187264.6080802@alum.mit.edu> Date: Thu, 19 Jan 2012 14:43:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net><4F04A7E3.5060104@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com><4F04FB04.9000203@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C01DC3BB3@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31200586D10@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31200587097@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31200587097@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 19 Jan 2012 19:43:35 -0000 RECOMMENDED is the same as SHOULD. And so, if we were to use it then should specify the criteria for doing it or not. Without anything like that it is not especially useful. We have more important fish to fry, so I'm ok with doing nothing. Thanks, Paul On 1/19/12 2:07 PM, Hutton, Andrew wrote: > Hi Charles, > > I was forgetting that your RTP stuff will go in to the protocol draft I am ok with the text in your draft. > > A hint in the architecture draft just to make people think about the possibility would be good enough for me but I would also be happy if we said nothing at all about RFC 5761 in the architecture draft. > > I don't see the value in making it recommended. > > Regards > Andy > > > > > > > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 19 January 2012 16:48 > To: Hutton, Andrew; Ravindran, Parthasarathi; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] Multiplexing RTP& RTCP in SIPREC > > I mostly agree, in that I do not believe we should mandate RFC 5761, nor > do I think there is a real need to call it out explicitly in the > protocol in the draft. It is mentioned in draft-eckel-siprec-rtp-rec-03 > only for the purpose of differentiating it from symmetric RTP and > symmetric RTCP, which are required. To me this means that, as with many > other things, support for RFC 5761 RTP/RTCP multiplexing is optional, > and there is nothing we need to say about it explicitly. > However, my feeling is that if we were to decide to add a hint at RFC > 5761 RTP/RTCP multiplexing in the architecture draft, then we actually > do need to deal with it in the protocol draft, and therefore in > draft-eckel-siprec-rtp-rec. It that point, I still feel we should not > make it required, but we could make it recommended. > > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Thursday, January 19, 2012 4:10 AM >> To: Ravindran, Parthasarathi; Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC >> >> Hi All, >> >> I am still of the view that we should not mandate support or the use > of >> RFC 5761 in SIPREC. >> >> Obviously in scenarios where there are a large number of recording >> sessions between the SRC and SRS it may make sense to make use of this >> that is the case for any scenario in which there are a large number of >> active sessions. We should not burden all SIPREC implementation with >> having to implement RFC 5761. >> >> I would be happy for the architecture draft to provide a hint towards >> using RFC 5761 but don't think it needs to be mentioned in the > protocol >> draft. >> >> Regards >> Andy (As an individual). >> >> >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: 05 January 2012 01:34 >> To: Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC >> >> Correction - "Optional to support" instead "optional to use" >> >>> -----Original Message----- >>> From: Ravindran, Parthasarathi >>> Sent: Thursday, January 05, 2012 7:00 AM >>> To: 'Paul Kyzivat' >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] Multiplexing RTP& RTCP in SIPREC >>> >>> Paul, >>> >>> We are in the same page for having two port allocation for RTCP when >> the >>> offer is sent by SRC/SRS and make it to single port after the >>> negotiation is done with answer. These kind of SIPREC implementation >> is >>> inline with any other RFC 5761 implementation. Please let me know >>> whether it is fine to make RFC 5761 as optional to support for > SIPREC. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, January 05, 2012 6:51 AM >>>> To: Ravindran, Parthasarathi >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC >>>> >>>> On 1/4/12 8:02 PM, Ravindran, Parthasarathi wrote: >>>>> Paul, >>>>> >>>>> My understanding about rtcp-mux (RFC5761) attribute is optional to >>>>> support in SIPREC as per Sec 5.1.1 of RFC 5761 statement >>>>> >>>>> " If the answer does not contain an "a=rtcp-mux" attribute, the >>>> offerer >>>>> MUST NOT multiplex RTP and RTCP packets on a single port. >>>> Instead, >>>>> it should send and receive RTCP on a port allocated according >> to >>>> the >>>>> usual port-selection rules (either the port pair, or a >> signalled >>>> port >>>>> if the "a=rtcp:" attribute [10] is also included). This will >>>> occur >>>>> when talking to a peer that does not understand the "a=rtcp- >> mux" >>>>> attribute." >>>> >>>>> Here in case SRS does not support RFC 5761, the answer to SRC will >>>>> not >>>> have "a=rtcp-mux" and SRC will fallback as per RFC suggestion. >>>> >>>> This implies that the offerer must reserve a port on which to > receive >>>> rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp- >> mux >>>> is accepted it can free up that port. >>>> >>>> And even though RTP is one-way for siprec, the RTCP is two-way, so >> this >>>> can't be avoided for siprec. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Thanks >>>>> Partha >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Thursday, January 05, 2012 12:56 AM >>>>>> To: siprec@ietf.org >>>>>> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC >>>>>> >>>>>> On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: >>>>>>> Hi Andy, >>>>>>> >>>>>>> I agree with you, and I do not see a need for us to make RFC > 5761 >>>>>>> RTP& RTCP multiplexing MANDATORY. There is currently no >>>>>>> recommendation for it in draft-eckelcu-siprec-rtp-rec. It is >>>>>>> mentioned only to differentiate it from symmetric RTP/RTCP, > which >>>>>>> is MANDATORY when >>>>>> sending RTP/RTCP. >>>>>> >>>>>> I agree it probably doesn't make sense to make it mandatory, nor >> to >>>>>> ban it. So from a spec perspective it may not be necessary to >>>>>> mention it at all. >>>>>> >>>>>> But given that there might be a large number of streams, it could >> be >>>>>> desirable to use. I guess the question would be whether we want > to >>>>>> make it mandatory to support but optional to use. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Cheers, >>>>>>> Charles >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >>>>>>>> Behalf Of Hutton, Andrew >>>>>>>> Sent: Wednesday, January 04, 2012 8:38 AM >>>>>>>> To: siprec@ietf.org >>>>>>>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) >> and >>>>>>>> whether what we should say about this in the SIPREC protocol >> draft >>>>>>>> the conclusion was that this could be supported but we needed > to >>>>>>>> confirm this. >>>>>>>> >>>>>>>> I am not sure we really need to say anything about this in the >>>>>>> protocol >>>>>>>> draft since support for it would of course be optional like > many >>>>>>>> other SDP attributes and I don't see any specific relevant to >>>>>>>> SIPREC other than it being useful in reducing the number of >> ports >>>>>>>> used at the SRS and SRC. >>>>>>>> >>>>>>>> I think it would be ok for the protocol draft to say that >> support >>>>>>>> for this would be a good idea but don't think we should make it >>>>>> mandatory. >>>>>>>> >>>>>>>> Any comments? >>>>>>>> >>>>>>>> Regards >>>>>>>> Andy >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >> >> _______________________________________________ >> 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 Jan 20 09:25:14 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1009E21F8681 for ; Fri, 20 Jan 2012 09:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 UvBiThyF1lvd for ; Fri, 20 Jan 2012 09:25:13 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF3621F867B for ; Fri, 20 Jan 2012 09:25:13 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id B665E1EB8456 for ; Fri, 20 Jan 2012 18:25:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 20 Jan 2012 18:25:09 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 20 Jan 2012 18:25:08 +0100 Thread-Topic: No SIPREC Meeting in Boston. Thread-Index: AczXmHUn2mX2TqoFQaq0kXZoSijr1Q== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312005EEB31@MCHP058A.global-ad.net> 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 Subject: [siprec] No SIPREC Meeting in Boston. 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, 20 Jan 2012 17:25:14 -0000 Hi All, There will be no February SIPREC meeting in Boston. After chasing a few people to see who would attend I came to the conclusion= there is not enough support for a face to face meeting in Boston be it an = official interim or a more informal design team meeting. There is however a desire to get things moving forward at a bit of a quicke= r pace so we need to discuss ways of doing that. Suggestions are most welco= me. In the first instance let's get some productive discussion going on the lis= t and get in good shape for IETF83 in March it looks like we should have a = good attendance of working group members in Paris. Regards Andy From Henry.Lum@alcatel-lucent.com Fri Jan 20 17:58:06 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF8E21F8644 for ; Fri, 20 Jan 2012 17:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=2.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 XfH0eFNJexZN for ; Fri, 20 Jan 2012 17:58:05 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BFBDE21F8648 for ; Fri, 20 Jan 2012 17:58:05 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0L1w3IY021526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2012 19:58:03 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0L1w1bp030949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jan 2012 19:58:02 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id q0L1vxOT024105; Fri, 20 Jan 2012 17:57:59 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 17:57:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2012 17:57:56 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74080A8C60@NAHALD.us.int.genesyslab.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31200587097@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Multiplexing RTP & RTCP in SIPREC Thread-Index: AczK/0mJUUTq/QDrSNy9JKqecfCpswAFMHoA//+pN4D//0dmIIABG7MA//+jjoD//0SQEP/n2lCg/89q2WD/nqlHYP87S1vQ References: <101C6067BEC68246B0C3F6843BCCC1E311FD92E6BD@MCHP058A.global-ad.net><4F04A7E3.5060104@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C01DC3B6F@inba-mail01.sonusnet.com><4F04FB04.9000203@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C01DC3BB3@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31200586D10@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31200587097@MCHP058A.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , "Charles Eckel (eckelcu)" , "Ravindran, Parthasarathi" , "Paul Kyzivat" X-OriginalArrivalTime: 21 Jan 2012 01:57:59.0505 (UTC) FILETIME=[19F53C10:01CCD7E0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: siprec@ietf.org Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC 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, 21 Jan 2012 01:58:06 -0000 I tend to agree that we should leave it alone and not mention it in the protocol draft. Mentioning it to the protocol draft implies that multiplexing becomes mandatory to support, which I don't think it is the intention here. Regards, Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: January-19-12 2:07 PM > To: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC >=20 > Hi Charles, >=20 > I was forgetting that your RTP stuff will go in to the protocol draft I > am ok with the text in your draft. >=20 > A hint in the architecture draft just to make people think about the > possibility would be good enough for me but I would also be happy if we > said nothing at all about RFC 5761 in the architecture draft. >=20 > I don't see the value in making it recommended. >=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 19 January 2012 16:48 > To: Hutton, Andrew; Ravindran, Parthasarathi; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC >=20 > I mostly agree, in that I do not believe we should mandate RFC 5761, > nor > do I think there is a real need to call it out explicitly in the > protocol in the draft. It is mentioned in draft-eckel-siprec-rtp-rec-03 > only for the purpose of differentiating it from symmetric RTP and > symmetric RTCP, which are required. To me this means that, as with many > other things, support for RFC 5761 RTP/RTCP multiplexing is optional, > and there is nothing we need to say about it explicitly. > However, my feeling is that if we were to decide to add a hint at RFC > 5761 RTP/RTCP multiplexing in the architecture draft, then we actually > do need to deal with it in the protocol draft, and therefore in > draft-eckel-siprec-rtp-rec. It that point, I still feel we should not > make it required, but we could make it recommended. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Thursday, January 19, 2012 4:10 AM > > To: Ravindran, Parthasarathi; Paul Kyzivat > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC > > > > Hi All, > > > > I am still of the view that we should not mandate support or the use > of > > RFC 5761 in SIPREC. > > > > Obviously in scenarios where there are a large number of recording > > sessions between the SRC and SRS it may make sense to make use of > this > > that is the case for any scenario in which there are a large number > of > > active sessions. We should not burden all SIPREC implementation with > > having to implement RFC 5761. > > > > I would be happy for the architecture draft to provide a hint towards > > using RFC 5761 but don't think it needs to be mentioned in the > protocol > > draft. > > > > Regards > > Andy (As an individual). > > > > > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ravindran, Parthasarathi > > Sent: 05 January 2012 01:34 > > To: Paul Kyzivat > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC > > > > Correction - "Optional to support" instead "optional to use" > > > > >-----Original Message----- > > >From: Ravindran, Parthasarathi > > >Sent: Thursday, January 05, 2012 7:00 AM > > >To: 'Paul Kyzivat' > > >Cc: siprec@ietf.org > > >Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC > > > > > >Paul, > > > > > >We are in the same page for having two port allocation for RTCP when > > the > > >offer is sent by SRC/SRS and make it to single port after the > > >negotiation is done with answer. These kind of SIPREC implementation > > is > > >inline with any other RFC 5761 implementation. Please let me know > > >whether it is fine to make RFC 5761 as optional to support for > SIPREC. > > > > > >Thanks > > >Partha > > > > > >>-----Original Message----- > > >>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > >>Sent: Thursday, January 05, 2012 6:51 AM > > >>To: Ravindran, Parthasarathi > > >>Cc: siprec@ietf.org > > >>Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC > > >> > > >>On 1/4/12 8:02 PM, Ravindran, Parthasarathi wrote: > > >>> Paul, > > >>> > > >>> My understanding about rtcp-mux (RFC5761) attribute is optional > to > > >>> support in SIPREC as per Sec 5.1.1 of RFC 5761 statement > > >>> > > >>> " If the answer does not contain an "a=3Drtcp-mux" attribute, the= > > >>offerer > > >>> MUST NOT multiplex RTP and RTCP packets on a single port. > > >>Instead, > > >>> it should send and receive RTCP on a port allocated according > > to > > >>the > > >>> usual port-selection rules (either the port pair, or a > > signalled > > >>port > > >>> if the "a=3Drtcp:" attribute [10] is also included). This will > > >>occur > > >>> when talking to a peer that does not understand the "a=3Drtcp= - > > mux" > > >>> attribute." > > >> > > >>> Here in case SRS does not support RFC 5761, the answer to SRC > will > > >>> not > > >>have "a=3Drtcp-mux" and SRC will fallback as per RFC suggestion. > > >> > > >>This implies that the offerer must reserve a port on which to > receive > > >>rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp- > > mux > > >>is accepted it can free up that port. > > >> > > >>And even though RTP is one-way for siprec, the RTCP is two-way, so > > this > > >>can't be avoided for siprec. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Thanks > > >>> Partha > > >>> > > >>>> -----Original Message----- > > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > >>>> Behalf Of Paul Kyzivat > > >>>> Sent: Thursday, January 05, 2012 12:56 AM > > >>>> To: siprec@ietf.org > > >>>> Subject: Re: [siprec] Multiplexing RTP& RTCP in SIPREC > > >>>> > > >>>> On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote: > > >>>>> Hi Andy, > > >>>>> > > >>>>> I agree with you, and I do not see a need for us to make RFC > 5761 > > >>>>> RTP& RTCP multiplexing MANDATORY. There is currently no > > >>>>> recommendation for it in draft-eckelcu-siprec-rtp-rec. It is > > >>>>> mentioned only to differentiate it from symmetric RTP/RTCP, > which > > >>>>> is MANDATORY when > > >>>> sending RTP/RTCP. > > >>>> > > >>>> I agree it probably doesn't make sense to make it mandatory, nor > > to > > >>>> ban it. So from a spec perspective it may not be necessary to > > >>>> mention it at all. > > >>>> > > >>>> But given that there might be a large number of streams, it > could > > be > > >>>> desirable to use. I guess the question would be whether we want > to > > >>>> make it mandatory to support but optional to use. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>>> Cheers, > > >>>>> Charles > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > > On > > >>>>>> Behalf Of Hutton, Andrew > > >>>>>> Sent: Wednesday, January 04, 2012 8:38 AM > > >>>>>> To: siprec@ietf.org > > >>>>>> Subject: [siprec] Multiplexing RTP& RTCP in SIPREC > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> During IETF82 we discussed RTP& RTCP Multiplexing (RFC 5761) > > and > > >>>>>> whether what we should say about this in the SIPREC protocol > > draft > > >>>>>> the conclusion was that this could be supported but we needed > to > > >>>>>> confirm this. > > >>>>>> > > >>>>>> I am not sure we really need to say anything about this in the > > >>>>> protocol > > >>>>>> draft since support for it would of course be optional like > many > > >>>>>> other SDP attributes and I don't see any specific relevant to > > >>>>>> SIPREC other than it being useful in reducing the number of > > ports > > >>>>>> used at the SRS and SRC. > > >>>>>> > > >>>>>> I think it would be ok for the protocol draft to say that > > support > > >>>>>> for this would be a good idea but don't think we should make > it > > >>>> mandatory. > > >>>>>> > > >>>>>> Any comments? > > >>>>>> > > >>>>>> Regards > > >>>>>> Andy > > >>>>>> > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> siprec mailing list > > >>>>> siprec@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> siprec mailing list > > >>>> siprec@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/siprec > > >>> > > > > _______________________________________________ > > 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 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From Henry.Lum@alcatel-lucent.com Fri Jan 20 19:16:06 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4772D21F86CF for ; Fri, 20 Jan 2012 19:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVBNpyZclxtL for ; Fri, 20 Jan 2012 19:16:05 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EEE1D21F86D6 for ; Fri, 20 Jan 2012 19:16:04 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q0L3G3tn028958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2012 21:16:03 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0L3G1Op011450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jan 2012 21:16:03 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id q0L3G1hP000063; Fri, 20 Jan 2012 19:16:01 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 19:16:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2012 19:16:00 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74080A8C65@NAHALD.us.int.genesyslab.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31200587082@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Transport of snapshot request Thread-Index: AcyxGxzXGIYdGDtlTJKb6K2UVf17VgltcougAEZAx7A= References: <6ACE27C1-E11E-4137-A0E9-81BDF6C0E524@gmail.com><622B0E14298DDE47ACA9E16B292F22A40F2F7EB2@Mail1.acmepacket.com><387F9047F55E8C42850AD6B3A7A03C6C01D9D17E@inba-mail02.sonusnet.com><4ED6EAA3.6060708@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31200587082@MCHP058A.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , X-OriginalArrivalTime: 21 Jan 2012 03:16:01.0084 (UTC) FILETIME=[00657FC0:01CCD7EB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [siprec] Transport of snapshot request 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, 21 Jan 2012 03:16:06 -0000 I agree on keeping the snapshot request and the snapshot as separate transactions which is the main point of this issue. The resulting 3 items below to me are basically the mechanism of mandating the snapshot request and snapshot as separate transactions, which I also agree is a reasonable and simple mechanism. =20 Thanks Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: January-19-12 1:52 PM > To: siprec@ietf.org > Subject: Re: [siprec] Transport of snapshot request >=20 > Hi All, >=20 > So let me try to summarize where we are on transporting the snapshot > request and the resulting metadata snapshot and give my own view on > this. >=20 > It seems that at least a couple of people (Paul & John) proposing that > we need to keep the snapshot request and the resulting snapshot > separated in different transactions and I also think that would be a > good idea. >=20 > We should however make sure we support the case when there is no > metadata provided via an XML body in which case I can see that a > reINVITE without SDP is effectively a snapshot request and must be > supported but that is just basic SIP and maybe we just don't call this > a snapshot request at all. >=20 > Assuming we agree on the different transaction model then I see no > benefit to including the snapshot request in a reINVITE in fact it > would be quite messy to do so given that the response would have to > include an SDP offer and so would most likely the resulting snapshot > itself. This would be a mess so let's mandate that the snapshot request > is made in an UPDATE request. >=20 > The resulting snapshot which includes an SDP offer plus metadata could > then be included in either a reINVITE or an UPDATE. I am not sure there > is much benefit in mandating that this is always in an UPDATE because > an SRS is almost certainly going to support sending a reINVITE with > metadata anyway but we could. >=20 > So in summary my thinking is: >=20 > 1. An explicit snapshot request MUST be in an UPDATE without SDP. >=20 > 2. The snaphot MUST be in either an UPDATE or a reINVITE both of which > MUST have SDP. I would be ok with mandating it be only in an UPDATE but > I think it is not necessary. >=20 > 3. The SRS MAY generate a reINVITE without SDP but this MUST not > include a snapshot request. >=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of John Elwell > Sent: 02 December 2011 17:52 > To: Hadriel Kaplan; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Transport of snapshot request >=20 > I am happy with the notion of keeping options to a minimum. However, I > prefer to decouple the snapshot request and the snapshot into different > transactions (rather like SUBSCRIBE and NOTIFY). The snapshot itself > can > then be done the same way as any metadata update (except we might > choose to > mandate that a snapshot be accompanied by an SDP offer, even though a > regular update might be with or without an SDP offer). So a simple > approach > might be: > - UPDATE request (without SDP offer) for snapshot request; > - UPDATE request (with/without SDP offer) for metadata update or > snapshot. >=20 > John >=20 > ----- Original Message ----- > From: "Hadriel Kaplan" > To: "Paul Kyzivat" > Cc: > Sent: Thursday, December 01, 2011 3:28 PM > Subject: Re: [siprec] Transport of snapshot request >=20 >=20 > > > > The reason to "exclude" anything is to improve interoperability. > I've > > seen countless issues with implementations not expecting another > device to > > do something causing problems when the other device does it, and > > definitely for re-INVITEs and UPDATE scenarios. > > > > So unless there's some pressing need to support multiple possible > > scenarios, I don't see any reason not to just pick one and only one > way to > > do something - it will improve interop to do so. > > > > If we think a snapshot request from the SRS will usually need SDP > from the > > SRC, and we don't think the SRS can provide an SDP offer in the > snapshot > > request - and I don't think the SRS can in fact always provide an SDP > > offer in it because the whole reason it's asking for a snapshot is it > > forgot stuff - then we should pick a way to do it without requiring > the > > SRS to send an SDP offer. > > > > Ergo, I vote we pick the snapshot request mechanism be an offerless > > re-INVITE, period. That will work in every scenario anyone has ever > > mentioned, afaict, and thus there's no reason to do anything else. > No? > > > > -hadriel > > > > > > On Nov 30, 2011, at 9:46 PM, Paul Kyzivat wrote: > > > >> On 12/1/11 8:47 AM, Ravindran, Parthasarathi wrote: > >>> Hi all, > >>> > >>> I agree with UPDATE without SDP based snapshot request in case > there is > >>> an agreement that SRS will never generate offer as there is no > >>> possibility > >>> of offer-answer race condition based on snapshot request mechanism. > So, > >>> I'm interested in hearing everybody opinion on "no offer from SRS" > >>> stance > >>> For SIPREC. > >> > >> I don't see how it would ever make sense for the SRS to make an > offer to > >> the SRC, so I'm fine with declaring that invalid SRS behavior. > >> > >> As far as a snapshot without SDP, I agree it is unlikely that a > snapshot > >> would not require an SDP update. But I see no reason to exclude it > in the > >> unlikely event that a case comes up when it is valid. > >> > >> This would be a problem if a snapshot request was in an UPDATE > without > >> SDP and the snapshot was required to be in the reply. But as long as > the > >> SRC can wait and send the snapshot in a request it initiates, it can > make > >> any offer it needs to, or potentially it could do the snapshot in an > >> UPDATE without SDP if no SDP was needed. > >> > >> Thanks, > >> Paul > >> > >>> Brad/John, > >>> > >>> Please read inline. > >>> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf > >>>> Of Brad Winslow > >>>> Sent: Wednesday, November 23, 2011 10:23 PM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] Transport of snapshot request > >>>> > >>>> Hi Folks, > >>>> > >>>> In the situation where the SRS needs a metadata update, it most > likely > >>>> will need an SDP update, as there is no guarantee the metadata- > only > >>>> update would be consistent with the current SDP label attributes > of the > >>>> SRS, aren't we asking for trouble if we allow a metadata-only > update? > >>> Snapshot request UPDATE without SDP from SRS is used to > >>> trigger > >>> Metadata request in SRC using RE-INVITE or UPDATE method > >>> > >>> > >>>> If we decide on a full update, metadata + SDP, should we settle on > >>>> UPDATE or INVITE to transmit the update from SRC to SRS? > >>> We have common understanding here > >>> > >>>> > >>>> As an aside, there is an expectation that the SRC behaves as a SIP > UA, > >>>> in this case it should be able to respond to an offer-less re- > INVITE > >>>> from the SRS and provide metadata and SDP in the response. > >>>> > >>> offerless Re-INVITE with 100 + 200 response is currently > >>> considered > >>> as alternative Proposal to UPDATE without SDP snapshot > request > >>> > >>>> Finally, if the SRS receives an INVITE for a new recording > session, > >>>> should we have an error code response which indicates the SRS is > not > >>>> interested in recording the session, not as a failure status, just > as a > >>>> status to terminate the recording. > >>> > >>> It will be negative response in case INVITE with > >>> require:siprec is > >>> not accepted using 200 OK right? Do we need the new server negative > 5xx > >>> response code for this policy decision? > >>> > >>> This presupposes the SRS may make > >>>> policy decisions for recording. > >>>> > >>>> Thanks in advance for your thoughts, > >>>> Brad > >>>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf > >>>> Of Leon Portman > >>>> Sent: Thursday, November 17, 2011 4:47 AM > >>>> To: John Elwell > >>>> Cc: siprec@ietf.org > >>>> Subject: Re: [siprec] Transport of snapshot request > >>>> > >>>> John, Nice to have you back on the list. > >>>> > >>>> Actually discussion during IETF meeting was started to converge to > >>>> similar as you describe below. > >>>> > >>>> Regards > >>>> > >>>> Leon > >>>> > >>>> On Nov 17, 2011, at 5:15 PM, John Elwell wrote: > >>>> > >>>>> There has been a long thread discussing the SIP messages for > snapshot > >>>> requests. > >>>>> > >>>>> First, I see no reason to tie the snapshot request and the > metadata > >>>> transmission to the same transaction (request/response). If they > are > >>>> tied together, this imposes unnecessary time and architectural > >>>> constraints on the SRC. > >>> > >>> The model proposed is request/provisional > response/response > >>> Wherein RE-INVITE/100/200 trying shall be used wherein there is no > >>> Immediate response to SRS. > >>> > >>> I much prefer an approach similar to the > >>>> subscribe/notify approach of RFC 3265 - use different > transactions. > >>> > >>> The downside of this approach is 4 SIP messages per every > >>> Service. I'm seeing the middle ground of offerless RE-INVITE with > >>> Provisional response (100) and final response wherein 3 messages > are > >>> Involved but there is no extra offer/answer race condition from > SRS. > >>> > >>> Having said that, in case it is confirmed that SRS will never offer > >>> Then I'm fine with UPDATE based snapshot request > >>> > >>> I am > >>>> rather unsympathetic to allowing, as an option, metadata > transmission > >>>> in > >>>> a response. Apart from the timing and architectural concerns, > there is > >>>> no means of responding to a response if anything is wrong. Keep it > >>>> simple, and allow metadata transmission only in requests, as in > NOTIFY. > >>>>> > >>>>> Second, I think it is an SRC decision whether it needs a further > >>>> offer-answer exchange. When sending the request containing the > >>>> metadata, > >>>> the SRC must ensure that any references to media description > labels are > >>>> consistent with the last SDP sent by the SRC - if not, the SRC can > >>>> initiate a further offer-answer exchange at the same time as the > >>>> metadata transmission. > >>>>> > >>>>> Perhaps it is my imagination, but I thought we had on the table > at one > >>>> time the notion of: > >>>>> - SRS sends snapshot request in an UPDATE request. > >>>>> - SRC sends medata in an UPDATE request (with offer if it needs > to > >>>> change SDP, otherwise without). > >>>>> > >>>>> I have lost track of how we came to diverge from this simple > model. > >>>>> > >>>>> John > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > _______________________________________________ > 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 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From rmohanr@cisco.com Sun Jan 22 20:25:43 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1769921F85F7 for ; Sun, 22 Jan 2012 20:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 NtpJRo8xoMSK for ; Sun, 22 Jan 2012 20:25:42 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id E788A21F85F6 for ; Sun, 22 Jan 2012 20:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1311; q=dns/txt; s=iport; t=1327292742; x=1328502342; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=mg9OF4Rss/0FWNmFtVic4hBbD3tjVJtxGePd8Mf0wEI=; b=YzlVbQiUB3Kh/DtsbV2ekCpshOqPVutyaHIY/bPI3K+BxFqOSgTVZ9yV kFF023PCmHjQxlDGrvaRchOqSm4Gge/8AbyFEsdhctFZ7Hdr/s8wGFyzL LulQb+o7tPsTIXib3uPYe8aXMBai2jOvfID7qJ29XYO5xyvVO5VKx9rz9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAHrgHE9Io8UY/2dsb2JhbABDryqBcgEBAQQBAQEPAR0KNBcEAgEIEQQBAQsGFwEGASYfCQgBAQQBCggIGodimisBnV0Ei0NjBIg5nzY X-IronPort-AV: E=Sophos;i="4.71,553,1320624000"; d="scan'208";a="3941969" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 23 Jan 2012 04:25:40 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0N4Pen2015518; Mon, 23 Jan 2012 04:25:40 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 09:55:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jan 2012 09:55:37 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0929B2C5@XMB-BGL-417.cisco.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312005EEB31@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] No SIPREC Meeting in Boston. Thread-Index: AczXmHUn2mX2TqoFQaq0kXZoSijr1QB7hfpw References: <101C6067BEC68246B0C3F6843BCCC1E312005EEB31@MCHP058A.global-ad.net> From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , X-OriginalArrivalTime: 23 Jan 2012 04:25:40.0082 (UTC) FILETIME=[10197D20:01CCD987] Subject: Re: [siprec] No SIPREC Meeting in Boston. 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, 23 Jan 2012 04:25:43 -0000 I think we could have an interim virtual meeting for a couple of hours ( may be one of the days during Feb 13 - 17 week ?) to make some more progress on the drafts. Thoughts ? Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Friday, January 20, 2012 10:55 PM > To: siprec@ietf.org > Subject: [siprec] No SIPREC Meeting in Boston. >=20 > Hi All, >=20 > There will be no February SIPREC meeting in Boston. >=20 > After chasing a few people to see who would attend I came to the > conclusion there is not enough support for a face to face meeting in > Boston be it an official interim or a more informal design team > meeting. >=20 > There is however a desire to get things moving forward at a bit of a > quicker pace so we need to discuss ways of doing that. Suggestions are > most welcome. >=20 > In the first instance let's get some productive discussion going on the > list and get in good shape for IETF83 in March it looks like we should > have a good attendance of working group members in Paris. >=20 > Regards > Andy >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From leon.portman@gmail.com Sun Jan 22 21:22:07 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE8A21F8571 for ; Sun, 22 Jan 2012 21:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 fw4hlpi2XJ3V for ; Sun, 22 Jan 2012 21:22:07 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4B8B21F8532 for ; Sun, 22 Jan 2012 21:22:06 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1751213vcb.31 for ; Sun, 22 Jan 2012 21:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=d6eXWyOczISMkoluKhEKnMoaWWJ3xSv4gNE2Oh73V78=; b=GYuVyLQRUaOGqSc6G4tOH8kjFNc6mOoSOH7v4s/EGtGLqsDf0NHaShxJXF5YlwTZCl iL7v3rjQdNWEB7YyqZSBmqTkIRMnWGPGnVNgMUXqECcyWB1VfxzLGRXimgTX3xaew5q2 FnP/NPYQrV4NOGO6Nez20diSyL90IphZiWYtA= MIME-Version: 1.0 Received: by 10.220.155.212 with SMTP id t20mr3681472vcw.8.1327296124738; Sun, 22 Jan 2012 21:22:04 -0800 (PST) Received: by 10.220.178.193 with HTTP; Sun, 22 Jan 2012 21:22:04 -0800 (PST) In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD0929B2C5@XMB-BGL-417.cisco.com> References: <101C6067BEC68246B0C3F6843BCCC1E312005EEB31@MCHP058A.global-ad.net> <35BCE99A477D6A4986FB2216D8CF2CFD0929B2C5@XMB-BGL-417.cisco.com> Date: Mon, 23 Jan 2012 07:22:04 +0200 Message-ID: From: Leon Portman To: "Ram Mohan R (rmohanr)" , "Hutton, Andrew" , siprec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [siprec] No SIPREC Meeting in Boston. 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, 23 Jan 2012 05:22:07 -0000 I think it is very good proposal, Ram Leon On 1/23/12, Ram Mohan R (rmohanr) wrote: > I think we could have an interim virtual meeting for a couple of hours ( > may be one of the days during Feb 13 - 17 week ?) to make some more > progress on the drafts. > > Thoughts ? > > Regards, > Ram > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Friday, January 20, 2012 10:55 PM >> To: siprec@ietf.org >> Subject: [siprec] No SIPREC Meeting in Boston. >> >> Hi All, >> >> There will be no February SIPREC meeting in Boston. >> >> After chasing a few people to see who would attend I came to the >> conclusion there is not enough support for a face to face meeting in >> Boston be it an official interim or a more informal design team >> meeting. >> >> There is however a desire to get things moving forward at a bit of a >> quicker pace so we need to discuss ways of doing that. Suggestions are >> most welcome. >> >> In the first instance let's get some productive discussion going on > the >> list and get in good shape for IETF83 in March it looks like we should >> have a good attendance of working group members in Paris. >> >> Regards >> Andy >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > -- Sent from my mobile device From Leon.Portman@nice.com Mon Jan 23 01:21:54 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF2721F84BD for ; Mon, 23 Jan 2012 01:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 m3jSf6qDUr7n for ; Mon, 23 Jan 2012 01:21:53 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id C8F0B21F8498 for ; Mon, 23 Jan 2012 01:21:52 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 23 Jan 2012 11:21:49 +0200 From: Leon Portman To: Henry Lum , "Hutton, Andrew" , "siprec@ietf.org" Date: Mon, 23 Jan 2012 11:21:47 +0200 Thread-Topic: [siprec] Transport of snapshot request Thread-Index: AcyxGxzXGIYdGDtlTJKb6K2UVf17VgltcougAEZAx7AAcZ10MA== Message-ID: <07465C1D981ABC41A344374066AE1A2C39D34F5065@TLVMBX01.nice.com> References: <6ACE27C1-E11E-4137-A0E9-81BDF6C0E524@gmail.com><622B0E14298DDE47ACA9E16B292F22A40F2F7EB2@Mail1.acmepacket.com><387F9047F55E8C42850AD6B3A7A03C6C01D9D17E@inba-mail02.sonusnet.com><4ED6EAA3.6060708@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31200587082@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74080A8C65@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74080A8C65@NAHALD.us.int.genesyslab.com> 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 Subject: Re: [siprec] Transport of snapshot request 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, 23 Jan 2012 09:21:55 -0000 +1=20 Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Henry Lum Sent: Saturday, January 21, 2012 5:16 AM To: Hutton, Andrew; siprec@ietf.org Subject: Re: [siprec] Transport of snapshot request I agree on keeping the snapshot request and the snapshot as separate transa= ctions which is the main point of this issue. The resulting 3 items below t= o me are basically the mechanism of mandating the snapshot request and snap= shot as separate transactions, which I also agree is a reasonable and simpl= e mechanism. =20 Thanks Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hutton, Andrew > Sent: January-19-12 1:52 PM > To: siprec@ietf.org > Subject: Re: [siprec] Transport of snapshot request >=20 > Hi All, >=20 > So let me try to summarize where we are on transporting the snapshot=20 > request and the resulting metadata snapshot and give my own view on=20 > this. >=20 > It seems that at least a couple of people (Paul & John) proposing that=20 > we need to keep the snapshot request and the resulting snapshot=20 > separated in different transactions and I also think that would be a=20 > good idea. >=20 > We should however make sure we support the case when there is no=20 > metadata provided via an XML body in which case I can see that a=20 > reINVITE without SDP is effectively a snapshot request and must be=20 > supported but that is just basic SIP and maybe we just don't call this=20 > a snapshot request at all. >=20 > Assuming we agree on the different transaction model then I see no=20 > benefit to including the snapshot request in a reINVITE in fact it=20 > would be quite messy to do so given that the response would have to=20 > include an SDP offer and so would most likely the resulting snapshot=20 > itself. This would be a mess so let's mandate that the snapshot request > is made in an UPDATE request. >=20 > The resulting snapshot which includes an SDP offer plus metadata could=20 > then be included in either a reINVITE or an UPDATE. I am not sure there > is much benefit in mandating that this is always in an UPDATE because=20 > an SRS is almost certainly going to support sending a reINVITE with=20 > metadata anyway but we could. >=20 > So in summary my thinking is: >=20 > 1. An explicit snapshot request MUST be in an UPDATE without SDP. >=20 > 2. The snaphot MUST be in either an UPDATE or a reINVITE both of which=20 > MUST have SDP. I would be ok with mandating it be only in an UPDATE but > I think it is not necessary. >=20 > 3. The SRS MAY generate a reINVITE without SDP but this MUST not=20 > include a snapshot request. >=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of John Elwell > Sent: 02 December 2011 17:52 > To: Hadriel Kaplan; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Transport of snapshot request >=20 > I am happy with the notion of keeping options to a minimum. However, I=20 > prefer to decouple the snapshot request and the snapshot into different > transactions (rather like SUBSCRIBE and NOTIFY). The snapshot itself=20 > can then be done the same way as any metadata update (except we might=20 > choose to mandate that a snapshot be accompanied by an SDP offer, even=20 > though a regular update might be with or without an SDP offer). So a=20 > simple approach might be: > - UPDATE request (without SDP offer) for snapshot request; > - UPDATE request (with/without SDP offer) for metadata update or=20 > snapshot. >=20 > John >=20 > ----- Original Message ----- > From: "Hadriel Kaplan" > To: "Paul Kyzivat" > Cc: > Sent: Thursday, December 01, 2011 3:28 PM > Subject: Re: [siprec] Transport of snapshot request >=20 >=20 > > > > The reason to "exclude" anything is to improve interoperability. > I've > > seen countless issues with implementations not expecting another > device to > > do something causing problems when the other device does it, and=20 > > definitely for re-INVITEs and UPDATE scenarios. > > > > So unless there's some pressing need to support multiple possible=20 > > scenarios, I don't see any reason not to just pick one and only one > way to > > do something - it will improve interop to do so. > > > > If we think a snapshot request from the SRS will usually need SDP > from the > > SRC, and we don't think the SRS can provide an SDP offer in the > snapshot > > request - and I don't think the SRS can in fact always provide an SDP > > offer in it because the whole reason it's asking for a snapshot is it > > forgot stuff - then we should pick a way to do it without requiring > the > > SRS to send an SDP offer. > > > > Ergo, I vote we pick the snapshot request mechanism be an offerless=20 > > re-INVITE, period. That will work in every scenario anyone has ever=20 > > mentioned, afaict, and thus there's no reason to do anything else. > No? > > > > -hadriel > > > > > > On Nov 30, 2011, at 9:46 PM, Paul Kyzivat wrote: > > > >> On 12/1/11 8:47 AM, Ravindran, Parthasarathi wrote: > >>> Hi all, > >>> > >>> I agree with UPDATE without SDP based snapshot request in case > there is > >>> an agreement that SRS will never generate offer as there is no=20 > >>> possibility of offer-answer race condition based on snapshot=20 > >>> request mechanism. > So, > >>> I'm interested in hearing everybody opinion on "no offer from SRS" > >>> stance > >>> For SIPREC. > >> > >> I don't see how it would ever make sense for the SRS to make an > offer to > >> the SRC, so I'm fine with declaring that invalid SRS behavior. > >> > >> As far as a snapshot without SDP, I agree it is unlikely that a > snapshot > >> would not require an SDP update. But I see no reason to exclude it > in the > >> unlikely event that a case comes up when it is valid. > >> > >> This would be a problem if a snapshot request was in an UPDATE > without > >> SDP and the snapshot was required to be in the reply. But as long as > the > >> SRC can wait and send the snapshot in a request it initiates, it can > make > >> any offer it needs to, or potentially it could do the snapshot in an > >> UPDATE without SDP if no SDP was needed. > >> > >> Thanks, > >> Paul > >> > >>> Brad/John, > >>> > >>> Please read inline. > >>> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > >>>> Behalf Of Brad Winslow > >>>> Sent: Wednesday, November 23, 2011 10:23 PM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] Transport of snapshot request > >>>> > >>>> Hi Folks, > >>>> > >>>> In the situation where the SRS needs a metadata update, it most > likely > >>>> will need an SDP update, as there is no guarantee the metadata- > only > >>>> update would be consistent with the current SDP label attributes > of the > >>>> SRS, aren't we asking for trouble if we allow a metadata-only > update? > >>> Snapshot request UPDATE without SDP from SRS is used to=20 > >>> trigger Metadata request in SRC using RE-INVITE or UPDATE method=20 > >>> > >>> > >>>> If we decide on a full update, metadata + SDP, should we settle on > >>>> UPDATE or INVITE to transmit the update from SRC to SRS? > >>> We have common understanding here > >>> > >>>> > >>>> As an aside, there is an expectation that the SRC behaves as a SIP > UA, > >>>> in this case it should be able to respond to an offer-less re- > INVITE > >>>> from the SRS and provide metadata and SDP in the response. > >>>> > >>> offerless Re-INVITE with 100 + 200 response is currently=20 > >>> considered as alternative Proposal to UPDATE without SDP snapshot > request > >>> > >>>> Finally, if the SRS receives an INVITE for a new recording > session, > >>>> should we have an error code response which indicates the SRS is > not > >>>> interested in recording the session, not as a failure status, just > as a > >>>> status to terminate the recording. > >>> > >>> It will be negative response in case INVITE with=20 > >>> require:siprec is not accepted using 200 OK right? Do we need the=20 > >>> new server negative > 5xx > >>> response code for this policy decision? > >>> > >>> This presupposes the SRS may make > >>>> policy decisions for recording. > >>>> > >>>> Thanks in advance for your thoughts, Brad > >>>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > >>>> Behalf Of Leon Portman > >>>> Sent: Thursday, November 17, 2011 4:47 AM > >>>> To: John Elwell > >>>> Cc: siprec@ietf.org > >>>> Subject: Re: [siprec] Transport of snapshot request > >>>> > >>>> John, Nice to have you back on the list. > >>>> > >>>> Actually discussion during IETF meeting was started to converge to > >>>> similar as you describe below. > >>>> > >>>> Regards > >>>> > >>>> Leon > >>>> > >>>> On Nov 17, 2011, at 5:15 PM, John Elwell wrote: > >>>> > >>>>> There has been a long thread discussing the SIP messages for > snapshot > >>>> requests. > >>>>> > >>>>> First, I see no reason to tie the snapshot request and the > metadata > >>>> transmission to the same transaction (request/response). If they > are > >>>> tied together, this imposes unnecessary time and architectural=20 > >>>> constraints on the SRC. > >>> > >>> The model proposed is request/provisional > response/response > >>> Wherein RE-INVITE/100/200 trying shall be used wherein there is no=20 > >>> Immediate response to SRS. > >>> > >>> I much prefer an approach similar to the > >>>> subscribe/notify approach of RFC 3265 - use different > transactions. > >>> > >>> The downside of this approach is 4 SIP messages per every > >>> Service. I'm seeing the middle ground of offerless RE-INVITE with=20 > >>> Provisional response (100) and final response wherein 3 messages > are > >>> Involved but there is no extra offer/answer race condition from > SRS. > >>> > >>> Having said that, in case it is confirmed that SRS will never offer > >>> Then I'm fine with UPDATE based snapshot request > >>> > >>> I am > >>>> rather unsympathetic to allowing, as an option, metadata > transmission > >>>> in > >>>> a response. Apart from the timing and architectural concerns, > there is > >>>> no means of responding to a response if anything is wrong. Keep it > >>>> simple, and allow metadata transmission only in requests, as in > NOTIFY. > >>>>> > >>>>> Second, I think it is an SRC decision whether it needs a further > >>>> offer-answer exchange. When sending the request containing the=20 > >>>> metadata, the SRC must ensure that any references to media=20 > >>>> description > labels are > >>>> consistent with the last SDP sent by the SRC - if not, the SRC can > >>>> initiate a further offer-answer exchange at the same time as the=20 > >>>> metadata transmission. > >>>>> > >>>>> Perhaps it is my imagination, but I thought we had on the table > at one > >>>> time the notion of: > >>>>> - SRS sends snapshot request in an UPDATE request. > >>>>> - SRC sends medata in an UPDATE request (with offer if it needs > to > >>>> change SDP, otherwise without). > >>>>> > >>>>> I have lost track of how we came to diverge from this simple > model. > >>>>> > >>>>> John > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > _______________________________________________ > 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 =09 ---------------------------------------------------------------------------= ---------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er person, use it for any purpose, or store or copy the information in any = medium. Copyright in this e-mail and any attachments belongs to Alcatel-Luc= ent and/or its affiliated entities. =09 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Mon Jan 23 01:33:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A495B21F8659 for ; Mon, 23 Jan 2012 01:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 ZMiaVNbAjVuo for ; Mon, 23 Jan 2012 01:33:24 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3628321F8655 for ; Mon, 23 Jan 2012 01:33:24 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0N9Y5cQ019724; Mon, 23 Jan 2012 04:34:05 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 04:33:19 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 15:04:20 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Mon, 23 Jan 2012 15:04:20 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman , Henry Lum , "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] Transport of snapshot request Thread-Index: AQHMsRsg6ij0KenvQEu7JOWM9t6Oh5YT+IaAgAIfDwCAA4rdgIAAXejQ Date: Mon, 23 Jan 2012 09:34:19 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD23FD@inba-mail02.sonusnet.com> References: <6ACE27C1-E11E-4137-A0E9-81BDF6C0E524@gmail.com><622B0E14298DDE47ACA9E16B292F22A40F2F7EB2@Mail1.acmepacket.com><387F9047F55E8C42850AD6B3A7A03C6C01D9D17E@inba-mail02.sonusnet.com><4ED6EAA3.6060708@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31200587082@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74080A8C65@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C39D34F5065@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C39D34F5065@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jan 2012 09:34:20.0870 (UTC) FILETIME=[2F597660:01CCD9B2] Subject: Re: [siprec] Transport of snapshot request 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, 23 Jan 2012 09:33:25 -0000 Hi Andy, I agree with your proposal as it is reduces the race condition introduced b= y UPDATE snapshot request. I guess that the following statement will clarif= y more on the snapshot requirement. "SRS MAY generate a RE-INVITE with or without SDP but this MUST NOT include= a snapshot request."=20 Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Leon Portman >Sent: Monday, January 23, 2012 2:52 PM >To: Henry Lum; Hutton, Andrew; siprec@ietf.org >Subject: Re: [siprec] Transport of snapshot request > >+1 > >Leon > > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Henry Lum >Sent: Saturday, January 21, 2012 5:16 AM >To: Hutton, Andrew; siprec@ietf.org >Subject: Re: [siprec] Transport of snapshot request > >I agree on keeping the snapshot request and the snapshot as separate >transactions which is the main point of this issue. The resulting 3 >items below to me are basically the mechanism of mandating the snapshot >request and snapshot as separate transactions, which I also agree is a >reasonable and simple mechanism. > >Thanks >Henry > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: January-19-12 1:52 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Transport of snapshot request >> >> Hi All, >> >> So let me try to summarize where we are on transporting the snapshot >> request and the resulting metadata snapshot and give my own view on >> this. >> >> It seems that at least a couple of people (Paul & John) proposing that >> we need to keep the snapshot request and the resulting snapshot >> separated in different transactions and I also think that would be a >> good idea. >> >> We should however make sure we support the case when there is no >> metadata provided via an XML body in which case I can see that a >> reINVITE without SDP is effectively a snapshot request and must be >> supported but that is just basic SIP and maybe we just don't call this >> a snapshot request at all. >> >> Assuming we agree on the different transaction model then I see no >> benefit to including the snapshot request in a reINVITE in fact it >> would be quite messy to do so given that the response would have to >> include an SDP offer and so would most likely the resulting snapshot >> itself. This would be a mess so let's mandate that the snapshot >request >> is made in an UPDATE request. >> >> The resulting snapshot which includes an SDP offer plus metadata could >> then be included in either a reINVITE or an UPDATE. I am not sure >there >> is much benefit in mandating that this is always in an UPDATE because >> an SRS is almost certainly going to support sending a reINVITE with >> metadata anyway but we could. >> >> So in summary my thinking is: >> >> 1. An explicit snapshot request MUST be in an UPDATE without SDP. >> >> 2. The snaphot MUST be in either an UPDATE or a reINVITE both of which >> MUST have SDP. I would be ok with mandating it be only in an UPDATE >but >> I think it is not necessary. >> >> 3. The SRS MAY generate a reINVITE without SDP but this MUST not >> include a snapshot request. >> >> Regards >> Andy >> >> >> >> >> >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of John Elwell >> Sent: 02 December 2011 17:52 >> To: Hadriel Kaplan; Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Transport of snapshot request >> >> I am happy with the notion of keeping options to a minimum. However, I >> prefer to decouple the snapshot request and the snapshot into >different >> transactions (rather like SUBSCRIBE and NOTIFY). The snapshot itself >> can then be done the same way as any metadata update (except we might >> choose to mandate that a snapshot be accompanied by an SDP offer, even >> though a regular update might be with or without an SDP offer). So a >> simple approach might be: >> - UPDATE request (without SDP offer) for snapshot request; >> - UPDATE request (with/without SDP offer) for metadata update or >> snapshot. >> >> John >> >> ----- Original Message ----- >> From: "Hadriel Kaplan" >> To: "Paul Kyzivat" >> Cc: >> Sent: Thursday, December 01, 2011 3:28 PM >> Subject: Re: [siprec] Transport of snapshot request >> >> >> > >> > The reason to "exclude" anything is to improve interoperability. >> I've >> > seen countless issues with implementations not expecting another >> device to >> > do something causing problems when the other device does it, and >> > definitely for re-INVITEs and UPDATE scenarios. >> > >> > So unless there's some pressing need to support multiple possible >> > scenarios, I don't see any reason not to just pick one and only one >> way to >> > do something - it will improve interop to do so. >> > >> > If we think a snapshot request from the SRS will usually need SDP >> from the >> > SRC, and we don't think the SRS can provide an SDP offer in the >> snapshot >> > request - and I don't think the SRS can in fact always provide an >SDP >> > offer in it because the whole reason it's asking for a snapshot is >it >> > forgot stuff - then we should pick a way to do it without requiring >> the >> > SRS to send an SDP offer. >> > >> > Ergo, I vote we pick the snapshot request mechanism be an offerless >> > re-INVITE, period. That will work in every scenario anyone has ever >> > mentioned, afaict, and thus there's no reason to do anything else. >> No? >> > >> > -hadriel >> > >> > >> > On Nov 30, 2011, at 9:46 PM, Paul Kyzivat wrote: >> > >> >> On 12/1/11 8:47 AM, Ravindran, Parthasarathi wrote: >> >>> Hi all, >> >>> >> >>> I agree with UPDATE without SDP based snapshot request in case >> there is >> >>> an agreement that SRS will never generate offer as there is no >> >>> possibility of offer-answer race condition based on snapshot >> >>> request >mechanism. >> So, >> >>> I'm interested in hearing everybody opinion on "no offer from SRS" >> >>> stance >> >>> For SIPREC. >> >> >> >> I don't see how it would ever make sense for the SRS to make an >> offer to >> >> the SRC, so I'm fine with declaring that invalid SRS behavior. >> >> >> >> As far as a snapshot without SDP, I agree it is unlikely that a >> snapshot >> >> would not require an SDP update. But I see no reason to exclude it >> in the >> >> unlikely event that a case comes up when it is valid. >> >> >> >> This would be a problem if a snapshot request was in an UPDATE >> without >> >> SDP and the snapshot was required to be in the reply. But as long >as >> the >> >> SRC can wait and send the snapshot in a request it initiates, it >can >> make >> >> any offer it needs to, or potentially it could do the snapshot in >an >> >> UPDATE without SDP if no SDP was needed. >> >> >> >> Thanks, >> >> Paul >> >> >> >>> Brad/John, >> >>> >> >>> Please read inline. >> >>> >> >>> Thanks >> >>> Partha >> >>> >> >>>> -----Original Message----- >> >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >>>> Behalf Of Brad Winslow >> >>>> Sent: Wednesday, November 23, 2011 10:23 PM >> >>>> To: siprec@ietf.org >> >>>> Subject: Re: [siprec] Transport of snapshot request >> >>>> >> >>>> Hi Folks, >> >>>> >> >>>> In the situation where the SRS needs a metadata update, it most >> likely >> >>>> will need an SDP update, as there is no guarantee the metadata- >> only >> >>>> update would be consistent with the current SDP label attributes >> of the >> >>>> SRS, aren't we asking for trouble if we allow a metadata-only >> update? >> >>> Snapshot request UPDATE without SDP from SRS is used to >> >>> trigger Metadata request in SRC using RE-INVITE or UPDATE method >> >>> >> >>> >> >>>> If we decide on a full update, metadata + SDP, should we settle >on >> >>>> UPDATE or INVITE to transmit the update from SRC to SRS? >> >>> We have common understanding here >> >>> >> >>>> >> >>>> As an aside, there is an expectation that the SRC behaves as a >SIP >> UA, >> >>>> in this case it should be able to respond to an offer-less re- >> INVITE >> >>>> from the SRS and provide metadata and SDP in the response. >> >>>> >> >>> offerless Re-INVITE with 100 + 200 response is currently >> >>> considered as alternative Proposal to UPDATE without SDP snapshot >> request >> >>> >> >>>> Finally, if the SRS receives an INVITE for a new recording >> session, >> >>>> should we have an error code response which indicates the SRS is >> not >> >>>> interested in recording the session, not as a failure status, >just >> as a >> >>>> status to terminate the recording. >> >>> >> >>> It will be negative response in case INVITE with >> >>> require:siprec is not accepted using 200 OK right? Do we need the >> >>> new server >negative >> 5xx >> >>> response code for this policy decision? >> >>> >> >>> This presupposes the SRS may make >> >>>> policy decisions for recording. >> >>>> >> >>>> Thanks in advance for your thoughts, Brad >> >>>> >> >>>> -----Original Message----- >> >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >>>> Behalf Of Leon Portman >> >>>> Sent: Thursday, November 17, 2011 4:47 AM >> >>>> To: John Elwell >> >>>> Cc: siprec@ietf.org >> >>>> Subject: Re: [siprec] Transport of snapshot request >> >>>> >> >>>> John, Nice to have you back on the list. >> >>>> >> >>>> Actually discussion during IETF meeting was started to converge >to >> >>>> similar as you describe below. >> >>>> >> >>>> Regards >> >>>> >> >>>> Leon >> >>>> >> >>>> On Nov 17, 2011, at 5:15 PM, John Elwell wrote: >> >>>> >> >>>>> There has been a long thread discussing the SIP messages for >> snapshot >> >>>> requests. >> >>>>> >> >>>>> First, I see no reason to tie the snapshot request and the >> metadata >> >>>> transmission to the same transaction (request/response). If they >> are >> >>>> tied together, this imposes unnecessary time and architectural >> >>>> constraints on the SRC. >> >>> >> >>> The model proposed is request/provisional >> response/response >> >>> Wherein RE-INVITE/100/200 trying shall be used wherein there is no >> >>> Immediate response to SRS. >> >>> >> >>> I much prefer an approach similar to the >> >>>> subscribe/notify approach of RFC 3265 - use different >> transactions. >> >>> >> >>> The downside of this approach is 4 SIP messages per >every >> >>> Service. I'm seeing the middle ground of offerless RE-INVITE with >> >>> Provisional response (100) and final response wherein 3 messages >> are >> >>> Involved but there is no extra offer/answer race condition from >> SRS. >> >>> >> >>> Having said that, in case it is confirmed that SRS will never >offer >> >>> Then I'm fine with UPDATE based snapshot request >> >>> >> >>> I am >> >>>> rather unsympathetic to allowing, as an option, metadata >> transmission >> >>>> in >> >>>> a response. Apart from the timing and architectural concerns, >> there is >> >>>> no means of responding to a response if anything is wrong. Keep >it >> >>>> simple, and allow metadata transmission only in requests, as in >> NOTIFY. >> >>>>> >> >>>>> Second, I think it is an SRC decision whether it needs a further >> >>>> offer-answer exchange. When sending the request containing the >> >>>> metadata, the SRC must ensure that any references to media >> >>>> description >> labels are >> >>>> consistent with the last SDP sent by the SRC - if not, the SRC >can >> >>>> initiate a further offer-answer exchange at the same time as the >> >>>> metadata transmission. >> >>>>> >> >>>>> Perhaps it is my imagination, but I thought we had on the table >> at one >> >>>> time the notion of: >> >>>>> - SRS sends snapshot request in an UPDATE request. >> >>>>> - SRC sends medata in an UPDATE request (with offer if it needs >> to >> >>>> change SDP, otherwise without). >> >>>>> >> >>>>> I have lost track of how we came to diverge from this simple >> model. >> >>>>> >> >>>>> John >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 > > >------------------------------------------------------------------------ >------------------------------------------- >CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain >confidential and proprietary information of Alcatel-Lucent and/or its >affiliated entities. Access by the intended recipient only is >authorized. Any liability arising from any party acting, or refraining >from acting, on any information contained in this e-mail is hereby >excluded. If you are not the intended recipient, please notify the >sender immediately, destroy the original transmission and its >attachments and do not disclose the contents to any other person, use it >for any purpose, or store or copy the information in any medium. >Copyright in this e-mail and any attachments belongs to Alcatel-Lucent >and/or its affiliated entities. > >_______________________________________________ >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 Mon Jan 23 03:56:08 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DC521F8700 for ; Mon, 23 Jan 2012 03:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 wkGbtn0YbOK3 for ; Mon, 23 Jan 2012 03:56:07 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 202DD21F86E2 for ; Mon, 23 Jan 2012 03:56:06 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7F2BF23F0468; Mon, 23 Jan 2012 12:56:04 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 23 Jan 2012 12:56:04 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Leon Portman , Henry Lum , "siprec@ietf.org" Date: Mon, 23 Jan 2012 12:56:02 +0100 Thread-Topic: [siprec] Transport of snapshot request Thread-Index: AQHMsRsg6ij0KenvQEu7JOWM9t6Oh5YT+IaAgAIfDwCAA4rdgIAAXejQgAAo7lA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312005EEE7C@MCHP058A.global-ad.net> References: <6ACE27C1-E11E-4137-A0E9-81BDF6C0E524@gmail.com><622B0E14298DDE47ACA9E16B292F22A40F2F7EB2@Mail1.acmepacket.com><387F9047F55E8C42850AD6B3A7A03C6C01D9D17E@inba-mail02.sonusnet.com><4ED6EAA3.6060708@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31200587082@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74080A8C65@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C39D34F5065@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C01DD23FD@inba-mail02.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DD23FD@inba-mail02.sonusnet.com> 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 Subject: Re: [siprec] Transport of snapshot request 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, 23 Jan 2012 11:56:08 -0000 Hi Partha, Great I also agree that your text is also makes the requirements very clear= . Regards Andy -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: 23 January 2012 09:34 To: Leon Portman; Henry Lum; Hutton, Andrew; siprec@ietf.org Subject: RE: [siprec] Transport of snapshot request Hi Andy, I agree with your proposal as it is reduces the race condition introduced b= y UPDATE snapshot request. I guess that the following statement will clarif= y more on the snapshot requirement. "SRS MAY generate a RE-INVITE with or without SDP but this MUST NOT include= a snapshot request." Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Leon Portman >Sent: Monday, January 23, 2012 2:52 PM >To: Henry Lum; Hutton, Andrew; siprec@ietf.org >Subject: Re: [siprec] Transport of snapshot request > >+1 > >Leon > > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Henry Lum >Sent: Saturday, January 21, 2012 5:16 AM >To: Hutton, Andrew; siprec@ietf.org >Subject: Re: [siprec] Transport of snapshot request > >I agree on keeping the snapshot request and the snapshot as separate >transactions which is the main point of this issue. The resulting 3 >items below to me are basically the mechanism of mandating the snapshot >request and snapshot as separate transactions, which I also agree is a >reasonable and simple mechanism. > >Thanks >Henry > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: January-19-12 1:52 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Transport of snapshot request >> >> Hi All, >> >> So let me try to summarize where we are on transporting the snapshot >> request and the resulting metadata snapshot and give my own view on >> this. >> >> It seems that at least a couple of people (Paul & John) proposing that >> we need to keep the snapshot request and the resulting snapshot >> separated in different transactions and I also think that would be a >> good idea. >> >> We should however make sure we support the case when there is no >> metadata provided via an XML body in which case I can see that a >> reINVITE without SDP is effectively a snapshot request and must be >> supported but that is just basic SIP and maybe we just don't call this >> a snapshot request at all. >> >> Assuming we agree on the different transaction model then I see no >> benefit to including the snapshot request in a reINVITE in fact it >> would be quite messy to do so given that the response would have to >> include an SDP offer and so would most likely the resulting snapshot >> itself. This would be a mess so let's mandate that the snapshot >request >> is made in an UPDATE request. >> >> The resulting snapshot which includes an SDP offer plus metadata could >> then be included in either a reINVITE or an UPDATE. I am not sure >there >> is much benefit in mandating that this is always in an UPDATE because >> an SRS is almost certainly going to support sending a reINVITE with >> metadata anyway but we could. >> >> So in summary my thinking is: >> >> 1. An explicit snapshot request MUST be in an UPDATE without SDP. >> >> 2. The snaphot MUST be in either an UPDATE or a reINVITE both of which >> MUST have SDP. I would be ok with mandating it be only in an UPDATE >but >> I think it is not necessary. >> >> 3. The SRS MAY generate a reINVITE without SDP but this MUST not >> include a snapshot request. >> >> Regards >> Andy >> >> >> >> >> >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of John Elwell >> Sent: 02 December 2011 17:52 >> To: Hadriel Kaplan; Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Transport of snapshot request >> >> I am happy with the notion of keeping options to a minimum. However, I >> prefer to decouple the snapshot request and the snapshot into >different >> transactions (rather like SUBSCRIBE and NOTIFY). The snapshot itself >> can then be done the same way as any metadata update (except we might >> choose to mandate that a snapshot be accompanied by an SDP offer, even >> though a regular update might be with or without an SDP offer). So a >> simple approach might be: >> - UPDATE request (without SDP offer) for snapshot request; >> - UPDATE request (with/without SDP offer) for metadata update or >> snapshot. >> >> John >> >> ----- Original Message ----- >> From: "Hadriel Kaplan" >> To: "Paul Kyzivat" >> Cc: >> Sent: Thursday, December 01, 2011 3:28 PM >> Subject: Re: [siprec] Transport of snapshot request >> >> >> > >> > The reason to "exclude" anything is to improve interoperability. >> I've >> > seen countless issues with implementations not expecting another >> device to >> > do something causing problems when the other device does it, and >> > definitely for re-INVITEs and UPDATE scenarios. >> > >> > So unless there's some pressing need to support multiple possible >> > scenarios, I don't see any reason not to just pick one and only one >> way to >> > do something - it will improve interop to do so. >> > >> > If we think a snapshot request from the SRS will usually need SDP >> from the >> > SRC, and we don't think the SRS can provide an SDP offer in the >> snapshot >> > request - and I don't think the SRS can in fact always provide an >SDP >> > offer in it because the whole reason it's asking for a snapshot is >it >> > forgot stuff - then we should pick a way to do it without requiring >> the >> > SRS to send an SDP offer. >> > >> > Ergo, I vote we pick the snapshot request mechanism be an offerless >> > re-INVITE, period. That will work in every scenario anyone has ever >> > mentioned, afaict, and thus there's no reason to do anything else. >> No? >> > >> > -hadriel >> > >> > >> > On Nov 30, 2011, at 9:46 PM, Paul Kyzivat wrote: >> > >> >> On 12/1/11 8:47 AM, Ravindran, Parthasarathi wrote: >> >>> Hi all, >> >>> >> >>> I agree with UPDATE without SDP based snapshot request in case >> there is >> >>> an agreement that SRS will never generate offer as there is no >> >>> possibility of offer-answer race condition based on snapshot >> >>> request >mechanism. >> So, >> >>> I'm interested in hearing everybody opinion on "no offer from SRS" >> >>> stance >> >>> For SIPREC. >> >> >> >> I don't see how it would ever make sense for the SRS to make an >> offer to >> >> the SRC, so I'm fine with declaring that invalid SRS behavior. >> >> >> >> As far as a snapshot without SDP, I agree it is unlikely that a >> snapshot >> >> would not require an SDP update. But I see no reason to exclude it >> in the >> >> unlikely event that a case comes up when it is valid. >> >> >> >> This would be a problem if a snapshot request was in an UPDATE >> without >> >> SDP and the snapshot was required to be in the reply. But as long >as >> the >> >> SRC can wait and send the snapshot in a request it initiates, it >can >> make >> >> any offer it needs to, or potentially it could do the snapshot in >an >> >> UPDATE without SDP if no SDP was needed. >> >> >> >> Thanks, >> >> Paul >> >> >> >>> Brad/John, >> >>> >> >>> Please read inline. >> >>> >> >>> Thanks >> >>> Partha >> >>> >> >>>> -----Original Message----- >> >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >>>> Behalf Of Brad Winslow >> >>>> Sent: Wednesday, November 23, 2011 10:23 PM >> >>>> To: siprec@ietf.org >> >>>> Subject: Re: [siprec] Transport of snapshot request >> >>>> >> >>>> Hi Folks, >> >>>> >> >>>> In the situation where the SRS needs a metadata update, it most >> likely >> >>>> will need an SDP update, as there is no guarantee the metadata- >> only >> >>>> update would be consistent with the current SDP label attributes >> of the >> >>>> SRS, aren't we asking for trouble if we allow a metadata-only >> update? >> >>> Snapshot request UPDATE without SDP from SRS is used to >> >>> trigger Metadata request in SRC using RE-INVITE or UPDATE method >> >>> >> >>> >> >>>> If we decide on a full update, metadata + SDP, should we settle >on >> >>>> UPDATE or INVITE to transmit the update from SRC to SRS? >> >>> We have common understanding here >> >>> >> >>>> >> >>>> As an aside, there is an expectation that the SRC behaves as a >SIP >> UA, >> >>>> in this case it should be able to respond to an offer-less re- >> INVITE >> >>>> from the SRS and provide metadata and SDP in the response. >> >>>> >> >>> offerless Re-INVITE with 100 + 200 response is currently >> >>> considered as alternative Proposal to UPDATE without SDP snapshot >> request >> >>> >> >>>> Finally, if the SRS receives an INVITE for a new recording >> session, >> >>>> should we have an error code response which indicates the SRS is >> not >> >>>> interested in recording the session, not as a failure status, >just >> as a >> >>>> status to terminate the recording. >> >>> >> >>> It will be negative response in case INVITE with >> >>> require:siprec is not accepted using 200 OK right? Do we need the >> >>> new server >negative >> 5xx >> >>> response code for this policy decision? >> >>> >> >>> This presupposes the SRS may make >> >>>> policy decisions for recording. >> >>>> >> >>>> Thanks in advance for your thoughts, Brad >> >>>> >> >>>> -----Original Message----- >> >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >>>> Behalf Of Leon Portman >> >>>> Sent: Thursday, November 17, 2011 4:47 AM >> >>>> To: John Elwell >> >>>> Cc: siprec@ietf.org >> >>>> Subject: Re: [siprec] Transport of snapshot request >> >>>> >> >>>> John, Nice to have you back on the list. >> >>>> >> >>>> Actually discussion during IETF meeting was started to converge >to >> >>>> similar as you describe below. >> >>>> >> >>>> Regards >> >>>> >> >>>> Leon >> >>>> >> >>>> On Nov 17, 2011, at 5:15 PM, John Elwell wrote: >> >>>> >> >>>>> There has been a long thread discussing the SIP messages for >> snapshot >> >>>> requests. >> >>>>> >> >>>>> First, I see no reason to tie the snapshot request and the >> metadata >> >>>> transmission to the same transaction (request/response). If they >> are >> >>>> tied together, this imposes unnecessary time and architectural >> >>>> constraints on the SRC. >> >>> >> >>> The model proposed is request/provisional >> response/response >> >>> Wherein RE-INVITE/100/200 trying shall be used wherein there is no >> >>> Immediate response to SRS. >> >>> >> >>> I much prefer an approach similar to the >> >>>> subscribe/notify approach of RFC 3265 - use different >> transactions. >> >>> >> >>> The downside of this approach is 4 SIP messages per >every >> >>> Service. I'm seeing the middle ground of offerless RE-INVITE with >> >>> Provisional response (100) and final response wherein 3 messages >> are >> >>> Involved but there is no extra offer/answer race condition from >> SRS. >> >>> >> >>> Having said that, in case it is confirmed that SRS will never >offer >> >>> Then I'm fine with UPDATE based snapshot request >> >>> >> >>> I am >> >>>> rather unsympathetic to allowing, as an option, metadata >> transmission >> >>>> in >> >>>> a response. Apart from the timing and architectural concerns, >> there is >> >>>> no means of responding to a response if anything is wrong. Keep >it >> >>>> simple, and allow metadata transmission only in requests, as in >> NOTIFY. >> >>>>> >> >>>>> Second, I think it is an SRC decision whether it needs a further >> >>>> offer-answer exchange. When sending the request containing the >> >>>> metadata, the SRC must ensure that any references to media >> >>>> description >> labels are >> >>>> consistent with the last SDP sent by the SRC - if not, the SRC >can >> >>>> initiate a further offer-answer exchange at the same time as the >> >>>> metadata transmission. >> >>>>> >> >>>>> Perhaps it is my imagination, but I thought we had on the table >> at one >> >>>> time the notion of: >> >>>>> - SRS sends snapshot request in an UPDATE request. >> >>>>> - SRC sends medata in an UPDATE request (with offer if it needs >> to >> >>>> change SDP, otherwise without). >> >>>>> >> >>>>> I have lost track of how we came to diverge from this simple >> model. >> >>>>> >> >>>>> John >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 > > >------------------------------------------------------------------------ >------------------------------------------- >CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain >confidential and proprietary information of Alcatel-Lucent and/or its >affiliated entities. Access by the intended recipient only is >authorized. Any liability arising from any party acting, or refraining >from acting, on any information contained in this e-mail is hereby >excluded. If you are not the intended recipient, please notify the >sender immediately, destroy the original transmission and its >attachments and do not disclose the contents to any other person, use it >for any purpose, or store or copy the information in any medium. >Copyright in this e-mail and any attachments belongs to Alcatel-Lucent >and/or its affiliated entities. > >_______________________________________________ >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 Mon Jan 23 11:24:53 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8A121F8545 for ; Mon, 23 Jan 2012 11:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X37DK567Hf1 for ; Mon, 23 Jan 2012 11:24:51 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CE37221F8528 for ; Mon, 23 Jan 2012 11:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=16762; q=dns/txt; s=iport; t=1327346691; x=1328556291; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=R+ihleDjfZfLqKYkVx4UdLJ9ReBDapnvyZzY3/7Cqzw=; b=eaThZdSTZGbeCD5x8Tadic9q0Jc2Uc4LgMQL4oVoDqx+aUpzZ9VSnzl4 AlKjXXCaa4Sxb2FOXxKNVje0ELIGlqT5DEtrcAPHwGrdknC52TXpyXKLF nHqJ+M1dz71JG1S+PO5z3vv+zeXQNj++B0bz+ijr5O+EJq8SXtUuLKuqM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAABGzHU+rRDoJ/2dsb2JhbABCnVCQWoEFgXIBAQEEAQEBDwEdCjQCFQQCAQgRBAEBAQoCBBcBBgEmHwkIAgQBEggah2KaMwGeCQSLQ2MEiDufTQ X-IronPort-AV: E=Sophos;i="4.71,557,1320624000"; d="scan'208";a="25056200" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 23 Jan 2012 19:24:51 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0NJOpu0008367; Mon, 23 Jan 2012 19:24:51 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 11:24:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jan 2012 11:24:55 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312005EEE7C@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Transport of snapshot request Thread-Index: AQHMsRsg6ij0KenvQEu7JOWM9t6Oh5YT+IaAgAIfDwCAA4rdgIAAXejQgAAo7lCAAH3W4A== References: <6ACE27C1-E11E-4137-A0E9-81BDF6C0E524@gmail.com><622B0E14298DDE47ACA9E16B292F22A40F2F7EB2@Mail1.acmepacket.com><387F9047F55E8C42850AD6B3A7A03C6C01D9D17E@inba-mail02.sonusnet.com><4ED6EAA3.6060708@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31200587082@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74080A8C65@NAHALD.us.int.genesyslab.com><07465C1D981ABC41A344374066AE1A2C39D34F5065@TLVMBX01.nice.com><387F9047F55E8C42850AD6B3A7A03C6C01DD23FD@inba-mail02.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312005EEE7C@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "Ravindran, Parthasarathi" , "Leon Portman" , "Henry Lum" , X-OriginalArrivalTime: 23 Jan 2012 19:24:51.0197 (UTC) FILETIME=[AD7852D0:01CCDA04] Subject: Re: [siprec] Transport of snapshot request 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, 23 Jan 2012 19:24:53 -0000 Works for me. Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Monday, January 23, 2012 3:56 AM > To: Ravindran, Parthasarathi; Leon Portman; Henry Lum; siprec@ietf.org > Subject: Re: [siprec] Transport of snapshot request >=20 > Hi Partha, >=20 > Great I also agree that your text is also makes the requirements very > clear. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 23 January 2012 09:34 > To: Leon Portman; Henry Lum; Hutton, Andrew; siprec@ietf.org > Subject: RE: [siprec] Transport of snapshot request >=20 > Hi Andy, >=20 > I agree with your proposal as it is reduces the race condition > introduced by UPDATE snapshot request. I guess that the following > statement will clarify more on the snapshot requirement. >=20 > "SRS MAY generate a RE-INVITE with or without SDP but this MUST NOT > include a snapshot request." >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Leon Portman > >Sent: Monday, January 23, 2012 2:52 PM > >To: Henry Lum; Hutton, Andrew; siprec@ietf.org > >Subject: Re: [siprec] Transport of snapshot request > > > >+1 > > > >Leon > > > > > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Henry Lum > >Sent: Saturday, January 21, 2012 5:16 AM > >To: Hutton, Andrew; siprec@ietf.org > >Subject: Re: [siprec] Transport of snapshot request > > > >I agree on keeping the snapshot request and the snapshot as separate > >transactions which is the main point of this issue. The resulting 3 > >items below to me are basically the mechanism of mandating the > snapshot > >request and snapshot as separate transactions, which I also agree is a > >reasonable and simple mechanism. > > > >Thanks > >Henry > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Hutton, Andrew > >> Sent: January-19-12 1:52 PM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Transport of snapshot request > >> > >> Hi All, > >> > >> So let me try to summarize where we are on transporting the snapshot > >> request and the resulting metadata snapshot and give my own view on > >> this. > >> > >> It seems that at least a couple of people (Paul & John) proposing > that > >> we need to keep the snapshot request and the resulting snapshot > >> separated in different transactions and I also think that would be a > >> good idea. > >> > >> We should however make sure we support the case when there is no > >> metadata provided via an XML body in which case I can see that a > >> reINVITE without SDP is effectively a snapshot request and must be > >> supported but that is just basic SIP and maybe we just don't call > this > >> a snapshot request at all. > >> > >> Assuming we agree on the different transaction model then I see no > >> benefit to including the snapshot request in a reINVITE in fact it > >> would be quite messy to do so given that the response would have to > >> include an SDP offer and so would most likely the resulting snapshot > >> itself. This would be a mess so let's mandate that the snapshot > >request > >> is made in an UPDATE request. > >> > >> The resulting snapshot which includes an SDP offer plus metadata > could > >> then be included in either a reINVITE or an UPDATE. I am not sure > >there > >> is much benefit in mandating that this is always in an UPDATE > because > >> an SRS is almost certainly going to support sending a reINVITE with > >> metadata anyway but we could. > >> > >> So in summary my thinking is: > >> > >> 1. An explicit snapshot request MUST be in an UPDATE without SDP. > >> > >> 2. The snaphot MUST be in either an UPDATE or a reINVITE both of > which > >> MUST have SDP. I would be ok with mandating it be only in an UPDATE > >but > >> I think it is not necessary. > >> > >> 3. The SRS MAY generate a reINVITE without SDP but this MUST not > >> include a snapshot request. > >> > >> Regards > >> Andy > >> > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of John Elwell > >> Sent: 02 December 2011 17:52 > >> To: Hadriel Kaplan; Paul Kyzivat > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] Transport of snapshot request > >> > >> I am happy with the notion of keeping options to a minimum. However, > I > >> prefer to decouple the snapshot request and the snapshot into > >different > >> transactions (rather like SUBSCRIBE and NOTIFY). The snapshot itself > >> can then be done the same way as any metadata update (except we > might > >> choose to mandate that a snapshot be accompanied by an SDP offer, > even > >> though a regular update might be with or without an SDP offer). So a > >> simple approach might be: > >> - UPDATE request (without SDP offer) for snapshot request; > >> - UPDATE request (with/without SDP offer) for metadata update or > >> snapshot. > >> > >> John > >> > >> ----- Original Message ----- > >> From: "Hadriel Kaplan" > >> To: "Paul Kyzivat" > >> Cc: > >> Sent: Thursday, December 01, 2011 3:28 PM > >> Subject: Re: [siprec] Transport of snapshot request > >> > >> > >> > > >> > The reason to "exclude" anything is to improve interoperability. > >> I've > >> > seen countless issues with implementations not expecting another > >> device to > >> > do something causing problems when the other device does it, and > >> > definitely for re-INVITEs and UPDATE scenarios. > >> > > >> > So unless there's some pressing need to support multiple possible > >> > scenarios, I don't see any reason not to just pick one and only > one > >> way to > >> > do something - it will improve interop to do so. > >> > > >> > If we think a snapshot request from the SRS will usually need SDP > >> from the > >> > SRC, and we don't think the SRS can provide an SDP offer in the > >> snapshot > >> > request - and I don't think the SRS can in fact always provide an > >SDP > >> > offer in it because the whole reason it's asking for a snapshot is > >it > >> > forgot stuff - then we should pick a way to do it without > requiring > >> the > >> > SRS to send an SDP offer. > >> > > >> > Ergo, I vote we pick the snapshot request mechanism be an > offerless > >> > re-INVITE, period. That will work in every scenario anyone has > ever > >> > mentioned, afaict, and thus there's no reason to do anything else. > >> No? > >> > > >> > -hadriel > >> > > >> > > >> > On Nov 30, 2011, at 9:46 PM, Paul Kyzivat wrote: > >> > > >> >> On 12/1/11 8:47 AM, Ravindran, Parthasarathi wrote: > >> >>> Hi all, > >> >>> > >> >>> I agree with UPDATE without SDP based snapshot request in case > >> there is > >> >>> an agreement that SRS will never generate offer as there is no > >> >>> possibility of offer-answer race condition based on snapshot > >> >>> request > >mechanism. > >> So, > >> >>> I'm interested in hearing everybody opinion on "no offer from > SRS" > >> >>> stance > >> >>> For SIPREC. > >> >> > >> >> I don't see how it would ever make sense for the SRS to make an > >> offer to > >> >> the SRC, so I'm fine with declaring that invalid SRS behavior. > >> >> > >> >> As far as a snapshot without SDP, I agree it is unlikely that a > >> snapshot > >> >> would not require an SDP update. But I see no reason to exclude > it > >> in the > >> >> unlikely event that a case comes up when it is valid. > >> >> > >> >> This would be a problem if a snapshot request was in an UPDATE > >> without > >> >> SDP and the snapshot was required to be in the reply. But as long > >as > >> the > >> >> SRC can wait and send the snapshot in a request it initiates, it > >can > >> make > >> >> any offer it needs to, or potentially it could do the snapshot in > >an > >> >> UPDATE without SDP if no SDP was needed. > >> >> > >> >> Thanks, > >> >> Paul > >> >> > >> >>> Brad/John, > >> >>> > >> >>> Please read inline. > >> >>> > >> >>> Thanks > >> >>> Partha > >> >>> > >> >>>> -----Original Message----- > >> >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> >>>> Behalf Of Brad Winslow > >> >>>> Sent: Wednesday, November 23, 2011 10:23 PM > >> >>>> To: siprec@ietf.org > >> >>>> Subject: Re: [siprec] Transport of snapshot request > >> >>>> > >> >>>> Hi Folks, > >> >>>> > >> >>>> In the situation where the SRS needs a metadata update, it most > >> likely > >> >>>> will need an SDP update, as there is no guarantee the metadata- > >> only > >> >>>> update would be consistent with the current SDP label > attributes > >> of the > >> >>>> SRS, aren't we asking for trouble if we allow a metadata-only > >> update? > >> >>> Snapshot request UPDATE without SDP from SRS is used > to > >> >>> trigger Metadata request in SRC using RE-INVITE or UPDATE method > >> >>> > >> >>> > >> >>>> If we decide on a full update, metadata + SDP, should we settle > >on > >> >>>> UPDATE or INVITE to transmit the update from SRC to SRS? > >> >>> We have common understanding here > >> >>> > >> >>>> > >> >>>> As an aside, there is an expectation that the SRC behaves as a > >SIP > >> UA, > >> >>>> in this case it should be able to respond to an offer-less re- > >> INVITE > >> >>>> from the SRS and provide metadata and SDP in the response. > >> >>>> > >> >>> offerless Re-INVITE with 100 + 200 response is > currently > >> >>> considered as alternative Proposal to UPDATE without SDP > snapshot > >> request > >> >>> > >> >>>> Finally, if the SRS receives an INVITE for a new recording > >> session, > >> >>>> should we have an error code response which indicates the SRS > is > >> not > >> >>>> interested in recording the session, not as a failure status, > >just > >> as a > >> >>>> status to terminate the recording. > >> >>> > >> >>> It will be negative response in case INVITE with > >> >>> require:siprec is not accepted using 200 OK right? Do we need > the > >> >>> new server > >negative > >> 5xx > >> >>> response code for this policy decision? > >> >>> > >> >>> This presupposes the SRS may make > >> >>>> policy decisions for recording. > >> >>>> > >> >>>> Thanks in advance for your thoughts, Brad > >> >>>> > >> >>>> -----Original Message----- > >> >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> >>>> Behalf Of Leon Portman > >> >>>> Sent: Thursday, November 17, 2011 4:47 AM > >> >>>> To: John Elwell > >> >>>> Cc: siprec@ietf.org > >> >>>> Subject: Re: [siprec] Transport of snapshot request > >> >>>> > >> >>>> John, Nice to have you back on the list. > >> >>>> > >> >>>> Actually discussion during IETF meeting was started to converge > >to > >> >>>> similar as you describe below. > >> >>>> > >> >>>> Regards > >> >>>> > >> >>>> Leon > >> >>>> > >> >>>> On Nov 17, 2011, at 5:15 PM, John Elwell wrote: > >> >>>> > >> >>>>> There has been a long thread discussing the SIP messages for > >> snapshot > >> >>>> requests. > >> >>>>> > >> >>>>> First, I see no reason to tie the snapshot request and the > >> metadata > >> >>>> transmission to the same transaction (request/response). If > they > >> are > >> >>>> tied together, this imposes unnecessary time and architectural > >> >>>> constraints on the SRC. > >> >>> > >> >>> The model proposed is request/provisional > >> response/response > >> >>> Wherein RE-INVITE/100/200 trying shall be used wherein there is > no > >> >>> Immediate response to SRS. > >> >>> > >> >>> I much prefer an approach similar to the > >> >>>> subscribe/notify approach of RFC 3265 - use different > >> transactions. > >> >>> > >> >>> The downside of this approach is 4 SIP messages per > >every > >> >>> Service. I'm seeing the middle ground of offerless RE-INVITE > with > >> >>> Provisional response (100) and final response wherein 3 messages > >> are > >> >>> Involved but there is no extra offer/answer race condition from > >> SRS. > >> >>> > >> >>> Having said that, in case it is confirmed that SRS will never > >offer > >> >>> Then I'm fine with UPDATE based snapshot request > >> >>> > >> >>> I am > >> >>>> rather unsympathetic to allowing, as an option, metadata > >> transmission > >> >>>> in > >> >>>> a response. Apart from the timing and architectural concerns, > >> there is > >> >>>> no means of responding to a response if anything is wrong. Keep > >it > >> >>>> simple, and allow metadata transmission only in requests, as in > >> NOTIFY. > >> >>>>> > >> >>>>> Second, I think it is an SRC decision whether it needs a > further > >> >>>> offer-answer exchange. When sending the request containing the > >> >>>> metadata, the SRC must ensure that any references to media > >> >>>> description > >> labels are > >> >>>> consistent with the last SDP sent by the SRC - if not, the SRC > >can > >> >>>> initiate a further offer-answer exchange at the same time as > the > >> >>>> metadata transmission. > >> >>>>> > >> >>>>> Perhaps it is my imagination, but I thought we had on the > table > >> at one > >> >>>> time the notion of: > >> >>>>> - SRS sends snapshot request in an UPDATE request. > >> >>>>> - SRC sends medata in an UPDATE request (with offer if it > needs > >> to > >> >>>> change SDP, otherwise without). > >> >>>>> > >> >>>>> I have lost track of how we came to diverge from this simple > >> model. > >> >>>>> > >> >>>>> John > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> 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 > > > > > >---------------------------------------------------------------------- > -- > >------------------------------------------- > >CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > >confidential and proprietary information of Alcatel-Lucent and/or its > >affiliated entities. Access by the intended recipient only is > >authorized. Any liability arising from any party acting, or refraining > >from acting, on any information contained in this e-mail is hereby > >excluded. If you are not the intended recipient, please notify the > >sender immediately, destroy the original transmission and its > >attachments and do not disclose the contents to any other person, use > it > >for any purpose, or store or copy the information in any medium. > >Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > >and/or its affiliated entities. > > > >_______________________________________________ > >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