From gsalguei@cisco.com Tue May 1 16:07:57 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6037A21E808E for ; Tue, 1 May 2012 16:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 816jDv+tkx-Z for ; Tue, 1 May 2012 16:07:56 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id 236F921E8024 for ; Tue, 1 May 2012 16:07:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q41N7tOm015391 for ; Tue, 1 May 2012 16:07:55 -0700 (PDT) Received: from sjc-vpn6-404.cisco.com (sjc-vpn6-404.cisco.com [10.21.121.148]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q41N7tlh016293 for ; Tue, 1 May 2012 16:07:55 -0700 (PDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 May 2012 19:07:54 -0400 References: <77659F77-CB15-4681-95F2-691B5B572277@cisco.com> To: insipid@ietf.org Message-Id: <2E1B9138-29A7-457F-A3F7-7E9E9D14976E@cisco.com> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [Insipid] Fwd: INSIPID Virtual Interim Doodle Poll X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 23:07:57 -0000 Folks: Friendly reminder to indicate availability dates for the INSIPID = Virtual Interim meeting. Cheers, Gonzalo Begin forwarded message: > From: Gonzalo Salgueiro > Subject: [Insipid] INSIPID Virtual Interim Doodle Poll > Date: April 27, 2012 12:52:01 AM EDT > To: insipid@ietf.org >=20 > Folks -=20 >=20 > As decided at IETF83 the INSIPID WG is planning a virtual interim = meeting to discuss and make progress on finalizing the list of = requirements for the end-to-end session identifier. I was pleased to = see James Polk started individual discussions on the alias for each = requirement. My hope is that we are able to make good progress on the = list so we can be as efficient as possible at the interim meeting. = Please indicate your preferences by the end of Thursday, May 3. I have = added a diverse selection of days/times to accommodate most. If you = think other times should be added to the poll, let the chairs knows. >=20 > This will be a 2 hour long webex meeting (I'll send out meeting = details once we converge on a date/time). >=20 > Please indicate your availability at: >=20 >=20 > http://www.doodle.com/sfdpmipnhtqtxn6e >=20 >=20 > The times specified on the poll are EDT but it should be intelligent = enough to translate to your local time. >=20 > Cheers, >=20 > Gonzalo > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From pravindran@sonusnet.com Wed May 2 05:26:29 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEED21F84B6 for ; Wed, 2 May 2012 05:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 vyszCC1wGDAl for ; Wed, 2 May 2012 05:26:29 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 74C3B21F84B5 for ; Wed, 2 May 2012 05:26:28 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT6En9PlFieXdSt0o+Xc7la27j4jGtCv+@postini.com; Wed, 02 May 2012 05:26:28 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 2 May 2012 08:26:33 -0400 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.0355.002; Wed, 2 May 2012 17:56:23 +0530 From: "Ravindran, Parthasarathi" To: Laura Liess Thread-Topic: [Insipid] Comment on REQ1, REQ6 and REQ7 Thread-Index: AQHNI7OBxm6Ux2YUtUeiPceD7Rb+H5atBd0AgAFG9ACAAHo48IAES82AgANiyHA= Date: Wed, 2 May 2012 12:26:22 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1489453F@inba-mail02.sonusnet.com> References: <06bb01cd23d4$bcd5a790$3680f6b0$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23AC3B@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: [10.70.54.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Paul E. Jones" , "insipid@ietf.org" , =?utf-8?B?TWFydGluIEjDvGxzZW1hbm4=?= , Hadriel Kaplan Subject: Re: [Insipid] Comment on REQ1, REQ6 and REQ7 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 12:26:29 -0000 TGF1cmEsDQoNCllvdXIgcHJvcG9zYWwgKDEpIGxvb2tzIGdvb2QgYXMgZm9sbG93czoNCg0KIlJF UTY6IFRoZSBpZGVudGlmaWVyIG11c3Qgbm90IHJldmVhbCB0byB0aGUgcmVjZWl2ZXIgb2YgaXQg dGhlDQogICBDYWxsLUlELCB0YWdzLCBvciBhbnkgb3RoZXIgU0lQIGhlYWRlciBvciBib2R5IHBv cnRpb24uICINCg0KVGhhbmtzDQpQYXJ0aGENCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogTGF1cmEgTGllc3MgW21haWx0bzpsYXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNv bV0NCj5TZW50OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDc6NDIgUE0NCj5UbzogUmF2aW5kcmFu LCBQYXJ0aGFzYXJhdGhpDQo+Q2M6IFBhdWwgRS4gSm9uZXM7IGluc2lwaWRAaWV0Zi5vcmc7IE1h cnRpbiBIw7xsc2VtYW5uOyBIYWRyaWVsIEthcGxhbg0KPlN1YmplY3Q6IFJlOiBbSW5zaXBpZF0g Q29tbWVudCBvbiBSRVExLCBSRVE2IGFuZCBSRVE3DQo+DQo+SGkgUGFydGhhLA0KPg0KPiAgPiBS RVEtNiBpcyBpbXBvcnRhbnQgdG8gYXZvaWQgdXNpbmcgU2Vzc2lvbi1pZCBiZWluZyB1c2VkIGFz IHJhdGhvbGUNCj5mb3IgcGFzc2luZyBhbnkgaW5mb3JtYXRpb24uIElNTywgaXQgaXMgaW1wb3J0 YW50Lg0KPg0KPklmIEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50IGNvcnJlY3RseSwgeW91IGRvbid0 IHdhbnQgVXNlciBBIGJlaW5nIGFibGUNCj50byB0cmFuc21pdCBzb21lIGNyaXRpY2FsIGluZm9y bWF0aW9uIHRvIFVzZXIgQiBpbiB0aGUgU2Vzc2lvbi1JRC1oZWFkZXINCj53aXRob3V0IHRoZSBC MkJVQSBiZXR3ZWVuIHRoZW0gIGJlaW5nIGFibGUgdG8gZmlsdGVyIG91dCB0aGlzIGNyaXRpY2Fs DQo+aW5mb3JtYXRpb24uIElzIHRoaXMgY29ycmVjdD8NCj4NCj5JZiB5ZXMsIEkgd291bGQgcHJv cG9zZSB0byBtb2RpZnkgdGhlIHJlcXVpcmVtZW50IHRvDQo+DQo+MS4gIlJFUTY6IFRoZSBpZGVu dGlmaWVyIG11c3Qgbm90IHJldmVhbCB0byB0aGUgcmVjZWl2ZXIgb2YgaXQgdGhlDQo+ICAgQ2Fs bC1JRCwgdGFncywgb3IgYW55IG90aGVyIFNJUCBoZWFkZXIgb3IgYm9keSBwb3J0aW9uLiAiDQo+ DQo+b3IgcmVzdHJpY3QgdGhlIHJlcXVpcmVtZW50cyB0byBlbmQgZGV2aWNlczoNCj4NCj4yLiAi UkVRNjogVGhlIGlkZW50aWZpZXIgbXVzdCBub3QgcmV2ZWFsIHRvIGVuZCBkZXZpY2VzIHRoYXQg dGhlDQo+ICAgQ2FsbC1JRCwgdGFncywgb3IgYW55IG90aGVyIFNJUCBoZWFkZXIgb3IgYm9keSBw b3J0aW9uIGhhdmUgYmVlbg0KPiAgIGNoYW5nZWQgYnkgbWlkZGxlYm94ZXMuIg0KPg0KPkNhbiB5 b3UgbGl2ZSB3aXRoIG9uZSBvZiB0aGVzZSBhbHRlcm5hdGl2ZXM/DQo+DQo+S2luZCByZWdhcmRz DQo+TGF1cmENCj4NCj4+DQo+PiBUaGFua3MNCj4+IFBhcnRoYQ0KPj4NCj4+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBpbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj5CZWhhbGYgT2YgTGF1cmEgTGllc3MN Cj4+PlNlbnQ6IEZyaWRheSwgQXByaWwgMjcsIDIwMTIgNjo0OCBQTQ0KPj4+VG86IFBhdWwgRS4g Sm9uZXMNCj4+PkNjOiBpbnNpcGlkQGlldGYub3JnOyBNYXJ0aW4gSMO8bHNlbWFubjsgSGFkcmll bCBLYXBsYW4NCj4+PlN1YmplY3Q6IFJlOiBbSW5zaXBpZF0gQ29tbWVudCBvbiBSRVExLCBSRVE2 IGFuZCBSRVE3DQo+Pj4NCj4+PlBhdWwsDQo+Pj4NCj4+PldoYXQgSSB0cmllZCB0byBzYXkgd2Fz IHRoYXQgSSB0aGluayB3ZSBjYW4gZHJvcCBSRVE2LiBSRVE1IGFuZCBSRUMxDQo+Pj5hcmUgaW1w b3J0YW50IGZvciB1cy4NCj4+Pg0KPj4+KFVuZm9ydHVuYXRlbHksIHRoZSB3YXMgZHJhd2luZyB3 aGljaCBhcnJpdmVkIGF0IHRoZSBtYWlsaW5nIGxpc3Qgd2FzDQo+Pj5ub3Qgd2hhdCBJIGludGVu ZGVkIHRvIHNlbmQuIFNvIHRoZSBleGFtcGxlIGlzIHF1aXRlIGRpZmZpY3VsdCB0bw0KPj4+dW5k ZXJzdGFuZC4pDQo+Pj4NCj4+PktpbmQgcmVnYXJkcw0KPj4+TGF1cmENCj4+Pg0KPj4+DQo+Pj4y MDEyLzQvMjYgUGF1bCBFLiBKb25lcyA8cGF1bGVqQHBhY2tldGl6ZXIuY29tPjoNCj4+Pj4gTGF1 cmEsDQo+Pj4+DQo+Pj4+IEkgYXNzdW1lIHRoZSBkZXNpcmUgZm9yIFJFUTYgcmVsYXRlcyB0byBl bnN1cmluZyB0aGUga2luZCBvZiBwcml2YWN5DQo+Pj50aGF0IGlzIGFmZm9yZGVkIGJ5IFNCQ3Mu IMKgVGhleSBjYW4gaGlkZSBuZXR3b3JrIHRvcG9sb2dpZXMsIHBlZXJpbmcNCj4+PnJlbGF0aW9u cywgZXRjLiDCoFRoaXMgcmVxdWlyZW1lbnRzIHN1Z2dlc3RzIHRoYXQgd2UgZG8gbm90IHdhbnQg dGhvc2UNCj4+PnRoaW5ncyBkaXNjbG9zZWQgdmlhIHRoZSBTZXNzaW9uLUlELg0KPj4+Pg0KPj4+ PiBSRVE3IGlzIGEgbWVhbnMgb2YgYXNzaWduaW5nIGFuIElEIHdoZW4gdGhlIGVuZHBvaW50IGRv ZXMgbm90LiDCoFRoYXQNCj4+PndvdWxkIHBlcmhhcHMgbWVhbiBvbmUgY2Fubm90IGluc3BlY3Qg YWxsIHRoZSB3YXkgdG8gdGhlIGVuZHBvaW50LCBidXQNCj4+Pm9uZSBjYW4gYXQgbGVhc3QgdHJh Y2sgc2Vzc2lvbnMgdG8gdGhlIGFzc2lnbmluZyBlbGVtZW50Lg0KPj4+Pg0KPj4+PiBSRVExIHNl ZW1zIGNvbmZsaWN0aW5nIG9uIHRoZSBzdXJmYWNlLCBidXQgb25lIG1heSBub3QgYWx3YXlzIGhh dmUNCj4+PmFjY2VzcyBpbnRvIGV2ZXJ5IHNlZ21lbnQgZXZlcnl3aGVyZS4gwqBUaG9zZSB0b3Bv bG9naWVzIGFuZCBidXNpbmVzcw0KPj4+cmVsYXRpb25zaGlwcyByZW1haW4gaGlkZGVuLiDCoEV2 ZW4gc28sIGl0J3MgcG9zc2libGUgdG8gcGVyaGFwcyBoYXZlDQo+Pj5tdWx0aXBsZSBwZW9wbGUg YW5kIG9yZ2FuaXphdGlvbnMgdGFsa2luZyBhYm91dCB0aGUgc2FtZSBTZXNzaW9uLUlELA0KPj4+ cmVnYXJkbGVzcyBvZiB3aGF0IG90aGVyIGRhdGEgaXMgY2hhbmdlZC4NCj4+Pj4NCj4+Pj4gSW4g c2hvcnQsIEkgZG9uJ3QgdGhpbmsgaXQgbWF0dGVycyBpZiBzb21ldGhpbmcgY2FuIGRldGVybWlu ZQ0KPj4+PiBjaGFuZ2VzDQo+Pj5tYWRlIGJ5IHRoZSBCMkJVQSBpZiBpdCdzIHRoYXQgc29tZXRo aW5nIGlzIGluIGEgcG9zaXRpb24gdG8gZG8gc28NCj4+PihlLmcuLCBoYXMgcGh5c2ljYWwgYWNj ZXNzIHRvIGFsbCBuZXR3b3JrIHNlZ21lbnRzKSwgYnV0IHRoZSBBUyBzaG91bGQNCj4+Pm5vdCBi ZSBhYmxlIHRvIHNlZSB0aGF0IENhcnJpZXIgQSBwZWVyZWQgd2l0aCBDYXJyaWVyIEIgb3Igc29t ZSBzdWNoDQo+Pj5vciB0aGF0IHRoZSBjYWxsZXIgaXMgdXNpbmcgTW9iaWxlIE9wZXJhdG9yIEMu DQo+Pj4+DQo+Pj4+IFBhdWwNCj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+PiBGcm9tOiBMYXVyYSBMaWVzcyBbbWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1h aWwuY29tXQ0KPj4+Pj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDI2LCAyMDEyIDk6NTAgQU0NCj4+ Pj4+IFRvOiBpbnNpcGlkQGlldGYub3JnOyBQYXVsIEpvbmVzOyBIYWRyaWVsIEthcGxhbg0KPj4+ Pj4gQ2M6IE1hcnRpbiBIw7xsc2VtYW5uDQo+Pj4+PiBTdWJqZWN0OiBDb21tZW50IG9uIFJFUTEs IFJFUTYgYW5kIFJFUTcNCj4+Pj4+DQo+Pj4+PiBIaSwNCj4+Pj4+DQo+Pj4+PiBXaGF0IGlzIHRo ZSByZWFzb24gZm9yIGhhdmluZyBSRVE2PyDCoERvIHdlIHJlYWx5IG5lZWQgaXQ/IEl0IHNlZW1z DQo+Pj4+PiB0byBtZSB0aGF0IGl0IHdpbGwgYmUgZGlmZmljdWx0IHRvIGZ1bGZpbGwgYWxsIFJF UTEgYW5kIFJFUTYgYW5kDQo+Pj4+PiBSRVE3IGF0IHRoZSBzYW1lIHRpbWUuDQo+Pj4+Pg0KPj4+ Pj4gVGFrZSB0aGUgZm9sbG93aW5nIHNjZW5hcmlvOg0KPj4+Pj4NCj4+Pj4+IMKgIMKgIC0tLS0t LS0tLS0tDQo+Pj4+PiAtLS0tLS0tLS0tLS0tIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLS0tLS0tLS0tLS0NCj4+Pj4+IMKgIMKgfCDCoCDCoEEg wqAgwqAgfCAtLS0tLS0tLS1DYWxsLUlEIHgtLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgQjJCVUEN Cj4+Pj4+IHwtLS0tLS0tLS0tLS0tQ2FsbC1JRCB5LS0tLS0tLT58IMKgIMKgQVMgwqAgfC0tLS0t LS0tDQo+Pj4+PiDCoCDCoCAtLS0tLS0tLS0tLQ0KPj4+Pj4gLS0tLS0tLS0tLS0tLSDCoCDCoCDC oCDCoCDCoCDCoCDCoFNlc3Npb24tSUQgeiDCoCDCoC0tLS0tLS0tLS0tDQo+Pj4+Pg0KPj4+Pj4g QSBpcyBhbiBlbmQgZGV2aWNlIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBTZXNzaW9uLUlELiDCoEFT IGlzIGFuDQo+Pj4+PiBBcHBsaWNhdGlvbiBTZXJ2ZXIgYW5kIGluIHRoZSBjb250ZXh0IG9mIFJF UTYgdGhlIHJlY2VpdmVyIG9mIHRoZQ0KPj4+Pj4gU2Vzc2lvbi1JRC4gVGhlIEIyQlVBIGNoYW5n ZXMgdGhlIENhbGwtSUQgZnJvbSB4IHRvIHkgYW5kDQo+Pj4+PiBjYWxjdWxhdGVzDQo+Pj5hIFNl c3Npb24tSUQgei4NCj4+Pj4+IEJ5IFJFUTEgYW5kIFJFUTcsIGFuIGV4dGVybmFsIGRldmljZSBt b25pdG9yaW5nIHRoZSBTSVAtdHJhZmZpYw0KPj4+Pj4gbXVzdCBiZSBhYmxlIHRvIGZpbmQgb3V0 IHRoYXQgbWVzc2FnZXMgd2l0aCB0aGUgQ2FsbC1JRCB4IGFuZA0KPj4+Pj4gbWVzc2FnZXMgd2l0 aCB0aGUgU2Vzc2lvbi1JRCB6IGJlbG9uZyB0byB0aGUgc2FtZSBzZXNzaW9uLiBTbyB0aGUNCj4+ Pj4+IEIyQlVBIG11c3QgYnVpbGQgeiBhcyBhIGZ1bmN0aW9uIG9mIHgsIGxldCdzIHNheSB6ID1G KHgpIGFuZCB0aGUNCj4+Pj4+IG1vbml0b3JpbmcgdGhlIEIyQlVBIGFuZCB0aGUgbW9uaXRvcmlu ZyBzeXN0ZW0gaGF2ZSB0byBrbm93IEYuDQo+Pj4+PiBPdGhlcndpc2UsIMKgYnkgUkVRNiwgdGhl IEFTIGlzIG5vdCBhbGxvd2VkIHRvIGtub3cgRiwgb3RoZXJ3aXNlIGhlDQo+Pj4+PiBpcyBhYmxl IHRvIGZpbmQgb3V0IHRoYXQgeiAvPSBGKHkpLg0KPj4+Pj4gTWF5YmUgaXQgaXMgaW4gdGhlb3Jl dGljYWx5IHBvc3NpYmxlIGZvciBhIG5ldHdvcmsgdG8gaGF2ZSBhIGZvcg0KPj4+Pj4gZWFjaCBu b2RlIGEgZGlmZmVyZW50IEYgYW5kIHRoZSB0aGUgbW9uaXRvcmluZyBzeXN0ZW1zIGtub3dpbmcN Cj4+Pj4+IHdoaWNoIEYgdG8gdXNlIGZvciBhIGNhbGwgbGVnLCBidXQgaW4gcHJhY3RpY2UgdGhp cyBpcyBwcm9iYWJseSB0b28NCj5jb21wbGV4Lg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywNCj4+Pj4+ IExhdXJhDQo+Pj4+DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+aW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4+Pmluc2lwaWRAaWV0Zi5vcmcNCj4+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZA0K From laura.liess.dt@googlemail.com Thu May 3 02:01:42 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BEF21F854B for ; Thu, 3 May 2012 02:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0y0sxPTatjB for ; Thu, 3 May 2012 02:01:41 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A721F8546 for ; Thu, 3 May 2012 02:01:41 -0700 (PDT) Received: by ggmi1 with SMTP id i1so205469ggm.31 for ; Thu, 03 May 2012 02:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=px3vUdx9GtpHtxEaUko94Jx1SQ2bO2FiE+pYYkr6Lc0=; b=RENecc/M7QmXHBizHgTfyrWjVDZtnDPXs1KiCEXSSt2AkzhP2XOD+bNT//ov4lyeWr UQwKJf1kidPrOngiajCkf+OO2/qzKgSsIWyJhW8vxYruikGSLVoLG8zEoOl/t/64Ii8g t+IbdGHClBd43RoYTvtAxNIJYt+H6PXMH8CstiNHbLuZAvy7R9xnUClvMiGOuj7mxrM4 nTnNRD5JRrAocu3rg+65cNhDHNCGG8qI8gvL0giNj0HDK/pYQ+USbJhUmbq6xLaRvgMc utGhF24sasN49dJ3CskX7KEwYLxJg957lryUUuDhxp010XcZMUge/OEga2w57YisKnK4 ntbw== MIME-Version: 1.0 Received: by 10.236.76.41 with SMTP id a29mr1689973yhe.117.1336035701254; Thu, 03 May 2012 02:01:41 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Thu, 3 May 2012 02:01:41 -0700 (PDT) In-Reply-To: <4F9E93F1.9070803@packetizer.com> References: <201204262007.q3QK73AU007837@mtv-core-4.cisco.com> <4F9E93F1.9070803@packetizer.com> Date: Thu, 3 May 2012 11:01:41 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "James M. Polk" , "insipid@ietf.org" , =?UTF-8?Q?Martin_H=C3=BClsemann?= Subject: Re: [Insipid] INSIPID Req#6 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 09:01:42 -0000 Paul, We had a parallel discussion on this issue and agreed to change the REQ-6 as follows: "REQ6: The identifier must not reveal to the receiver of it the Call-ID, tags, or any other SIP header or body portion. " This requirement still ensures topologies and peering relationships remain protected, but it is easier to comply to it than the REQ6 in its current form. Would this be OK for you? See http://www.ietf.org/mail-archive/web/insipid/current/msg00079.html Thanks, Laura 2012/4/30 Paul E. Jones : > I thought somebody replied on this one. =C2=A0In any case, the intent is = to not > reveal to the world that a call has passed through an SBC. I assume this = is > to ensure topologies and peering relationships remain protected. > > Paul > > > On 4/27/2012 9:07 AM, Laura Liess wrote: >> >> Hi, >> >> The benefit of having this requirement is not clear to me. What may >> happen if we do not have it? >> We have REQ5, which ensure hiding of every kid of device identity, in >> order to avoid B2BUAs to change the Session-ID. REQ5 is important. But >> REQ6? If we can not find out what the reason for it is, I propose to >> drop it, because having REQ6 =C2=A0may complicate the solution, I think. >> >> Thanks >> Laura >> >> 2012/4/26 James M. Polk: >>> >>> Figure it is about time I sent these requirements out to the list. >>> Comments, >>> questions and wordsmithing are encouraged. Let's see if we can leave mu= ch >>> of >>> the wordsmithing till the end of the discussion, once we have agreed on >>> the >>> requirement's worthiness and contents. >>> >>> Let's also keep the discussion on *this* thread to just *this* >>> requirement >>> for tracking purposes. There are 9 current requirements. Therefore, the= re >>> will be 9 different messages sent to this list. >>> >>> Here is REQ#6 as currently written in >>> >>> http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqt= s-00.txt >>> >>> =C2=A0 REQ6: The identifier must not reveal to the receiver of it >>> =C2=A0 that the Call-ID, tags, or any other SIP header or body >>> =C2=A0 portion have been changed by middleboxes, with as high a >>> =C2=A0 probability as possible. >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > From paulej@packetizer.com Thu May 3 06:29:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F225F21F85A0 for ; Thu, 3 May 2012 06:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, 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 i5U2LjSx+F7P for ; Thu, 3 May 2012 06:29:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D90DA21F8595 for ; Thu, 3 May 2012 06:29:57 -0700 (PDT) Received: from [156.106.246.73] ([156.106.246.73]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q43DTrsd018326 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 May 2012 09:29:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336051795; bh=F3wWcRi/JxNB2NwiVWx4vnDrOcyP0QZAIAiGmMTM5hc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=suitBCtHT66cSSNL96w29p1wjsc1SQiDpKB/7jwe4AjNFoC0+eaLZrgliIs3OKQiL gcsFFa9peAWcuyyXq7QvO7KgX9VmpKSc7zYm43g91dFfsf2F8IUhqIDWcvX4iDOiWp HoRSSJTUlblgSPEUuaYEQaEe0mZGvQbUCoCdQ+bE= Message-ID: <4FA28855.7030503@packetizer.com> Date: Thu, 03 May 2012 09:29:57 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Laura Liess References: <201204262007.q3QK73AU007837@mtv-core-4.cisco.com> <4F9E93F1.9070803@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030908030003010300000000" Cc: "James M. Polk" , "insipid@ietf.org" , =?UTF-8?B?TWFydGluIEjDvGxzZW1hbm4=?= Subject: Re: [Insipid] INSIPID Req#6 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 13:29:59 -0000 This is a multi-part message in MIME format. --------------030908030003010300000000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Laura, No objection. Just trying to make this requirement a little easier to read, I re-ordered it a little. How does this sound? REQ6: The identifier must not reveal the Call-ID, tags, or any other SIP header or body portion to the receiver. Paul On 5/3/2012 5:01 AM, Laura Liess wrote: > Paul, > > We had a parallel discussion on this issue and agreed to change the > REQ-6 as follows: > > "REQ6: The identifier must not reveal to the receiver of it the > Call-ID, tags, or any other SIP header or body portion. " > > This requirement still ensures topologies and peering relationships > remain protected, but it is easier to comply to it than the REQ6 in > its current form. > > Would this be OK for you? > > See http://www.ietf.org/mail-archive/web/insipid/current/msg00079.html > > Thanks, > Laura > > 2012/4/30 Paul E. Jones: >> I thought somebody replied on this one. In any case, the intent is to not >> reveal to the world that a call has passed through an SBC. I assume this is >> to ensure topologies and peering relationships remain protected. >> >> Paul >> >> >> On 4/27/2012 9:07 AM, Laura Liess wrote: >>> Hi, >>> >>> The benefit of having this requirement is not clear to me. What may >>> happen if we do not have it? >>> We have REQ5, which ensure hiding of every kid of device identity, in >>> order to avoid B2BUAs to change the Session-ID. REQ5 is important. But >>> REQ6? If we can not find out what the reason for it is, I propose to >>> drop it, because having REQ6 may complicate the solution, I think. >>> >>> Thanks >>> Laura >>> >>> 2012/4/26 James M. Polk: >>>> Figure it is about time I sent these requirements out to the list. >>>> Comments, >>>> questions and wordsmithing are encouraged. Let's see if we can leave much >>>> of >>>> the wordsmithing till the end of the discussion, once we have agreed on >>>> the >>>> requirement's worthiness and contents. >>>> >>>> Let's also keep the discussion on *this* thread to just *this* >>>> requirement >>>> for tracking purposes. There are 9 current requirements. Therefore, there >>>> will be 9 different messages sent to this list. >>>> >>>> Here is REQ#6 as currently written in >>>> >>>> http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt >>>> >>>> REQ6: The identifier must not reveal to the receiver of it >>>> that the Call-ID, tags, or any other SIP header or body >>>> portion have been changed by middleboxes, with as high a >>>> probability as possible. >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid --------------030908030003010300000000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Laura,

No objection.  Just trying to make this requirement a little easier to read, I re-ordered it a little.  How does this sound?

REQ6: The identifier must not reveal the Call-ID, tags, or any other SIP header or body portion to the receiver.

Paul


On 5/3/2012 5:01 AM, Laura Liess wrote: 
Paul,

We had a parallel discussion on this issue and agreed to change the
REQ-6 as follows:

 "REQ6: The identifier must not reveal to the receiver of it the
 Call-ID, tags, or any other SIP header or body portion. "

This requirement still ensures topologies and peering relationships
remain protected, but it is easier to comply to it than the REQ6 in
its current form.

Would this be OK for you?

See http://www.ietf.org/mail-archive/web/insipid/current/msg00079.html

Thanks,
Laura

2012/4/30 Paul E. Jones <paulej@packetizer.com>:

I thought somebody replied on this one.  In any case, the intent is to not
reveal to the world that a call has passed through an SBC. I assume this is
to ensure topologies and peering relationships remain protected.

Paul


On 4/27/2012 9:07 AM, Laura Liess wrote:

Hi,

The benefit of having this requirement is not clear to me. What may
happen if we do not have it?
We have REQ5, which ensure hiding of every kid of device identity, in
order to avoid B2BUAs to change the Session-ID. REQ5 is important. But
REQ6? If we can not find out what the reason for it is, I propose to
drop it, because having REQ6  may complicate the solution, I think.

Thanks
Laura

2012/4/26 James M. Polk<jmpolk@cisco.com>:

Figure it is about time I sent these requirements out to the list.
Comments,
questions and wordsmithing are encouraged. Let's see if we can leave much
of
the wordsmithing till the end of the discussion, once we have agreed on
the
requirement's worthiness and contents.

Let's also keep the discussion on *this* thread to just *this*
requirement
for tracking purposes. There are 9 current requirements. Therefore, there
will be 9 different messages sent to this list.

Here is REQ#6 as currently written in

http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt

  REQ6: The identifier must not reveal to the receiver of it
  that the Call-ID, tags, or any other SIP header or body
  portion have been changed by middleboxes, with as high a
  probability as possible.
_______________________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid

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



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

--------------030908030003010300000000-- From brett@broadsoft.com Thu May 3 07:10:27 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD90421F858D for ; Thu, 3 May 2012 07:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHuwW3VNz8lO for ; Thu, 3 May 2012 07:10:21 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1150E21F8476 for ; Thu, 3 May 2012 07:10:21 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 3 May 2012 07:12:29 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 3 May 2012 07:12:24 -0700 From: Brett Tate To: "insipid@ietf.org" Date: Thu, 3 May 2012 07:10:13 -0700 Thread-Topic: [Insipid] INSIPID Req#2 - comments? Thread-Index: Ac0j6G0SV1FjUmPnQBu/VsbqvnBmVgFQSxfg Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> In-Reply-To: <201204262006.q3QK6isF007654@mtv-core-4.cisco.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: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:10:27 -0000 > REQ2: It must be possible to identify the end-to-end session > when a session is transferred or if two different sessions > are joined together via an intermediary (e.g., a PBX). As worded, this requirement appears to cause the session identifier to be r= enegotiated and/or changed within a dialog. For instance, a B2BUA is aware of two separate session identifiers: X1A and= X2B. X1 is connected to A through B2BUA; X2 is connected to B through B2B= UA. The B2BUA is stimulated to connect A part of X1A to B part of X2B using= existing dialogs (and releasing the other halves of the dialogs because X = is dropping out). Does the requirement cause the session identifier to be = changed and/or renegotiated when the B2BUA connects the two already existin= g dialogs? From gsalguei@cisco.com Thu May 3 07:20:22 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B2121F858A for ; Thu, 3 May 2012 07:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GF-Pvrq8Gg1 for ; Thu, 3 May 2012 07:20:21 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id AD12621F854B for ; Thu, 3 May 2012 07:20:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q43EKKAd004025 for ; Thu, 3 May 2012 07:20:20 -0700 (PDT) Received: from sjc-vpn5-766.cisco.com (sjc-vpn5-766.cisco.com [10.21.90.254]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q43EKKhd006363 for ; Thu, 3 May 2012 07:20:20 -0700 (PDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 May 2012 10:19:40 -0400 References: <77659F77-CB15-4681-95F2-691B5B572277@cisco.com> To: insipid@ietf.org Message-Id: <24B03CB8-C8F8-4199-9FD3-E7DFD07CE186@cisco.com> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [Insipid] Fwd: INSIPID Virtual Interim Doodle Poll X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:20:22 -0000 Final reminder that poll closes today for indicating availability for a = date for an INSIPID virtual interim meeting. Cheers, Gonzalo Begin forwarded message: > From: Gonzalo Salgueiro > Subject: [Insipid] INSIPID Virtual Interim Doodle Poll > Date: April 27, 2012 12:52:01 AM EDT > To: insipid@ietf.org >=20 > Folks -=20 >=20 > As decided at IETF83 the INSIPID WG is planning a virtual interim = meeting to discuss and make progress on finalizing the list of = requirements for the end-to-end session identifier. I was pleased to = see James Polk started individual discussions on the alias for each = requirement. My hope is that we are able to make good progress on the = list so we can be as efficient as possible at the interim meeting. = Please indicate your preferences by the end of Thursday, May 3. I have = added a diverse selection of days/times to accommodate most. If you = think other times should be added to the poll, let the chairs knows. >=20 > This will be a 2 hour long webex meeting (I'll send out meeting = details once we converge on a date/time). >=20 > Please indicate your availability at: >=20 >=20 > http://www.doodle.com/sfdpmipnhtqtxn6e >=20 >=20 > The times specified on the poll are EDT but it should be intelligent = enough to translate to your local time. >=20 > Cheers, >=20 > Gonzalo > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From paulej@packetizer.com Fri May 4 02:06:33 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27A621F853B for ; Fri, 4 May 2012 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, SARE_OBFU_ALL=0.751] 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 lNXT9ntITGOe for ; Fri, 4 May 2012 02:06:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EED7721F86E2 for ; Fri, 4 May 2012 02:06:32 -0700 (PDT) Received: from [156.106.218.124] ([156.106.218.124]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q4496SxP017470 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 May 2012 05:06:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336122390; bh=wbKSMm4ti9vbZgCGtCgZ4PMQ/sn6y/g6t1D7JW+EuX0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oos+DrZeQcsVAfA6eOTebMSDjHs1hficKwP5tSgfFs2FA7cG/UmZefzF2JrVrIdj4 Rp2zJ97Fz1E+iAFBlPYakCCMP39f6yaLX1nvg9ZjrPukJrZuyGrZXFpi8vIyHCMF/Y eO1C3UWVjLhL8SfH++8VwL0/dEfkX7m7F+Sj/BLc= Message-ID: <4FA39C1A.4030709@packetizer.com> Date: Fri, 04 May 2012 05:06:34 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brett Tate References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" Subject: Re: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:06:33 -0000 Brett, I did not fully follow your example, but when a call is joined with another, the session identifiers may (and likely will) change. I'd argue they must, actually. If Alice calls Bob, there would be some Session-ID X. If Carol calls Bob, there would be some Session-ID Y. Now, if Bob does something such that Alice and Carol are now communicating directly, the Session-ID for either or both Alice and Carol must change. If the ID did not change, then we would not be able to identify the session end-to-end. Without change, Alice would think the ID is X and Carol would think the ID is Y. The two ends should have a common understanding of what the Session-ID is. There are a few ways to accomplish this and we've proposed one in our draft. What we proposed is that Alice would have a UUID that is unique to her and Bob would have one unique to him. Likewise Carol would have a unique UUID. These are unique per SIP session. So, following our solution proposal: If Alice calls Bob, there would be a Session-ID A||B1 (where || means order concatenation, but that's not so significant; we could keep these as separate components) If Carol calls Bob, there would be a Session-ID C||B2 (note Bob would not use the same value since these are separate SIP sessions) Now, if Bob does something such that Alice and Carol are now communicating directly, the Session-ID that both Alice and Carol would use is A||C. (Here, the value A and C did not change, but the Session-ID did since the two components changed. What is important is that both endpoints, Alice and Carol, have a common understanding of the Session-ID.) Paul On 5/3/2012 10:10 AM, Brett Tate wrote: >> REQ2: It must be possible to identify the end-to-end session >> when a session is transferred or if two different sessions >> are joined together via an intermediary (e.g., a PBX). > As worded, this requirement appears to cause the session identifier to be renegotiated and/or changed within a dialog. > > For instance, a B2BUA is aware of two separate session identifiers: X1A and X2B. X1 is connected to A through B2BUA; X2 is connected to B through B2BUA. The B2BUA is stimulated to connect A part of X1A to B part of X2B using existing dialogs (and releasing the other halves of the dialogs because X is dropping out). Does the requirement cause the session identifier to be changed and/or renegotiated when the B2BUA connects the two already existing dialogs? > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From brett@broadsoft.com Fri May 4 04:22:51 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030EB21F85ED for ; Fri, 4 May 2012 04:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_05=-1.11] 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 ZrbRjh+ZqOcg for ; Fri, 4 May 2012 04:22:49 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF0721F85A5 for ; Fri, 4 May 2012 04:22:49 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.161) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 4 May 2012 04:24:59 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 4 May 2012 04:24:59 -0700 From: Brett Tate To: "Paul E. Jones" , "insipid@ietf.org" Date: Fri, 4 May 2012 04:22:48 -0700 Thread-Topic: [Insipid] INSIPID Req#2 - comments? Thread-Index: Ac0p1YHAQL2SOcSHQZ+RY9UvdFxzxQACkGCQ Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> In-Reply-To: <4FA39C1A.4030709@packetizer.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: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 11:22:51 -0000 Thanks for the response. > I did not fully follow your example, but when a call is=20 > joined with another, the session identifiers may (and=20 > likely will) change. I'd argue they must, actually. Your interpretation/restatement of the example is correct (Bob equates to m= y example's X). My current understanding is that REQ2 is the requirement implying that the = session identifier must change. If so, I recommend REQ2 (or whichever requ= irement implies such a thing) be modified to explicitly indicate that meeti= ng the requirement may cause the session identifier to change within an exi= sting dialog. I recommend being explicit because it appears to go beyond t= he current charter. And if I recall correctly, it was one of the controver= sial topics during the chartering process. > >> REQ2: It must be possible to identify the end-to-end session > >> when a session is transferred or if two different sessions > >> are joined together via an intermediary (e.g., a PBX). From paulej@packetizer.com Fri May 4 06:14:22 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CB821F86A5 for ; Fri, 4 May 2012 06:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 HdK+RG72rfrI for ; Fri, 4 May 2012 06:14:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67021F86A2 for ; Fri, 4 May 2012 06:14:21 -0700 (PDT) Received: from [156.106.218.124] ([156.106.218.124]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q44DEGim024507 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 May 2012 09:14:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336137258; bh=vrYYIDJaTqwuLXOQraY8fG/v5CxsimXtaG/mBuFYkNU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dDVDl5geBgmHWeCV0gXDICLeZM20lieVlFAnF05JeL+PO1YXkosuNzSRc3HUVD3zo rG6N4AdgOhEu3IMCQTC5X/woGylHz/ISdmtamKEzM0ykZgWJfxxqr1gsGtGJKzFOpR psfpb46GthNs4ACA1+qGGu/uiytiuEOABI0caF6k= Message-ID: <4FA3D62D.4030709@packetizer.com> Date: Fri, 04 May 2012 09:14:21 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brett Tate References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" Subject: Re: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 13:14:22 -0000 While I'm not opposed to making an explicit statement that the ID must change, that's not the requirement. I believe it must change, but others may feel differently. The requirement is to be able to identify the session end-to-end, even when a call is transferred, joined, or otherwise subjected to mid-call interaction. If there is a way to do that without changing the value of the IDs, then we could meet the requirement. I can see where this would be possible with a typical transfer where the transferred-to party is not already in a call. The call join is the more challenging case. I don't think we should make it a requirement to change the ID. Changing the ID might be a part of the solution, but I don't see why the solution should dictate the requirements. Paul On 5/4/2012 7:22 AM, Brett Tate wrote: > Thanks for the response. > >> I did not fully follow your example, but when a call is >> joined with another, the session identifiers may (and >> likely will) change. I'd argue they must, actually. > Your interpretation/restatement of the example is correct (Bob equates to my example's X). > > My current understanding is that REQ2 is the requirement implying that the session identifier must change. If so, I recommend REQ2 (or whichever requirement implies such a thing) be modified to explicitly indicate that meeting the requirement may cause the session identifier to change within an existing dialog. I recommend being explicit because it appears to go beyond the current charter. And if I recall correctly, it was one of the controversial topics during the chartering process. > > >>>> REQ2: It must be possible to identify the end-to-end session >>>> when a session is transferred or if two different sessions >>>> are joined together via an intermediary (e.g., a PBX). From keith.drage@alcatel-lucent.com Fri May 4 07:09:18 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAF721F87A8 for ; Fri, 4 May 2012 07:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.941 X-Spam-Level: X-Spam-Status: No, score=-107.941 tagged_above=-999 required=5 tests=[AWL=-1.692, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea6raAPrTj8q for ; Fri, 4 May 2012 07:09:17 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7A62521F8799 for ; Fri, 4 May 2012 07:09:17 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q44E8vgh025092 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 16:09:12 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 4 May 2012 16:09:09 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "insipid@ietf.org" Date: Fri, 4 May 2012 16:09:07 +0200 Thread-Topic: [Insipid] Proposed New Requirement: Marking for Logging Thread-Index: Ac0MP7WqoLijRuySQbySMYSbKIzcWwdvs2xg Message-ID: References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> <4F71F9CF.1090302@alum.mit.edu> In-Reply-To: <4F71F9CF.1090302@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:09:18 -0000 Coming in on this late. I think there are several steps in this discussion. 1) Is the session ID that INSIPID have to define sufficient to identify a t= racked call. The original dawes proposal created an entirely separate ident= ifier to identify such calls. Is that a better solution than using the sess= ion ID? Obviously if we agree the reuse of the session ID, we need to make sure it = is fit for purpose. 2) If session ID is used for this, then some tagging is required that says = something like, "log anything with this session id" at least at some point = in the session. That can either be integrated with the session id, or handl= ed as an entirely separate parameter. If it is integrated it certainly need= s to be done by INSIPID. If it is not then it could be, or it could be done= elsewhere. All this is of course dependent on whether people feel logging of specific = calls is a useful function. It is perfectly valid for the WG to say it is n= ot. As WG cochair, I am certainly interested in determining how much of this pe= ople are interested in working on, and how much they consider to be in scop= e fo the group. Keith -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 27 March 2012 18:33 To: insipid@ietf.org Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging I don't quite get this. It sounds like you are bundling two things that=20 don't need to be bundled: - the session-id - a request to log the call I see no need to couple those things. If you can mark the call to be=20 logged, and if it happens to have a sesson-id, then there will be data=20 about the call, including the session-id, in logs of all the systems=20 traversed. But you can still have session-ids without logging, and you=20 can have logging without session-ids. Thanks, Paul On 3/26/12 9:38 PM, Dawes, Peter, Vodafone Group wrote: > Hello James, All, > Thanks for presenting your requirements draft for the session identifier.= The requirement I propose to add is on slide 7 of my presentation in the I= NSIPID meeting materials (http://www.ietf.org/proceedings/83/slides/slides-= 83-insipid-1.pdf) as follows: > > "It must be possible to mark a session identifier as inserted for logging= purposes" > "...in order to keep network operations and maintenance steps and also SI= P entity data volume and processing load to practical levels when troublesh= ooting" > > Slides 1-6 illustrate the reasons behind this proposed requirement. > > Regards, > Peter > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Fri May 4 08:21:47 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1821F86C2 for ; Fri, 4 May 2012 08:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 TCJwcUt5RIF8 for ; Fri, 4 May 2012 08:21:45 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB9A21F8685 for ; Fri, 4 May 2012 08:21:42 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id 5oAE1j0041YDfWL58rMbej; Fri, 04 May 2012 15:21:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id 5rMh1j00p07duvL3grMiDz; Fri, 04 May 2012 15:21:42 +0000 Message-ID: <4FA3F401.2090907@alum.mit.edu> Date: Fri, 04 May 2012 11:21:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> <4F71F9CF.1090302@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:21:47 -0000 Keith, I agree with all you say below. But I'll also observe that if there is a desire to do this sort of logging, and if the session-id being worked on by insipid isn't suitable for the purpose, then it raises the question of whether every use of a "session id" requires a distinct id for that purpose. Thanks, Paul On 5/4/12 10:09 AM, DRAGE, Keith (Keith) wrote: > Coming in on this late. > > I think there are several steps in this discussion. > > 1) Is the session ID that INSIPID have to define sufficient to identify a tracked call. The original dawes proposal created an entirely separate identifier to identify such calls. Is that a better solution than using the session ID? > > Obviously if we agree the reuse of the session ID, we need to make sure it is fit for purpose. > > 2) If session ID is used for this, then some tagging is required that says something like, "log anything with this session id" at least at some point in the session. That can either be integrated with the session id, or handled as an entirely separate parameter. If it is integrated it certainly needs to be done by INSIPID. If it is not then it could be, or it could be done elsewhere. > > All this is of course dependent on whether people feel logging of specific calls is a useful function. It is perfectly valid for the WG to say it is not. > > As WG cochair, I am certainly interested in determining how much of this people are interested in working on, and how much they consider to be in scope fo the group. > > Keith > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 27 March 2012 18:33 > To: insipid@ietf.org > Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging > > I don't quite get this. It sounds like you are bundling two things that > don't need to be bundled: > - the session-id > - a request to log the call > > I see no need to couple those things. If you can mark the call to be > logged, and if it happens to have a sesson-id, then there will be data > about the call, including the session-id, in logs of all the systems > traversed. But you can still have session-ids without logging, and you > can have logging without session-ids. > > Thanks, > Paul > > On 3/26/12 9:38 PM, Dawes, Peter, Vodafone Group wrote: >> Hello James, All, >> Thanks for presenting your requirements draft for the session identifier. The requirement I propose to add is on slide 7 of my presentation in the INSIPID meeting materials (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf) as follows: >> >> "It must be possible to mark a session identifier as inserted for logging purposes" >> "...in order to keep network operations and maintenance steps and also SIP entity data volume and processing load to practical levels when troubleshooting" >> >> Slides 1-6 illustrate the reasons behind this proposed requirement. >> >> Regards, >> Peter >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >> > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From brett@broadsoft.com Fri May 4 08:47:09 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515DD21F85EF for ; Fri, 4 May 2012 08:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.469, 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 M+qkULNno4zU for ; Fri, 4 May 2012 08:47:08 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id D30B521F8577 for ; Fri, 4 May 2012 08:47:08 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 4 May 2012 08:49:17 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 4 May 2012 08:49:17 -0700 From: Brett Tate To: "Paul E. Jones" , "insipid@ietf.org" Date: Fri, 4 May 2012 08:47:06 -0700 Thread-Topic: [Insipid] INSIPID Req#2 - comments? Thread-Index: Ac0p+CfzgnhxKa5HQOuP5lHl5erJyQACKBdA Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> <4FA3D62D.4030709@packetizer.com> In-Reply-To: <4FA3D62D.4030709@packetizer.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: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:47:09 -0000 Thanks for the response. > While I'm not opposed to making an explicit statement=20 > that the ID must change, that's not the requirement. =20 > I believe it must change, but others may feel differently. As far as I know, "the ID must change" is currently an implied requirement = since nobody has communicated how REQ2 could be met (for the example) witho= ut the session identity changing within an existing dialog. > I don't think we should make it a requirement to change=20 > the ID. Changing the ID might be a part of the solution,=20 > but I don't see why the solution should dictate the=20 > requirements. I'm concerned that as the working group reviews the requirements draft, the= reviewers may not realize that an implied requirement/consequence of REQ2 = is that a B2BUA connecting/joining two existing dialogs would potentially r= esult in the session identifier changing within the dialog. I prefer that the topic be debated as part of the requirements process inst= ead of after the requirements draft becomes an RFC. This is mostly because= I prefer a non explicit "approved requirement" not subsequently be used as= justification to change session identifiers within a dialog (or justificat= ion for a more severe remedy to meet REQ2). >> REQ2: It must be possible to identify the end-to-end session >> when a session is transferred or if two different sessions >> are joined together via an intermediary (e.g., a PBX). From andrew.hutton@siemens-enterprise.com Wed May 9 03:43:20 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEA721F854B for ; Wed, 9 May 2012 03:43:20 -0700 (PDT) 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 6abR7sF5kIdr for ; Wed, 9 May 2012 03:43:19 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5497121F8513 for ; Wed, 9 May 2012 03:43:16 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id DB0FB23F04C4; Wed, 9 May 2012 12:43:14 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 9 May 2012 12:43:14 +0200 From: "Hutton, Andrew" To: "James M. Polk" , "insipid@ietf.org" Date: Wed, 9 May 2012 12:43:12 +0200 Thread-Topic: [Insipid] INSIPID Req#9 - comments? Thread-Index: Ac0j6FO+y8ca8ixYStuKBjxMKDlXngJ5tUAA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> In-Reply-To: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.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: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 10:43:20 -0000 Hi, Regarding the requirement for making the identifier suitable for transmissi= on in RTCP and the associated use case of associating signaling and media f= lows. I doubt that it is a good idea to attempt to include the same identifier in= the media/RTCP as the signaling as even if this is possible in some scenar= ios it is most likely not possible in many and will break in others. =20 Is it really a requirement for the identifier to be used to associate signa= ling with media personally I am thinking it is not. Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of James M. Polk > Sent: 26 April 2012 21:06 > To: insipid@ietf.org > Subject: [Insipid] INSIPID Req#9 - comments? >=20 > Figure it is about time I sent these requirements out to the list. > Comments, questions and wordsmithing are encouraged. Let's see if we > can leave much of the wordsmithing till the end of the discussion, > once we have agreed on the requirement's worthiness and contents. >=20 > Let's also keep the discussion on *this* thread to just *this* > requirement for tracking purposes. There are 9 current requirements. > Therefore, there will be 9 different messages sent to this list. >=20 > Here is REQ#9 as currently written in > http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id- > reqts-00.txt >=20 > REQ9: The identifier should be constructed in such a way as > to make it suitable for transmission in SIP, H.323, RSVP > [3], and RTCP [4]. >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Wed May 9 03:50:44 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BB421F8559 for ; Wed, 9 May 2012 03:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 9HEn31vw5+Ap for ; Wed, 9 May 2012 03:50:42 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 911B921F854E for ; Wed, 9 May 2012 03:50:41 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 0326223F04AC; Wed, 9 May 2012 12:50:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 9 May 2012 12:50:40 +0200 From: "Hutton, Andrew" To: Brett Tate , "Paul E. Jones" , "insipid@ietf.org" Date: Wed, 9 May 2012 12:50:38 +0200 Thread-Topic: [Insipid] INSIPID Req#2 - comments? Thread-Index: Ac0p+CfzgnhxKa5HQOuP5lHl5erJyQACKBdAAPQVo9A= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312A742B4A6@MCHP058A.global-ad.net> References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> <4FA3D62D.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> 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: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 10:50:44 -0000 Hi, I agree with Brett we need to get it out in the open in the requirements dr= afts that the identifier can change during a dialog and use transfer use ca= se to bring this requirement out. A 3PCC use case or two would also I think be appropriate. Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Brett Tate > Sent: 04 May 2012 16:47 > To: Paul E. Jones; insipid@ietf.org > Subject: Re: [Insipid] INSIPID Req#2 - comments? >=20 > Thanks for the response. >=20 > > While I'm not opposed to making an explicit statement > > that the ID must change, that's not the requirement. > > I believe it must change, but others may feel differently. >=20 > As far as I know, "the ID must change" is currently an implied > requirement since nobody has communicated how REQ2 could be met (for > the example) without the session identity changing within an existing > dialog. >=20 > >=20 > > I don't think we should make it a requirement to change > > the ID. Changing the ID might be a part of the solution, > > but I don't see why the solution should dictate the > > requirements. >=20 > I'm concerned that as the working group reviews the requirements draft, > the reviewers may not realize that an implied requirement/consequence > of REQ2 is that a B2BUA connecting/joining two existing dialogs would > potentially result in the session identifier changing within the > dialog. >=20 > I prefer that the topic be debated as part of the requirements process > instead of after the requirements draft becomes an RFC. This is mostly > because I prefer a non explicit "approved requirement" not subsequently > be used as justification to change session identifiers within a dialog > (or justification for a more severe remedy to meet REQ2). >=20 >=20 > >> REQ2: It must be possible to identify the end-to-end session > >> when a session is transferred or if two different sessions > >> are joined together via an intermediary (e.g., a PBX). >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed May 9 06:23:57 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1FA21F8600 for ; Wed, 9 May 2012 06:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 cPbBEwCYZhxK for ; Wed, 9 May 2012 06:23:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0D421F84FB for ; Wed, 9 May 2012 06:23:56 -0700 (PDT) Received: from [156.106.244.206] ([156.106.244.206]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q49DNnbP020919 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 May 2012 09:23:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336569831; bh=Dg8oneEq8k80X5Mc/EYuGCL4WojC8aaIi5seAF/g0Ao=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=jLyfDAKEqW/GRr68HAdXvobgdOo0Wa8nsTHp2DvnL+DcK6Om0vv29hItU/1zdGFWi plaEYeIn8ICd3Z2+WUpZXlw1rYgX/0QYMOcfLkSzho7maG33h4NfXwiYfSyA9hiCOB O0lxsGMZv/VS1F1Vf9D6Kjxz/mlKcJE8XHZWWHoc= Message-ID: <4FAA6FE5.7000808@packetizer.com> Date: Wed, 09 May 2012 09:23:49 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Hutton, Andrew" References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> <4FA3D62D.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> <101C6067BEC68246B0C3F6843BCCC1E312A742B4A6@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A742B4A6@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" , Brett Tate Subject: Re: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:23:57 -0000 While I'm not stubbornly opposed to making such an explicit statement in the requirements document, having such a requirement seems to be a solution, not a requirement. The requirement should not be to change an ID, but if the solution requires it to satisfy the requirement, then that's the solution. Perhaps someone can come up with some interesting idea not already considered that would not require a change in the IDs used. I doubt they can, but I'll never dismiss any possibility. In any case, changing the ID isn't a requirement, but an answer to the requirement. Paul On 5/9/2012 6:50 AM, Hutton, Andrew wrote: > Hi, > > I agree with Brett we need to get it out in the open in the requirements drafts that the identifier can change during a dialog and use transfer use case to bring this requirement out. > > A 3PCC use case or two would also I think be appropriate. > > Regards > Andy > > > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Brett Tate >> Sent: 04 May 2012 16:47 >> To: Paul E. Jones; insipid@ietf.org >> Subject: Re: [Insipid] INSIPID Req#2 - comments? >> >> Thanks for the response. >> >>> While I'm not opposed to making an explicit statement >>> that the ID must change, that's not the requirement. >>> I believe it must change, but others may feel differently. >> As far as I know, "the ID must change" is currently an implied >> requirement since nobody has communicated how REQ2 could be met (for >> the example) without the session identity changing within an existing >> dialog. >> >> >> >>> I don't think we should make it a requirement to change >>> the ID. Changing the ID might be a part of the solution, >>> but I don't see why the solution should dictate the >>> requirements. >> I'm concerned that as the working group reviews the requirements draft, >> the reviewers may not realize that an implied requirement/consequence >> of REQ2 is that a B2BUA connecting/joining two existing dialogs would >> potentially result in the session identifier changing within the >> dialog. >> >> I prefer that the topic be debated as part of the requirements process >> instead of after the requirements draft becomes an RFC. This is mostly >> because I prefer a non explicit "approved requirement" not subsequently >> be used as justification to change session identifiers within a dialog >> (or justification for a more severe remedy to meet REQ2). >> >> >>>> REQ2: It must be possible to identify the end-to-end session >>>> when a session is transferred or if two different sessions >>>> are joined together via an intermediary (e.g., a PBX). >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Wed May 9 06:30:44 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2222D21F85C9 for ; Wed, 9 May 2012 06:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.89 X-Spam-Level: X-Spam-Status: No, score=-109.89 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 hS0N8OEPJqEC for ; Wed, 9 May 2012 06:30:43 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id F14CD21F85B7 for ; Wed, 9 May 2012 06:30:42 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q49DU3lp018054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 May 2012 15:30:38 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 9 May 2012 15:30:35 +0200 From: "DRAGE, Keith (Keith)" To: Gonzalo Salgueiro , "insipid@ietf.org" Date: Wed, 9 May 2012 15:30:34 +0200 Thread-Topic: [Insipid] Fwd: INSIPID Virtual Interim Doodle Poll Thread-Index: Ac0n70R8sLtP2oybRgSz/SpGt8ZV4wF+FP0Q Message-ID: References: <77659F77-CB15-4681-95F2-691B5B572277@cisco.com> <2E1B9138-29A7-457F-A3F7-7E9E9D14976E@cisco.com> In-Reply-To: <2E1B9138-29A7-457F-A3F7-7E9E9D14976E@cisco.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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Insipid] Fwd: INSIPID Virtual Interim Doodle Poll X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:30:44 -0000 We will be using the slot on 29th May 2012 at 12:00 noon Eastern time 5:00 = pm UK time, 6:00 pm Central Europe time for the interim meeting. Duration 2 hours. Further details in due course (along with the formal notification). Regards Keith -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Gonzalo Salgueiro Sent: 02 May 2012 00:08 To: insipid@ietf.org Subject: [Insipid] Fwd: INSIPID Virtual Interim Doodle Poll Folks: Friendly reminder to indicate availability dates for the INSIPID Vi= rtual Interim meeting. Cheers, Gonzalo Begin forwarded message: > From: Gonzalo Salgueiro > Subject: [Insipid] INSIPID Virtual Interim Doodle Poll > Date: April 27, 2012 12:52:01 AM EDT > To: insipid@ietf.org >=20 > Folks -=20 >=20 > As decided at IETF83 the INSIPID WG is planning a virtual interim meeting= to discuss and make progress on finalizing the list of requirements for th= e end-to-end session identifier. I was pleased to see James Polk started i= ndividual discussions on the alias for each requirement. My hope is that we= are able to make good progress on the list so we can be as efficient as po= ssible at the interim meeting. Please indicate your preferences by the end= of Thursday, May 3. I have added a diverse selection of days/times to acco= mmodate most. If you think other times should be added to the poll, let the= chairs knows. >=20 > This will be a 2 hour long webex meeting (I'll send out meeting details o= nce we converge on a date/time). >=20 > Please indicate your availability at: >=20 >=20 > http://www.doodle.com/sfdpmipnhtqtxn6e >=20 >=20 > The times specified on the poll are EDT but it should be intelligent enou= gh to translate to your local time. >=20 > Cheers, >=20 > Gonzalo > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Wed May 9 07:04:10 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5552921F8494 for ; Wed, 9 May 2012 07:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.933 X-Spam-Level: X-Spam-Status: No, score=-109.933 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 NcKTrsy2mVtE for ; Wed, 9 May 2012 07:04:09 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02D21F8493 for ; Wed, 9 May 2012 07:04:08 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q49E3hPT008214 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 9 May 2012 16:04:06 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 9 May 2012 16:03:56 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Wed, 9 May 2012 16:03:55 +0200 Thread-Topic: Agenda for virtual interim meeting Thread-Index: Ac0t7JJhyNP1vnf1RdSycp15t+Ux9w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [Insipid] Agenda for virtual interim meeting X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:04:10 -0000 (As WG cochair) My proposed agenda as follows. Note that I have not included any discussion of the solution document on th= is call because I believe we will not have time in the two hour slot. An objective will be to be able to do an adoption call of a requirements do= cument following this meeting - I believe this is dependent on fixing the s= cope. If authors are intending revising any of the documents listed below before = the interim, please send the chairs a mail. Please also feel free to agenda bash before the virtual interim call starts= . Regards Keith -------------------------------------------------------- The INSIPID WG will be holding a virtual interim meeting on 29th May 2012 a= t 12 noon Eastern time. Duration 2 hours. 1) Agenda bash, notetakers, etc 2) Scope of requirements / use cases document [Note identified presenters are those that were designated for Paris - plea= se let me know if this now changes, or you wish to revise your slides, othe= rwise I'll upload the existing slidepacks from IETF83] Session Initiation Protocol (SIP) Header Parameter for Debugging draft-dawe= s-dispatch-debug-00 Peter Dawes https://datatracker.ietf.org/doc/draft-dawe= s-dispatch-debug Session Initiation Protocol (SIP) Extension for logging and debugging draf= t-kaithal-dispatch-sip-log-information-00 Parthasarathi Ravindran (on behalf of Adarsh Kaithal / Sandeep K S) https:/= /datatracker.ietf.org/doc/draft-kaithal-dispatch-sip-log-information/ [Listed because it is identified by draft-dawes-dispatch-debug] A Session Identifier for the Session Initiation Protocol (SIP) (ANNEX A ONL= Y) draft-kaplan-dispatch-session-id-03 Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03 3) Discussion of individual requirements Requirements for an End-to-End Session Identification in IP-Based Multimedi= a Communication Networks draft-jones-ipmc-session-id-reqts-01 Paul Jones / James Polk / Parthasarathi Ravindran / Laura Liess / Roland Je= sske / Salvatore Loreto / Hadriel Kaplan https://datatracker.ietf.org/doc/d= raft-jones-ipmc-session-id-reqts/ Focus on specific issues from mailing list discussion 4) Next steps --------------------------------- From andrew.hutton@siemens-enterprise.com Wed May 9 10:30:43 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B615A11E80AB for ; Wed, 9 May 2012 10:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 jXhm3XP+EgMz for ; Wed, 9 May 2012 10:30:43 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CAD8311E80A3 for ; Wed, 9 May 2012 10:30:42 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A0B861EB8565; Wed, 9 May 2012 19:30:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 9 May 2012 19:30:41 +0200 From: "Hutton, Andrew" To: "James M. Polk" , "insipid@ietf.org" Date: Wed, 9 May 2012 19:30:40 +0200 Thread-Topic: [Insipid] INSIPID Req#9 - comments? Thread-Index: Ac0j6FO+y8ca8ixYStuKBjxMKDlXngJ5tUAAAA5/H7A= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312A742B683@MCHP058A.global-ad.net> References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@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: Re: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 17:30:43 -0000 Just like to add that the INSIPID charter indicates that the group will foc= us on a SIP Identifier and does not say anything about a media level identi= fier. I assume that specifying something for RTCP is therefore out of scope= . Regards Andy=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: 09 May 2012 11:43 > To: James M. Polk; insipid@ietf.org > Subject: Re: [Insipid] INSIPID Req#9 - comments? >=20 > Hi, >=20 > Regarding the requirement for making the identifier suitable for > transmission in RTCP and the associated use case of associating > signaling and media flows. >=20 > I doubt that it is a good idea to attempt to include the same > identifier in the media/RTCP as the signaling as even if this is > possible in some scenarios it is most likely not possible in many and > will break in others. >=20 > Is it really a requirement for the identifier to be used to associate > signaling with media personally I am thinking it is not. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of James M. Polk > > Sent: 26 April 2012 21:06 > > To: insipid@ietf.org > > Subject: [Insipid] INSIPID Req#9 - comments? > > > > Figure it is about time I sent these requirements out to the list. > > Comments, questions and wordsmithing are encouraged. Let's see if we > > can leave much of the wordsmithing till the end of the discussion, > > once we have agreed on the requirement's worthiness and contents. > > > > Let's also keep the discussion on *this* thread to just *this* > > requirement for tracking purposes. There are 9 current requirements. > > Therefore, there will be 9 different messages sent to this list. > > > > Here is REQ#9 as currently written in > > http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id- > > reqts-00.txt > > > > REQ9: The identifier should be constructed in such a way as > > to make it suitable for transmission in SIP, H.323, RSVP > > [3], and RTCP [4]. > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Wed May 9 11:35:13 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD1911E809C for ; Wed, 9 May 2012 11:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Poot-NQi9HxP for ; Wed, 9 May 2012 11:35:12 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 969A811E8081 for ; Wed, 9 May 2012 11:35:12 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CD0881EB84B9; Wed, 9 May 2012 20:35:11 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 9 May 2012 20:35:11 +0200 From: "Hutton, Andrew" To: "Paul E. Jones" Date: Wed, 9 May 2012 20:35:10 +0200 Thread-Topic: [Insipid] INSIPID Req#2 - comments? Thread-Index: Ac0t5v5/un6S1tLcTlewpkwHC/rf9AAIn3nA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312A742B688@MCHP058A.global-ad.net> References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> <4FA3D62D.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> <101C6067BEC68246B0C3F6843BCCC1E312A742B4A6@MCHP058A.global-ad.net> <4FAA6FE5.7000808@packetizer.com> In-Reply-To: <4FAA6FE5.7000808@packetizer.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: "insipid@ietf.org" , Brett Tate Subject: Re: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:35:13 -0000 Hi, The draft and even the working group charter are full of solution type stuf= f already so we are already going down that path. Is it just me or is there a problem with terminology in the draft it seems = to me after reading the terminology section that "session", "end-to-end ses= sion" and "communication session" all mean the same thing which makes some = of the requirements really hard to understand if you read them literally. I agree that specifying that the identifier can be changed within a dialog = is really solution but can I ask whether there is already some assumption a= bout whether this is a single identifier or whether it could be a more comp= lex structure which somehow links things together after a transfer for exam= ple? Some of the requirements seem to assume a single identifier, for example RE= Q3, and that was my assumption so far. If we have already decided that this= is a single identifier then of course it is going to have to change in cer= tain scenarios. Regards Andy > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: 09 May 2012 14:24 > To: Hutton, Andrew > Cc: Brett Tate; insipid@ietf.org > Subject: Re: [Insipid] INSIPID Req#2 - comments? >=20 > While I'm not stubbornly opposed to making such an explicit statement > in > the requirements document, having such a requirement seems to be a > solution, not a requirement. The requirement should not be to change > an > ID, but if the solution requires it to satisfy the requirement, then > that's the solution. >=20 > Perhaps someone can come up with some interesting idea not already > considered that would not require a change in the IDs used. I doubt > they can, but I'll never dismiss any possibility. >=20 > In any case, changing the ID isn't a requirement, but an answer to the > requirement. >=20 > Paul >=20 > On 5/9/2012 6:50 AM, Hutton, Andrew wrote: > > Hi, > > > > I agree with Brett we need to get it out in the open in the > requirements drafts that the identifier can change during a dialog and > use transfer use case to bring this requirement out. > > > > A 3PCC use case or two would also I think be appropriate. > > > > Regards > > Andy > > > > > > > >> -----Original Message----- > >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >> Behalf Of Brett Tate > >> Sent: 04 May 2012 16:47 > >> To: Paul E. Jones; insipid@ietf.org > >> Subject: Re: [Insipid] INSIPID Req#2 - comments? > >> > >> Thanks for the response. > >> > >>> While I'm not opposed to making an explicit statement > >>> that the ID must change, that's not the requirement. > >>> I believe it must change, but others may feel differently. > >> As far as I know, "the ID must change" is currently an implied > >> requirement since nobody has communicated how REQ2 could be met (for > >> the example) without the session identity changing within an > existing > >> dialog. > >> > >> > >> > >>> I don't think we should make it a requirement to change > >>> the ID. Changing the ID might be a part of the solution, > >>> but I don't see why the solution should dictate the > >>> requirements. > >> I'm concerned that as the working group reviews the requirements > draft, > >> the reviewers may not realize that an implied > requirement/consequence > >> of REQ2 is that a B2BUA connecting/joining two existing dialogs > would > >> potentially result in the session identifier changing within the > >> dialog. > >> > >> I prefer that the topic be debated as part of the requirements > process > >> instead of after the requirements draft becomes an RFC. This is > mostly > >> because I prefer a non explicit "approved requirement" not > subsequently > >> be used as justification to change session identifiers within a > dialog > >> (or justification for a more severe remedy to meet REQ2). > >> > >> > >>>> REQ2: It must be possible to identify the end-to-end session > >>>> when a session is transferred or if two different sessions > >>>> are joined together via an intermediary (e.g., a PBX). > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed May 9 15:10:10 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8314E11E80C5 for ; Wed, 9 May 2012 15:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 nNiaezmMWtiY for ; Wed, 9 May 2012 15:10:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C866D11E80BB for ; Wed, 9 May 2012 15:10:09 -0700 (PDT) Received: from [10.200.69.168] (167.3.143.94.ch.dsl.dfinet.net [94.143.3.167] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q49MA4Cx002886 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 May 2012 18:10:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336601406; bh=dMqmO9YKHYbz6qgEyNbspCNT1udRdYNbl9aFg1/SvqE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Xbznu3XmFbNOAv/Ym5/7Spczk8/RbTiamC2Y915Snsuwwh5zJ9QFKNTdHpqcrWxgv pYM6WcfvcB4GXNNS68qNMXOXDfbT3OYMRRac8sAAFWPcm5OSx6g0fUVAy4A8Pw3I4p rAmI3gCNWETio5WPBsX9+qJlZThKswf1wUmZ8cao= Message-ID: <4FAAEB3D.3020605@packetizer.com> Date: Wed, 09 May 2012 18:10:05 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Hutton, Andrew" References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> <4FA3D62D.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> <101C6067BEC68246B0C3F6843BCCC1E312A742B4A6@MCHP058A.global-ad.net> <4FAA6FE5.7000808@packetizer.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B688@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A742B688@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" , Brett Tate Subject: Re: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 22:10:10 -0000 On 5/9/2012 2:35 PM, Hutton, Andrew wrote: > Hi, > > The draft and even the working group charter are full of solution type stuff already so we are already going down that path. If that's the case, we might want to change the wording a bit. Feel free to propose suggested changes. > Is it just me or is there a problem with terminology in the draft it seems to me after reading the terminology section that "session", "end-to-end session" and "communication session" all mean the same thing which makes some of the requirements really hard to understand if you read them literally. Without looking at the document, I'd assume these are all the same. We're talking about a "session" and I think that it's not well-defined (nor is it defined elsewhere), but I believe we have the same notion of what we mean. We had proposed defining that, but that was stricken from the charter. > I agree that specifying that the identifier can be changed within a dialog is really solution but can I ask whether there is already some assumption about whether this is a single identifier or whether it could be a more complex structure which somehow links things together after a transfer for example? Our solution document defines a "session-ID" that is comprised of components. However, the proposed solution should not dictate the requirements. I would like to have "a thing" we can point a finger at and call it a session ID. I do not care how it's constructed, though I would like it to be usable across a plurality of protocols, including SIP, H.323, whatever RTCWeb goes with, and XMPP. > Some of the requirements seem to assume a single identifier, for example REQ3, and that was my assumption so far. If we have already decided that this is a single identifier then of course it is going to have to change in certain scenarios. I believe it should be possible to view it as a single ID, though it might be comprised of components. I've been down this path more than once already and each time I pick a single ID at one end, I encounter problems. Once a call is in a steady state, though, there should be something we call the Session-ID (versus the session ID parts). That said, at least one person did suggest that it might be better to view the session ID as a collection of parts. I think we should only make that decision once we get the requirements solidified and start to work on a solution. Paul From paulej@packetizer.com Wed May 9 15:14:55 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B2321F843C for ; Wed, 9 May 2012 15:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 LmR4KHwZJfXd for ; Wed, 9 May 2012 15:14:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9D35B21F843A for ; Wed, 9 May 2012 15:14:54 -0700 (PDT) Received: from [10.200.69.168] (167.3.143.94.ch.dsl.dfinet.net [94.143.3.167] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q49MElb7002980 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 May 2012 18:14:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336601693; bh=eLo+UY93ye8m/EvCTuMZVTgowtMq6z5XeFyFrRJEPlk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=lnQqPB6Uw346NfFQVssklAt58JVvZ3DdMdp3Xtwabt63GF3drSAp6yw3yoUockWgq Vm8WLz3chQOl/vjhMn8PoaeNPAcwnsenQyvsEWcrm+8Rc4unVe8C1UtBBMSAYWHQG9 +6Po0XYcjSmwrS7If3pnaR4Y5Luhus1E5/TA+oog= Message-ID: <4FAAEC58.8050503@packetizer.com> Date: Wed, 09 May 2012 18:14:48 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Hutton, Andrew" References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E312A742B683@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A742B683@MCHP058A.global-ad.net> Content-Type: multipart/alternative; boundary="------------050407060905020707070602" Cc: "James M. Polk" , "insipid@ietf.org" Subject: Re: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 22:14:55 -0000 This is a multi-part message in MIME format. --------------050407060905020707070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Specifying it is out of scope, but the objective to have an ID that /could be /used in RTCP is nonetheless desirable. I'd like to be able to use this as a means of correlating media flows. I'd like to be able to identify which set of flows have a direct relationship or indirect relationship. There are things we can do with that information in the network. Paul On 5/9/2012 1:30 PM, Hutton, Andrew wrote: > Just like to add that the INSIPID charter indicates that the group will focus on a SIP Identifier and does not say anything about a media level identifier. I assume that specifying something for RTCP is therefore out of scope. > > Regards > Andy > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: 09 May 2012 11:43 >> To: James M. Polk; insipid@ietf.org >> Subject: Re: [Insipid] INSIPID Req#9 - comments? >> >> Hi, >> >> Regarding the requirement for making the identifier suitable for >> transmission in RTCP and the associated use case of associating >> signaling and media flows. >> >> I doubt that it is a good idea to attempt to include the same >> identifier in the media/RTCP as the signaling as even if this is >> possible in some scenarios it is most likely not possible in many and >> will break in others. >> >> Is it really a requirement for the identifier to be used to associate >> signaling with media personally I am thinking it is not. >> >> Regards >> Andy >> >> >> >> >>> -----Original Message----- >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>> Behalf Of James M. Polk >>> Sent: 26 April 2012 21:06 >>> To: insipid@ietf.org >>> Subject: [Insipid] INSIPID Req#9 - comments? >>> >>> Figure it is about time I sent these requirements out to the list. >>> Comments, questions and wordsmithing are encouraged. Let's see if we >>> can leave much of the wordsmithing till the end of the discussion, >>> once we have agreed on the requirement's worthiness and contents. >>> >>> Let's also keep the discussion on *this* thread to just *this* >>> requirement for tracking purposes. There are 9 current requirements. >>> Therefore, there will be 9 different messages sent to this list. >>> >>> Here is REQ#9 as currently written in >>> http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id- >>> reqts-00.txt >>> >>> REQ9: The identifier should be constructed in such a way as >>> to make it suitable for transmission in SIP, H.323, RSVP >>> [3], and RTCP [4]. >>> >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid --------------050407060905020707070602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Specifying it is out of scope, but the objective to have an ID that could be used in RTCP is nonetheless desirable.

I'd like to be able to use this as a means of correlating media flows.  I'd like to be able to identify which set of flows have a direct relationship or indirect relationship.  There are things we can do with that information in the network.

Paul

On 5/9/2012 1:30 PM, Hutton, Andrew wrote: 
Just like to add that the INSIPID charter indicates that the group will focus on a SIP Identifier and does not say anything about a media level identifier. I assume that specifying something for RTCP is therefore out of scope.

Regards
Andy 


-----Original Message-----
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On
Behalf Of Hutton, Andrew
Sent: 09 May 2012 11:43
To: James M. Polk; insipid@ietf.org
Subject: Re: [Insipid] INSIPID Req#9 - comments?

Hi,

Regarding the requirement for making the identifier suitable for
transmission in RTCP and the associated use case of associating
signaling and media flows.

I doubt that it is a good idea to attempt to include the same
identifier in the media/RTCP as the signaling as even if this is
possible in some scenarios it is most likely not possible in many and
will break in others.

Is it really a requirement for the identifier to be used to associate
signaling with media personally I am thinking it is not.

Regards
Andy





-----Original Message-----
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On
Behalf Of James M. Polk
Sent: 26 April 2012 21:06
To: insipid@ietf.org
Subject: [Insipid] INSIPID Req#9 - comments?

Figure it is about time I sent these requirements out to the list.
Comments, questions and wordsmithing are encouraged. Let's see if we
can leave much of the wordsmithing till the end of the discussion,
once we have agreed on the requirement's worthiness and contents.

Let's also keep the discussion on *this* thread to just *this*
requirement for tracking purposes. There are 9 current requirements.
Therefore, there will be 9 different messages sent to this list.

Here is REQ#9 as currently written in
http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-
reqts-00.txt

    REQ9: The identifier should be constructed in such a way as
    to make it suitable for transmission in SIP, H.323, RSVP
    [3], and RTCP [4].

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

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

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

--------------050407060905020707070602-- From jmpolk@cisco.com Fri May 11 15:55:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1265711E8076 for ; Fri, 11 May 2012 15:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.882 X-Spam-Level: X-Spam-Status: No, score=-109.882 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_HI=-8, 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 nhq5uXbMIxBu for ; Fri, 11 May 2012 15:55:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 58A379E800A for ; Fri, 11 May 2012 15:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2585; q=dns/txt; s=iport; t=1336776900; x=1337986500; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=qk2K7MiwJcNFUEV59MT2Oe53FB7cypoqR1ptWOJuALU=; b=FCteFtiMX6exm+TP5MTB0qcaGz/FVXUjvaGXmJ8jfk16NZ7WfVF2hpm3 IDzvdFSLz3RWG/W53jJJ/KmULrnfQgSBfsy6aKROITJDF8yCQjc6d1sRO kIBcM1PMKELSS9b/gWshP8YRnr+C8bnPdRjEVU7aJJazpl051DvdnMI0h I=; X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="41908002" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 May 2012 22:55:00 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4BMsvqu021540; Fri, 11 May 2012 22:54:59 GMT Message-Id: <201205112254.q4BMsvqu021540@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 May 2012 15:54:11 -0500 To: "Hutton, Andrew" , "insipid@ietf.org" From: "James M. Polk" In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global -ad.net> References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "James M. Polk" Subject: Re: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:55:01 -0000 Andy I don't want this to come off as too confrontational, but saying "I doubt it is a good idea" isn't technical enough for many to agree with you. Picking only on RTCP, can you specifically list a few scenarios in which it will break RTCP? As to "Is it really a requirement for the identifier to be used to associate signaling with media", right now that's req#9 because the requirements document lists it as a requirement. Saying only that you don't like something doesn't make it go away. We need more technical details as to why it doesn't make sense or why it breaks X and Y, and you need to be more open to others wanting to counter what you say for cases in which it does make sense. Is this agreeable? James At 05:43 AM 5/9/2012, Hutton, Andrew wrote: >Hi, > >Regarding the requirement for making the identifier suitable for >transmission in RTCP and the associated use case of associating >signaling and media flows. > >I doubt that it is a good idea to attempt to include the same >identifier in the media/RTCP as the signaling as even if this is >possible in some scenarios it is most likely not possible in many >and will break in others. > >Is it really a requirement for the identifier to be used to >associate signaling with media personally I am thinking it is not. > >Regards >Andy > > > > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of James M. Polk > > Sent: 26 April 2012 21:06 > > To: insipid@ietf.org > > Subject: [Insipid] INSIPID Req#9 - comments? > > > > Figure it is about time I sent these requirements out to the list. > > Comments, questions and wordsmithing are encouraged. Let's see if we > > can leave much of the wordsmithing till the end of the discussion, > > once we have agreed on the requirement's worthiness and contents. > > > > Let's also keep the discussion on *this* thread to just *this* > > requirement for tracking purposes. There are 9 current requirements. > > Therefore, there will be 9 different messages sent to this list. > > > > Here is REQ#9 as currently written in > > http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id- > > reqts-00.txt > > > > REQ9: The identifier should be constructed in such a way as > > to make it suitable for transmission in SIP, H.323, RSVP > > [3], and RTCP [4]. > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Fri May 11 15:55:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB4D9E800A for ; Fri, 11 May 2012 15:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.864 X-Spam-Level: X-Spam-Status: No, score=-109.864 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_HI=-8, 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 7PAdE2brD6KD for ; Fri, 11 May 2012 15:55:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BFF7A11E8074 for ; Fri, 11 May 2012 15:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3472; q=dns/txt; s=iport; t=1336776900; x=1337986500; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=Lq8u2pct1oYHkPEc0HlsOvYQ27uuLZNNhgaLP8bYqWw=; b=U4Aec+g1XDhyQpyZyw42QqIGxHaQ1uOzXE7NJcm42U6NOvjDJfuwtJJA +03hJaAtgHVYUxqL0i6tUuOUsd8fmDU/5IYM6d2swUuZ6N2JoU7vA04rA MSfuRtHUMee5t6x6s6ggz0muKpDhR9jfDOfHsMoBUhFM1PLLdrw/HSb7G I=; X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="41369151" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 11 May 2012 22:55:00 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4BMsvqw021540; Fri, 11 May 2012 22:55:00 GMT Message-Id: <201205112255.q4BMsvqw021540@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 May 2012 16:00:52 -0500 To: "Hutton, Andrew" , "insipid@ietf.org" From: "James M. Polk" In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A742B683@MCHP058A.global -ad.net> References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E312A742B683@MCHP058A.global-ad.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "James M. Polk" Subject: Re: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:55:01 -0000 Andy SIP is text based, and H.323 is binary based. One stated goal is to have this same (i.e., identical) identifier used in H.323. What that said, anything that is binary and extensible, and not fixed length, can conceivably carry this same identifier. That includes many protocols, RTCP, RSVP, H.323, H.248, etc. As long as this session-ID is compatible with H.323, it can be placed in several more protocols that can use it viably, as long as it doesn't break them. Further, IMO, as long as we know specific scenarios in which this ID will or will not break another protocol - I see no reason not to list those protocols and/or use-cases, if only in an appendix of solution doc. James At 12:30 PM 5/9/2012, Hutton, Andrew wrote: >Just like to add that the INSIPID charter indicates that the group >will focus on a SIP Identifier and does not say anything about a >media level identifier. I assume that specifying something for RTCP >is therefore out of scope. > >Regards >Andy > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: 09 May 2012 11:43 > > To: James M. Polk; insipid@ietf.org > > Subject: Re: [Insipid] INSIPID Req#9 - comments? > > > > Hi, > > > > Regarding the requirement for making the identifier suitable for > > transmission in RTCP and the associated use case of associating > > signaling and media flows. > > > > I doubt that it is a good idea to attempt to include the same > > identifier in the media/RTCP as the signaling as even if this is > > possible in some scenarios it is most likely not possible in many and > > will break in others. > > > > Is it really a requirement for the identifier to be used to associate > > signaling with media personally I am thinking it is not. > > > > Regards > > Andy > > > > > > > > > > > -----Original Message----- > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > > Behalf Of James M. Polk > > > Sent: 26 April 2012 21:06 > > > To: insipid@ietf.org > > > Subject: [Insipid] INSIPID Req#9 - comments? > > > > > > Figure it is about time I sent these requirements out to the list. > > > Comments, questions and wordsmithing are encouraged. Let's see if we > > > can leave much of the wordsmithing till the end of the discussion, > > > once we have agreed on the requirement's worthiness and contents. > > > > > > Let's also keep the discussion on *this* thread to just *this* > > > requirement for tracking purposes. There are 9 current requirements. > > > Therefore, there will be 9 different messages sent to this list. > > > > > > Here is REQ#9 as currently written in > > > http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id- > > > reqts-00.txt > > > > > > REQ9: The identifier should be constructed in such a way as > > > to make it suitable for transmission in SIP, H.323, RSVP > > > [3], and RTCP [4]. > > > > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Fri May 11 15:55:02 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961AB11E8083 for ; Fri, 11 May 2012 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.848 X-Spam-Level: X-Spam-Status: No, score=-109.848 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_HI=-8, 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 xXcwdth9adxp for ; Fri, 11 May 2012 15:55:01 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DCC689E800A for ; Fri, 11 May 2012 15:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3603; q=dns/txt; s=iport; t=1336776901; x=1337986501; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=2RIKIwT+p15GpJmUa4+hShkYiBEO57y+UXvwO7X6If8=; b=kgzKuUGi0Aa6muiKkLyKaT+eaPb6GJGkyIIIQTq45/75k8SdCrGGAm5B n/KD6o1K/OQo7sMOpQFiL6vu3XH2MI0HKa/S8UPk+GDtXsu3rA/ypTwnA R0VMYgHoOK5TVmjE1rzLrX0gCgdMLTMnfta//EosEASpW1+7A83mAmV9J 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFACiYrU+rRDoG/2dsb2JhbAA6AQkos0WBB4IVAQEBBAEBAQ8BJQI0CwwEBwQRBAEBAR4JBxkOHwkIBgoHAhsHh2sMmymfZgSLFw8Bhg0EiGSbcIFpgwcg X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="41369153" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 11 May 2012 22:55:01 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4BMsvr2021540; Fri, 11 May 2012 22:55:01 GMT Message-Id: <201205112255.q4BMsvr2021540@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 May 2012 16:19:01 -0500 To: "Paul E. Jones" , "Hutton, Andrew" From: "James M. Polk" In-Reply-To: <4FAA6FE5.7000808@packetizer.com> References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> <4FA3D62D.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> <101C6067BEC68246B0C3F6843BCCC1E312A742B4A6@MCHP058A.global-ad.net> <4FAA6FE5.7000808@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "insipid@ietf.org" , Brett Tate Subject: Re: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:55:02 -0000 I'm with Paul J. here, let's not make it a requirement to have to change the session-ID, though we can add some text to a motivation part around this REQ by saying it will likely change the ID. We shouldn't mandate the change, else we'll end up in a dog fight as to exactly what the scope of the change is. For example, is changing 1 bit value in a Session-ID enough, or does at least or more than half of the ID need to change to satisfy this new mandatory aspect of this REQ? James At 08:23 AM 5/9/2012, Paul E. Jones wrote: >While I'm not stubbornly opposed to making such an explicit >statement in the requirements document, having such a requirement >seems to be a solution, not a requirement. The requirement should >not be to change an ID, but if the solution requires it to satisfy >the requirement, then that's the solution. > >Perhaps someone can come up with some interesting idea not already >considered that would not require a change in the IDs used. I doubt >they can, but I'll never dismiss any possibility. > >In any case, changing the ID isn't a requirement, but an answer to >the requirement. > >Paul > >On 5/9/2012 6:50 AM, Hutton, Andrew wrote: >>Hi, >> >>I agree with Brett we need to get it out in the open in the >>requirements drafts that the identifier can change during a dialog >>and use transfer use case to bring this requirement out. >> >>A 3PCC use case or two would also I think be appropriate. >> >>Regards >>Andy >> >> >> >>>-----Original Message----- >>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>Behalf Of Brett Tate >>>Sent: 04 May 2012 16:47 >>>To: Paul E. Jones; insipid@ietf.org >>>Subject: Re: [Insipid] INSIPID Req#2 - comments? >>> >>>Thanks for the response. >>> >>>>While I'm not opposed to making an explicit statement >>>>that the ID must change, that's not the requirement. >>>>I believe it must change, but others may feel differently. >>>As far as I know, "the ID must change" is currently an implied >>>requirement since nobody has communicated how REQ2 could be met (for >>>the example) without the session identity changing within an existing >>>dialog. >>> >>> >>> >>>>I don't think we should make it a requirement to change >>>>the ID. Changing the ID might be a part of the solution, >>>>but I don't see why the solution should dictate the >>>>requirements. >>>I'm concerned that as the working group reviews the requirements draft, >>>the reviewers may not realize that an implied requirement/consequence >>>of REQ2 is that a B2BUA connecting/joining two existing dialogs would >>>potentially result in the session identifier changing within the >>>dialog. >>> >>>I prefer that the topic be debated as part of the requirements process >>>instead of after the requirements draft becomes an RFC. This is mostly >>>because I prefer a non explicit "approved requirement" not subsequently >>>be used as justification to change session identifiers within a dialog >>>(or justification for a more severe remedy to meet REQ2). >>> >>> >>>>>REQ2: It must be possible to identify the end-to-end session >>>>>when a session is transferred or if two different sessions >>>>>are joined together via an intermediary (e.g., a PBX). >>>_______________________________________________ >>>insipid mailing list >>>insipid@ietf.org >>>https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Sat May 12 04:54:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EF921F85EF for ; Sat, 12 May 2012 04:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 lweJGJ9Y10A6 for ; Sat, 12 May 2012 04:54:00 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id CB89221F85E1 for ; Sat, 12 May 2012 04:53:59 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 60B4A23F05C5; Sat, 12 May 2012 13:53:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Sat, 12 May 2012 13:53:58 +0200 From: "Hutton, Andrew" To: "James M. Polk" , "insipid@ietf.org" Date: Sat, 12 May 2012 13:53:55 +0200 Thread-Topic: [Insipid] INSIPID Req#9 - comments? Thread-Index: Ac0vyRuFe6ntmnW2Ruq+R1lHKvDF4QAaVvdg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312A7633C4E@MCHP058A.global-ad.net> References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> <201205112254.q4BMsvqu021540@mtv-core-1.cisco.com> In-Reply-To: <201205112254.q4BMsvqu021540@mtv-core-1.cisco.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: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 11:54:01 -0000 Hi James, Don't worry about being confrontational that's part of the fun. The main issue from my point of view is to determine whether correlating th= e media streams with signaling is a problem that the INSIPID WG is going to= tackle. My understanding was that the WG was tasked with standardizing an = identifier which could be passed end to end over the signaling path without= being mangled by intermediaries. If the same identifier could be used over= other session establishment protocols like H.323 then that would be also b= e nice. However I did not envisage that the same identifier was going to be= used on the media plane. The issue of correlating the media and signaling streams is a different pro= blem space that I for one had not envisaged was within scope of INSIPID and= one for which I have not seen the same need. I did not say that including such an identifier in RTCP would break RTCP an= d I don't think it would. However any mechanism for correlating media strea= ms with signaling will break in some scenarios. It has to be assumed that = the signaling and media will not flow through the same set of intermediarie= s and therefore there is always scope for things to go wrong if you are att= empting to use the same identifier in both signaling and media. I would argue that the use case below is not a valid use case within the sc= ope of INSIPID and there should be no requirement to be able to include the= identifier in RTCP and probably not RSVP either. "Association of session signaling and media flows, made possible by includi= ng the session identifier in media-related messages (e.g., RSVP or RTCP). Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of James M. Polk > Sent: 10 May 2012 21:54 > To: Hutton, Andrew; insipid@ietf.org > Cc: James M. Polk > Subject: Re: [Insipid] INSIPID Req#9 - comments? >=20 > Andy >=20 > I don't want this to come off as too confrontational, but saying "I > doubt it is a good idea" isn't technical enough for many to agree with > you. >=20 > Picking only on RTCP, can you specifically list a few scenarios in > which it will break RTCP? >=20 > As to "Is it really a requirement for the identifier to be used to > associate signaling with media", right now that's req#9 because the > requirements document lists it as a requirement. Saying only that you > don't like something doesn't make it go away. We need more technical > details as to why it doesn't make sense or why it breaks X and Y, and > you need to be more open to others wanting to counter what you say > for cases in which it does make sense. >=20 > Is this agreeable? >=20 > James >=20 > At 05:43 AM 5/9/2012, Hutton, Andrew wrote: > >Hi, > > > >Regarding the requirement for making the identifier suitable for > >transmission in RTCP and the associated use case of associating > >signaling and media flows. > > > >I doubt that it is a good idea to attempt to include the same > >identifier in the media/RTCP as the signaling as even if this is > >possible in some scenarios it is most likely not possible in many > >and will break in others. > > > >Is it really a requirement for the identifier to be used to > >associate signaling with media personally I am thinking it is not. > > > >Regards > >Andy > > > > > > > > > > > -----Original Message----- > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > > Behalf Of James M. Polk > > > Sent: 26 April 2012 21:06 > > > To: insipid@ietf.org > > > Subject: [Insipid] INSIPID Req#9 - comments? > > > > > > Figure it is about time I sent these requirements out to the list. > > > Comments, questions and wordsmithing are encouraged. Let's see if > we > > > can leave much of the wordsmithing till the end of the discussion, > > > once we have agreed on the requirement's worthiness and contents. > > > > > > Let's also keep the discussion on *this* thread to just *this* > > > requirement for tracking purposes. There are 9 current > requirements. > > > Therefore, there will be 9 different messages sent to this list. > > > > > > Here is REQ#9 as currently written in > > > http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id- > > > reqts-00.txt > > > > > > REQ9: The identifier should be constructed in such a way as > > > to make it suitable for transmission in SIP, H.323, RSVP > > > [3], and RTCP [4]. > > > > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From brett@broadsoft.com Mon May 14 04:34:45 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3720721F86D5 for ; Mon, 14 May 2012 04:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 bfCIw9wUJeoy for ; Mon, 14 May 2012 04:34:44 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id BBB0D21F86D3 for ; Mon, 14 May 2012 04:34:44 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 May 2012 04:37:01 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 14 May 2012 04:36:59 -0700 From: Brett Tate To: "James M. Polk" , "insipid@ietf.org" Date: Mon, 14 May 2012 04:34:41 -0700 Thread-Topic: [Insipid] INSIPID Req#2 - comments? Thread-Index: Ac0vyWsK4jd26vuxTjWcUIlOyqsfGwB+ZUXw Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2CA41FF3@EXMBXCLUS01.citservers.local> References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> <4FA3D62D.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> <101C6067BEC68246B0C3F6843BCCC1E312A742B4A6@MCHP058A.global-ad.net> <4FAA6FE5.7000808@packetizer.com> <201205112255.q4BMsvr2021540@mtv-core-1.cisco.com> In-Reply-To: <201205112255.q4BMsvr2021540@mtv-core-1.cisco.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: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:34:45 -0000 > I'm with Paul J. here, let's not make it a requirement=20 > to have to change the session-ID, though we can add=20 > some text to a motivation part around this REQ by=20 > saying it will likely change the ID.=20 I agree; that was basically my suggested change. "I recommend REQ2 (or whichever requirement implies such a thing) be modifi= ed to explicitly indicate that meeting the requirement may cause the sessio= n identifier to change within an existing dialog. I recommend being explic= it because it appears to go beyond the current charter. And if I recall co= rrectly, it was one of the controversial topics during the chartering proce= ss." From iesg-secretary@ietf.org Mon May 14 10:01:09 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1751921F88A1; Mon, 14 May 2012 10:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 v0bDfJo-THJY; Mon, 14 May 2012 10:01:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7554A21F8893; Mon, 14 May 2012 10:01:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120514170108.12442.11490.idtracker@ietfa.amsl.com> Date: Mon, 14 May 2012 10:01:08 -0700 Cc: insipid@ietf.org Subject: [Insipid] INSIPID WG Virtual Interim Meeting, May 29, 2012 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:01:09 -0000 The INSIPID WG will be holding a virtual interim meeting on 29th May 2012 a= t 12 noon Eastern time. Duration 2 hours. The proposed agenda will be: -------------------------------------------------------- 1) Agenda bash, notetakers, etc 2) Scope of requirements / use cases document [Note identified presenters are those that were designated for Paris - plea= se let me know if this now changes, or you wish to revise your slides, othe= rwise I'll upload the existing slidepacks from IETF83] Session Initiation Protocol (SIP) Header Parameter for Debugging draft-dawes-dispatch-debug-00 Peter Dawes https://datatracker.ietf.org/doc/draft-dawes-dispatch-debug Session Initiation Protocol (SIP) Extension for logging and debugging draft-kaithal-dispatch-sip-log-information-00 Parthasarathi Ravindran (on behalf of Adarsh Kaithal / Sandeep K S) https://datatracker.ietf.org/doc/draft-kaithal-dispatch-sip-log-information/ [Listed because it is identified by draft-dawes-dispatch-debug] A Session Identifier for the Session Initiation Protocol (SIP) (ANNEX A ONL= Y) draft-kaplan-dispatch-session-id-03 Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03 3) Discussion of individual requirements Requirements for an End-to-End Session Identification in IP-Based Multimedi= a Communication Networks draft-jones-ipmc-session-id-reqts-01 Paul Jones / James Polk / Parthasarathi Ravindran / Laura Liess / Roland Je= sske / Salvatore Loreto / Hadriel Kaplan https://datatracker.ietf.org/doc/draft-jones-ipmc-session-id-reqts/ Focus on specific issues from mailing list discussion 4) Next steps --------------------------------- From gsalguei@cisco.com Tue May 15 13:54:08 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2311E80BC for ; Tue, 15 May 2012 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=-3.609, 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 73B95orjUCBQ for ; Tue, 15 May 2012 13:54:07 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4604311E808C for ; Tue, 15 May 2012 13:54:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4FKs4a1024021 for ; Tue, 15 May 2012 13:54:05 -0700 (PDT) Received: from dhcp-64-102-210-169.cisco.com (dhcp-64-102-210-169.cisco.com [64.102.210.169]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4FKrvOc005157 for ; Tue, 15 May 2012 16:53:59 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 15 May 2012 16:53:57 -0400 Message-Id: <0E05A9D5-9337-4DAE-8FC6-BC04C3BFC120@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [Insipid] INSIPID Virtual Interim Meeting: Dial-in details via Webex X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:54:08 -0000 Hello Folks -=20 We will use Webex to host the INSIPID virtual interim meeting. See below = for the "dial-in" details. For completeness the previously published = agenda is included at the bottom of this message. INtermediary-safe SIP session ID (INSIPID) Group invites you to attend = this online meeting.=20 Topic: INSIPID WG Interim=20 Date: Tuesday, May 29, 2012=20 Time: 8:45 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 961 449 580=20 Meeting Password: 1234=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D193859087&UID=3D128555520= 7&PW=3DNZGJjMGI0Mzgz&RT=3DMiM0=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: 1234=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 = https://workgreen.webex.com/workgreen/j.php?ED=3D193859087&UID=3D128555520= 7&PW=3DNZGJjMGI0Mzgz&ORT=3DMiM0=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED= =3D193859087&tollFree=3D0=20 Access code:961 449 580=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 cmorgan@amsl.com=20 1-510-492-4085=20 To update this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 = https://workgreen.webex.com/workgreen/j.php?ED=3D193859087&UID=3D128555520= 7&ICS=3DMRS1&LD=3D1&RD=3D2&ST=3D1&SHA2=3D07eDCG0TzTGC2TAQfqHhZ7Xz22qylDWvz= PyQidKMKD8=3D&RT=3DMiM0=20 WebEx will automatically setup Meeting Manager for Windows the first = time you join a meeting. To save time, you can setup prior to the = meeting by clicking this link:=20 https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php=20 The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://workgreen.webex.com/workgreen/systemdiagnosis.php.=20 Sign up for a free trial of WebEx=20 http://www.webex.com/go/mcemfreetrial=20 http://www.webex.com=20 CCP:+14087926300x961449580#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 -------------------------------------------------------- 1) Agenda bash, notetakers, etc 2) Scope of requirements / use cases document [Note identified presenters are those that were designated for Paris - = please let me know if this now changes, or you wish to revise your = slides, otherwise I'll upload the existing slidepacks from IETF83] Session Initiation Protocol (SIP) Header Parameter for Debugging draft-dawes-dispatch-debug-00 Peter Dawes https://datatracker.ietf.org/doc/draft-dawes-dispatch-debug Session Initiation Protocol (SIP) Extension for logging and debugging draft-kaithal-dispatch-sip-log-information-00 Parthasarathi Ravindran (on behalf of Adarsh Kaithal / Sandeep K S) = https://datatracker.ietf.org/doc/draft-kaithal-dispatch-sip-log-informatio= n/ [Listed because it is identified by draft-dawes-dispatch-debug] A Session Identifier for the Session Initiation Protocol (SIP) (ANNEX A = ONLY) draft-kaplan-dispatch-session-id-03 Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03 3) Discussion of individual requirements Requirements for an End-to-End Session Identification in IP-Based = Multimedia Communication Networks draft-jones-ipmc-session-id-reqts-01 Paul Jones / James Polk / Parthasarathi Ravindran / Laura Liess / Roland = Jesske / Salvatore Loreto / Hadriel Kaplan https://datatracker.ietf.org/doc/draft-jones-ipmc-session-id-reqts/ Focus on specific issues from mailing list discussion 4) Next steps --------------------------------- Cheers, Gonzalo From paulej@packetizer.com Wed May 16 07:49:56 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190AE21F85EF for ; Wed, 16 May 2012 07:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 CMtv4ChDZUbX for ; Wed, 16 May 2012 07:49:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0737F21F8603 for ; Wed, 16 May 2012 07:49:54 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q4GEnrcu016453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 May 2012 10:49:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1337179793; bh=AcgVn+I2keIn24q0XcBcjrw4mruQnsNLZSNurvgiyTo=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Rm83jhgIURfNssqNxbDo3kRHPY1vuMpBhtFPsu7i8eRLfHnILFTUTxavodX87F9vB 2xfe9naoQXnvDAHQHZolM+NvtkE8z0x9XNlrFHOqtnBAfk8Yu3Ca0fFryYqb+JbpBk FXirQ6j3YoLcGZCTgM3bQokFLC5/LRIjDHQxprk4= From: "Paul E. Jones" To: "'Hutton, Andrew'" , "'James M. Polk'" , References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> <201205112254.q4BMsvqu021540@mtv-core-1.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A7633C4E@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A7633C4E@MCHP058A.global-ad.net> Date: Wed, 16 May 2012 10:49:55 -0400 Message-ID: <022b01cd3373$28fc4750$7af4d5f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKUymPVogtMP86s0HvhOJDlCRCzPAKL57OtAnvmjOgAj+WjcZUQkVzQ Content-Language: en-us Subject: Re: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 14:49:56 -0000 Andy, I do have a desire to associate signaling with media flows, and to associate one flow with another flow. The Session-ID could be used for that for me. Perhaps I would not use the Session-ID directly, but perhaps I might. If the Session-ID was defined as two GUIDs (Alice || Bob), perhaps sha(Alice||Bob) might serve my purposes. A SIP session is not only the call signaling, but the associated media flows, too. I would not necessary expect some value inserted into every RTP packet or RTCP packet, etc., but we should strive for a construction that would potentially allow for its inclusion. What I would like to avoid is some long, variable-length ASCII string that makes it a challenge to use anywhere outside of an INVITE or 200. I'd like a reasonably compact binary encoding (that can also be expressed in ASCII). Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Hutton, Andrew > Sent: Saturday, May 12, 2012 7:54 AM > To: James M. Polk; insipid@ietf.org > Subject: Re: [Insipid] INSIPID Req#9 - comments? > > Hi James, > > Don't worry about being confrontational that's part of the fun. > > The main issue from my point of view is to determine whether correlating > the media streams with signaling is a problem that the INSIPID WG is going > to tackle. My understanding was that the WG was tasked with standardizing > an identifier which could be passed end to end over the signaling path > without being mangled by intermediaries. If the same identifier could be > used over other session establishment protocols like H.323 then that would > be also be nice. However I did not envisage that the same identifier was > going to be used on the media plane. > > The issue of correlating the media and signaling streams is a different > problem space that I for one had not envisaged was within scope of INSIPID > and one for which I have not seen the same need. > > I did not say that including such an identifier in RTCP would break RTCP > and I don't think it would. However any mechanism for correlating media > streams with signaling will break in some scenarios. It has to be assumed > that the signaling and media will not flow through the same set of > intermediaries and therefore there is always scope for things to go wrong > if you are attempting to use the same identifier in both signaling and > media. > > I would argue that the use case below is not a valid use case within the > scope of INSIPID and there should be no requirement to be able to include > the identifier in RTCP and probably not RSVP either. > > "Association of session signaling and media flows, made possible by > including the session identifier in media-related messages (e.g., RSVP or > RTCP). > > Regards > Andy > > > > > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of James M. Polk > > Sent: 10 May 2012 21:54 > > To: Hutton, Andrew; insipid@ietf.org > > Cc: James M. Polk > > Subject: Re: [Insipid] INSIPID Req#9 - comments? > > > > Andy > > > > I don't want this to come off as too confrontational, but saying "I > > doubt it is a good idea" isn't technical enough for many to agree with > > you. > > > > Picking only on RTCP, can you specifically list a few scenarios in > > which it will break RTCP? > > > > As to "Is it really a requirement for the identifier to be used to > > associate signaling with media", right now that's req#9 because the > > requirements document lists it as a requirement. Saying only that you > > don't like something doesn't make it go away. We need more technical > > details as to why it doesn't make sense or why it breaks X and Y, and > > you need to be more open to others wanting to counter what you say for > > cases in which it does make sense. > > > > Is this agreeable? > > > > James > > > > At 05:43 AM 5/9/2012, Hutton, Andrew wrote: > > >Hi, > > > > > >Regarding the requirement for making the identifier suitable for > > >transmission in RTCP and the associated use case of associating > > >signaling and media flows. > > > > > >I doubt that it is a good idea to attempt to include the same > > >identifier in the media/RTCP as the signaling as even if this is > > >possible in some scenarios it is most likely not possible in many and > > >will break in others. > > > > > >Is it really a requirement for the identifier to be used to associate > > >signaling with media personally I am thinking it is not. > > > > > >Regards > > >Andy > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] > > > > On Behalf Of James M. Polk > > > > Sent: 26 April 2012 21:06 > > > > To: insipid@ietf.org > > > > Subject: [Insipid] INSIPID Req#9 - comments? > > > > > > > > Figure it is about time I sent these requirements out to the list. > > > > Comments, questions and wordsmithing are encouraged. Let's see if > > we > > > > can leave much of the wordsmithing till the end of the discussion, > > > > once we have agreed on the requirement's worthiness and contents. > > > > > > > > Let's also keep the discussion on *this* thread to just *this* > > > > requirement for tracking purposes. There are 9 current > > requirements. > > > > Therefore, there will be 9 different messages sent to this list. > > > > > > > > Here is REQ#9 as currently written in > > > > http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id > > > > - > > > > reqts-00.txt > > > > > > > > REQ9: The identifier should be constructed in such a way as > > > > to make it suitable for transmission in SIP, H.323, RSVP > > > > [3], and RTCP [4]. > > > > > > > > _______________________________________________ > > > > insipid mailing list > > > > insipid@ietf.org > > > > https://www.ietf.org/mailman/listinfo/insipid > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed May 16 07:52:14 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A150E21F85EF for ; Wed, 16 May 2012 07:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 OBeA4O0KFWyE for ; Wed, 16 May 2012 07:52:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 145A621F8622 for ; Wed, 16 May 2012 07:52:09 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q4GEq3gF016545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 May 2012 10:52:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1337179923; bh=L0X72dngy8UQj697Zzy/yafmJZiVMfGTXcpjK7CW24E=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=L8ttz3OHgK6/cA6pO0TALQY12em0Vnwy3CDa0PRCO7ng1w/VBQeYF1Is2DHMAYovd uniYYfW716m8d97OxTEQpruHoz83Mb3o1jgtjE341/MpH7l7N0W/AEdXEWQq4g4Jhq guDCsqDOYPuf/uxbkyCNTPUczGUbK7uVKjmdWxsQ= From: "Paul E. Jones" To: "'Brett Tate'" , "'James M. Polk'" , References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BC9EC2@EXMBXCLUS01.citservers.local> <4FA39C1A.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA020@EXMBXCLUS01.citservers.local> <4FA3D62D.4030709@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25BCA0B5@EXMBXCLUS01.citservers.local> <101C6067BEC68246B0C3F6843BCCC1E312A742B4A6@MCHP058A.global-ad.net> <4FAA6FE5.7000808@packetizer.com> <201205112255.q4BMsvr2021540@mtv-core-1.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2CA41FF3@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2CA41FF3@EXMBXCLUS01.citservers.local> Date: Wed, 16 May 2012 10:52:05 -0400 Message-ID: <022d01cd3373$76831490$63893db0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLIuEe130ArHQfGJiMJguLwyZJy0gLTYqH6ArwhTDACEzrW8AF4qnr9AUNrXdUBslaiuQI4e34mAkxf9A4C0DLK4pQ6RIaw Content-Language: en-us Subject: Re: [Insipid] INSIPID Req#2 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 14:52:14 -0000 How is this: REQ2: It must be possible to identify the end-to-end session when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a PBX). Note that this might result in a change in the value of the end-to-end Session-Identifier. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Brett Tate > Sent: Monday, May 14, 2012 7:35 AM > To: James M. Polk; insipid@ietf.org > Subject: Re: [Insipid] INSIPID Req#2 - comments? > > > I'm with Paul J. here, let's not make it a requirement to have to > > change the session-ID, though we can add some text to a motivation > > part around this REQ by saying it will likely change the ID. > > I agree; that was basically my suggested change. > > "I recommend REQ2 (or whichever requirement implies such a thing) be > modified to explicitly indicate that meeting the requirement may cause the > session identifier to change within an existing dialog. I recommend being > explicit because it appears to go beyond the current charter. And if I > recall correctly, it was one of the controversial topics during the > chartering process." > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Fri May 18 02:28:47 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B28B21F8603 for ; Fri, 18 May 2012 02:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 EzoqPGeFo0B7 for ; Fri, 18 May 2012 02:28:46 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 040E521F85F8 for ; Fri, 18 May 2012 02:28:46 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 99BDD1EB845D; Fri, 18 May 2012 11:28:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 18 May 2012 11:28:44 +0200 From: "Hutton, Andrew" To: "Paul E. Jones" , "'James M. Polk'" , "insipid@ietf.org" Date: Fri, 18 May 2012 11:28:41 +0200 Thread-Topic: [Insipid] INSIPID Req#9 - comments? Thread-Index: AQKUymPVogtMP86s0HvhOJDlCRCzPAKL57OtAnvmjOgAj+WjcZUQkVzQgALHrpA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312A76345BF@MCHP058A.global-ad.net> References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> <201205112254.q4BMsvqu021540@mtv-core-1.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A7633C4E@MCHP058A.global-ad.net> <022b01cd3373$28fc4750$7af4d5f0$@packetizer.com> In-Reply-To: <022b01cd3373$28fc4750$7af4d5f0$@packetizer.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: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 09:28:47 -0000 Hi Paul, I understand the desire to associate signaling with media but this to me is= clearly not within the scope of the INSIPID charter which only talks about= correlating SIP Messages and dialogs so we should not have requirements an= d use cases for correlating signaling with media. I think we need to clarify this and some of the terminology before moving f= orward for example when do we really mean a "dialog" and when do we mean a = "session". For example REQ3 in your draft which currently states "REQ3: It must be possible to identify all sessions participating in a mult= ipoint or multi-party conference by observing the end-to-end session identi= fiers of each session". Should this really be: "REQ3: It must be possible to identify all SIP dialogs participating in a m= ultipoint or multi-party conference by observing the end-to-end session ide= ntifiers of each SIP dialog". Regards Andy > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: 16 May 2012 15:50 > To: Hutton, Andrew; 'James M. Polk'; insipid@ietf.org > Subject: RE: [Insipid] INSIPID Req#9 - comments? >=20 > Andy, >=20 > I do have a desire to associate signaling with media flows, and to > associate > one flow with another flow. The Session-ID could be used for that for > me. > Perhaps I would not use the Session-ID directly, but perhaps I might. > If > the Session-ID was defined as two GUIDs (Alice || Bob), perhaps > sha(Alice||Bob) might serve my purposes. >=20 > A SIP session is not only the call signaling, but the associated media > flows, too. I would not necessary expect some value inserted into > every RTP > packet or RTCP packet, etc., but we should strive for a construction > that > would potentially allow for its inclusion. What I would like to avoid > is > some long, variable-length ASCII string that makes it a challenge to > use > anywhere outside of an INVITE or 200. I'd like a reasonably compact > binary > encoding (that can also be expressed in ASCII). >=20 > Paul >=20 > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf > > Of Hutton, Andrew > > Sent: Saturday, May 12, 2012 7:54 AM > > To: James M. Polk; insipid@ietf.org > > Subject: Re: [Insipid] INSIPID Req#9 - comments? > > > > Hi James, > > > > Don't worry about being confrontational that's part of the fun. > > > > The main issue from my point of view is to determine whether > correlating > > the media streams with signaling is a problem that the INSIPID WG is > going > > to tackle. My understanding was that the WG was tasked with > standardizing > > an identifier which could be passed end to end over the signaling > path > > without being mangled by intermediaries. If the same identifier could > be > > used over other session establishment protocols like H.323 then that > would > > be also be nice. However I did not envisage that the same identifier > was > > going to be used on the media plane. > > > > The issue of correlating the media and signaling streams is a > different > > problem space that I for one had not envisaged was within scope of > INSIPID > > and one for which I have not seen the same need. > > > > I did not say that including such an identifier in RTCP would break > RTCP > > and I don't think it would. However any mechanism for correlating > media > > streams with signaling will break in some scenarios. It has to be > assumed > > that the signaling and media will not flow through the same set of > > intermediaries and therefore there is always scope for things to go > wrong > > if you are attempting to use the same identifier in both signaling > and > > media. > > > > I would argue that the use case below is not a valid use case within > the > > scope of INSIPID and there should be no requirement to be able to > include > > the identifier in RTCP and probably not RSVP either. > > > > "Association of session signaling and media flows, made possible by > > including the session identifier in media-related messages (e.g., > RSVP or > > RTCP). > > > > Regards > > Andy > > > > > > > > > > > > > -----Original Message----- > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > > Behalf Of James M. Polk > > > Sent: 10 May 2012 21:54 > > > To: Hutton, Andrew; insipid@ietf.org > > > Cc: James M. Polk > > > Subject: Re: [Insipid] INSIPID Req#9 - comments? > > > > > > Andy > > > > > > I don't want this to come off as too confrontational, but saying "I > > > doubt it is a good idea" isn't technical enough for many to agree > with > > > you. > > > > > > Picking only on RTCP, can you specifically list a few scenarios in > > > which it will break RTCP? > > > > > > As to "Is it really a requirement for the identifier to be used to > > > associate signaling with media", right now that's req#9 because the > > > requirements document lists it as a requirement. Saying only that > you > > > don't like something doesn't make it go away. We need more > technical > > > details as to why it doesn't make sense or why it breaks X and Y, > and > > > you need to be more open to others wanting to counter what you say > for > > > cases in which it does make sense. > > > > > > Is this agreeable? > > > > > > James > > > > > > At 05:43 AM 5/9/2012, Hutton, Andrew wrote: > > > >Hi, > > > > > > > >Regarding the requirement for making the identifier suitable for > > > >transmission in RTCP and the associated use case of associating > > > >signaling and media flows. > > > > > > > >I doubt that it is a good idea to attempt to include the same > > > >identifier in the media/RTCP as the signaling as even if this is > > > >possible in some scenarios it is most likely not possible in many > and > > > >will break in others. > > > > > > > >Is it really a requirement for the identifier to be used to > associate > > > >signaling with media personally I am thinking it is not. > > > > > > > >Regards > > > >Andy > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: insipid-bounces@ietf.org [mailto:insipid- > bounces@ietf.org] > > > > > On Behalf Of James M. Polk > > > > > Sent: 26 April 2012 21:06 > > > > > To: insipid@ietf.org > > > > > Subject: [Insipid] INSIPID Req#9 - comments? > > > > > > > > > > Figure it is about time I sent these requirements out to the > list. > > > > > Comments, questions and wordsmithing are encouraged. Let's see > if > > > we > > > > > can leave much of the wordsmithing till the end of the > discussion, > > > > > once we have agreed on the requirement's worthiness and > contents. > > > > > > > > > > Let's also keep the discussion on *this* thread to just *this* > > > > > requirement for tracking purposes. There are 9 current > > > requirements. > > > > > Therefore, there will be 9 different messages sent to this > list. > > > > > > > > > > Here is REQ#9 as currently written in > > > > > http://www.ietf.org/internet-drafts/draft-jones-insipid- > session-id > > > > > - > > > > > reqts-00.txt > > > > > > > > > > REQ9: The identifier should be constructed in such a way as > > > > > to make it suitable for transmission in SIP, H.323, RSVP > > > > > [3], and RTCP [4]. > > > > > > > > > > _______________________________________________ > > > > > insipid mailing list > > > > > insipid@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/insipid > > > > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Fri May 18 05:58:55 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F79921F86B2 for ; Fri, 18 May 2012 05:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 D8l1atWBB4Ru for ; Fri, 18 May 2012 05:58:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7915B21F8665 for ; Fri, 18 May 2012 05:58:54 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q4ICwqH5029453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 May 2012 08:58:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1337345933; bh=TeXZm+oW3pnF1Qk6JdLB4qWrQBvLXzA80ElnOy740pg=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QzR2ktJAGyLtfzxTZy2QDtqhwzXvctV1vzCvAs4HnlZBw93LgeR2BAxMu2ot6WjIj tBRXuWLBVHY6CLnrdZGTglmwQy7kP7iUpmaqi6ZosAorkR0lmp6IJy1zUG99AHB03r zTtFoGMgdRTikyvpugHJEfudXULrtpZM8sr9q8iw= From: "Paul E. Jones" To: "'Hutton, Andrew'" , "'James M. Polk'" , References: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A742B49D@MCHP058A.global-ad.net> <201205112254.q4BMsvqu021540@mtv-core-1.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E312A7633C4E@MCHP058A.global-ad.net> <022b01cd3373$28fc4750$7af4d5f0$@packetizer.com> <101C6067BEC68246B0C3F6843BCCC1E312A76345BF@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A76345BF@MCHP058A.global-ad.net> Date: Fri, 18 May 2012 08:58:56 -0400 Message-ID: <023301cd34f5$fc701c50$f55054f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKUymPVogtMP86s0HvhOJDlCRCzPAKL57OtAnvmjOgAj+WjcQLsaHczAWilQLKU8O9ZcA== Content-Language: en-us Subject: Re: [Insipid] INSIPID Req#9 - comments? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 12:58:55 -0000 Andrew, > I understand the desire to associate signaling with media but this to me > is clearly not within the scope of the INSIPID charter which only talks > about correlating SIP Messages and dialogs so we should not have > requirements and use cases for correlating signaling with media. The requirement does not say that flows must be correlated. We merely propose that the identifier be constructed in such a way that it can be carried in other protocols. How it might be used on those other protocols is outside the scope of this document. There document only says it might be used for other purposes, but does not require it. > I think we need to clarify this and some of the terminology before moving > forward for example when do we really mean a "dialog" and when do we mean > a "session". For example REQ3 in your draft which currently states We debated that. Some wanted to define it and some did not. However, a "session" or "communication" session in my documents is always the same -- it is an end-to-end (dare I say) "session". It might be comprised of one or more dialogs. > "REQ3: It must be possible to identify all sessions participating in a > multipoint or multi-party conference by observing the end-to-end session > identifiers of each session". This does not mean multiple dialogs. This means multiple sessions. If there are 10 people (10 different "calls" or "sessions") participating in a conference, it would be desirable to be able to recognize that all 10 are participants in the same conference. Paul > Should this really be: > > "REQ3: It must be possible to identify all SIP dialogs participating in a > multipoint or multi-party conference by observing the end-to-end session > identifiers of each SIP dialog". > > Regards > Andy > > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: 16 May 2012 15:50 > > To: Hutton, Andrew; 'James M. Polk'; insipid@ietf.org > > Subject: RE: [Insipid] INSIPID Req#9 - comments? > > > > Andy, > > > > I do have a desire to associate signaling with media flows, and to > > associate one flow with another flow. The Session-ID could be used > > for that for me. > > Perhaps I would not use the Session-ID directly, but perhaps I might. > > If > > the Session-ID was defined as two GUIDs (Alice || Bob), perhaps > > sha(Alice||Bob) might serve my purposes. > > > > A SIP session is not only the call signaling, but the associated media > > flows, too. I would not necessary expect some value inserted into > > every RTP packet or RTCP packet, etc., but we should strive for a > > construction that would potentially allow for its inclusion. What I > > would like to avoid is some long, variable-length ASCII string that > > makes it a challenge to use anywhere outside of an INVITE or 200. I'd > > like a reasonably compact binary encoding (that can also be expressed > > in ASCII). > > > > Paul > > > > > -----Original Message----- > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf > > > Of Hutton, Andrew > > > Sent: Saturday, May 12, 2012 7:54 AM > > > To: James M. Polk; insipid@ietf.org > > > Subject: Re: [Insipid] INSIPID Req#9 - comments? > > > > > > Hi James, > > > > > > Don't worry about being confrontational that's part of the fun. > > > > > > The main issue from my point of view is to determine whether > > correlating > > > the media streams with signaling is a problem that the INSIPID WG is > > going > > > to tackle. My understanding was that the WG was tasked with > > standardizing > > > an identifier which could be passed end to end over the signaling > > path > > > without being mangled by intermediaries. If the same identifier > > > could > > be > > > used over other session establishment protocols like H.323 then that > > would > > > be also be nice. However I did not envisage that the same identifier > > was > > > going to be used on the media plane. > > > > > > The issue of correlating the media and signaling streams is a > > different > > > problem space that I for one had not envisaged was within scope of > > INSIPID > > > and one for which I have not seen the same need. > > > > > > I did not say that including such an identifier in RTCP would break > > RTCP > > > and I don't think it would. However any mechanism for correlating > > media > > > streams with signaling will break in some scenarios. It has to be > > assumed > > > that the signaling and media will not flow through the same set of > > > intermediaries and therefore there is always scope for things to go > > wrong > > > if you are attempting to use the same identifier in both signaling > > and > > > media. > > > > > > I would argue that the use case below is not a valid use case within > > the > > > scope of INSIPID and there should be no requirement to be able to > > include > > > the identifier in RTCP and probably not RSVP either. > > > > > > "Association of session signaling and media flows, made possible by > > > including the session identifier in media-related messages (e.g., > > RSVP or > > > RTCP). > > > > > > Regards > > > Andy > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] > > > > On Behalf Of James M. Polk > > > > Sent: 10 May 2012 21:54 > > > > To: Hutton, Andrew; insipid@ietf.org > > > > Cc: James M. Polk > > > > Subject: Re: [Insipid] INSIPID Req#9 - comments? > > > > > > > > Andy > > > > > > > > I don't want this to come off as too confrontational, but saying > > > > "I doubt it is a good idea" isn't technical enough for many to > > > > agree > > with > > > > you. > > > > > > > > Picking only on RTCP, can you specifically list a few scenarios in > > > > which it will break RTCP? > > > > > > > > As to "Is it really a requirement for the identifier to be used to > > > > associate signaling with media", right now that's req#9 because > > > > the requirements document lists it as a requirement. Saying only > > > > that > > you > > > > don't like something doesn't make it go away. We need more > > technical > > > > details as to why it doesn't make sense or why it breaks X and Y, > > and > > > > you need to be more open to others wanting to counter what you say > > for > > > > cases in which it does make sense. > > > > > > > > Is this agreeable? > > > > > > > > James > > > > > > > > At 05:43 AM 5/9/2012, Hutton, Andrew wrote: > > > > >Hi, > > > > > > > > > >Regarding the requirement for making the identifier suitable for > > > > >transmission in RTCP and the associated use case of associating > > > > >signaling and media flows. > > > > > > > > > >I doubt that it is a good idea to attempt to include the same > > > > >identifier in the media/RTCP as the signaling as even if this is > > > > >possible in some scenarios it is most likely not possible in many > > and > > > > >will break in others. > > > > > > > > > >Is it really a requirement for the identifier to be used to > > associate > > > > >signaling with media personally I am thinking it is not. > > > > > > > > > >Regards > > > > >Andy > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: insipid-bounces@ietf.org [mailto:insipid- > > bounces@ietf.org] > > > > > > On Behalf Of James M. Polk > > > > > > Sent: 26 April 2012 21:06 > > > > > > To: insipid@ietf.org > > > > > > Subject: [Insipid] INSIPID Req#9 - comments? > > > > > > > > > > > > Figure it is about time I sent these requirements out to the > > list. > > > > > > Comments, questions and wordsmithing are encouraged. Let's see > > if > > > > we > > > > > > can leave much of the wordsmithing till the end of the > > discussion, > > > > > > once we have agreed on the requirement's worthiness and > > contents. > > > > > > > > > > > > Let's also keep the discussion on *this* thread to just *this* > > > > > > requirement for tracking purposes. There are 9 current > > > > requirements. > > > > > > Therefore, there will be 9 different messages sent to this > > list. > > > > > > > > > > > > Here is REQ#9 as currently written in > > > > > > http://www.ietf.org/internet-drafts/draft-jones-insipid- > > session-id > > > > > > - > > > > > > reqts-00.txt > > > > > > > > > > > > REQ9: The identifier should be constructed in such a way as > > > > > > to make it suitable for transmission in SIP, H.323, RSVP > > > > > > [3], and RTCP [4]. > > > > > > > > > > > > _______________________________________________ > > > > > > insipid mailing list > > > > > > insipid@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/insipid > > > > > > > > _______________________________________________ > > > > insipid mailing list > > > > insipid@ietf.org > > > > https://www.ietf.org/mailman/listinfo/insipid > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Tue May 29 06:05:07 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9E21F845A for ; Tue, 29 May 2012 06:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCRt-TzTUSBH for ; Tue, 29 May 2012 06:05:06 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE6121F8656 for ; Tue, 29 May 2012 06:05:06 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4TD4mcT010714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 29 May 2012 15:05:03 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 29 May 2012 15:04:56 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Tue, 29 May 2012 15:04:54 +0200 Thread-Topic: [Insipid] INSIPID Virtual Interim Meeting: Dial-in details via Webex Thread-Index: Ac0y3OQScB/Vdd8KSBGugY9i295EJwKvkbmQ Message-ID: References: <0E05A9D5-9337-4DAE-8FC6-BC04C3BFC120@cisco.com> In-Reply-To: <0E05A9D5-9337-4DAE-8FC6-BC04C3BFC120@cisco.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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Insipid] INSIPID Virtual Interim Meeting: Dial-in details via Webex X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 13:05:07 -0000 A reminder of the interim today. While the Webex bridge will come up at 8:45, in order to allow you all to g= et connected in time, the interim will start at 9:00 Pacific time. Details = below. I have so far received no refreshed slides. If you have any then please sen= d them. I am about to start uploading existing slides to the meeting materials site= which you will find here: http://www.ietf.org/meeting/interim/proceedings.html=20 regards Keith -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Gonzalo Salgueiro Sent: 15 May 2012 21:54 To: insipid@ietf.org Subject: [Insipid] INSIPID Virtual Interim Meeting: Dial-in details via Web= ex Hello Folks -=20 We will use Webex to host the INSIPID virtual interim meeting. See below fo= r the "dial-in" details. For completeness the previously published agenda i= s included at the bottom of this message. INtermediary-safe SIP session ID (INSIPID) Group invites you to attend this= online meeting.=20 Topic: INSIPID WG Interim=20 Date: Tuesday, May 29, 2012=20 Time: 8:45 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 961 449 580=20 Meeting Password: 1234=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D193859087&UID=3D1= 285555207&PW=3DNZGJjMGI0Mzgz&RT=3DMiM0=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: 1234=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 https://workgreen.webex.com/workgreen/j.php?ED=3D193859087&UID=3D1285555207= &PW=3DNZGJjMGI0Mzgz&ORT=3DMiM0=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code.=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.= php?serviceType=3DMC&ED=3D193859087&tollFree=3D0=20 Access code:961 449 580=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 cmorgan@amsl.com=20 1-510-492-4085=20 To update this meeting to your calendar program (for example Microsoft Outl= ook), click this link:=20 https://workgreen.webex.com/workgreen/j.php?ED=3D193859087&UID=3D1285555207= &ICS=3DMRS1&LD=3D1&RD=3D2&ST=3D1&SHA2=3D07eDCG0TzTGC2TAQfqHhZ7Xz22qylDWvzPy= QidKMKD8=3D&RT=3DMiM0=20 WebEx will automatically setup Meeting Manager for Windows the first time y= ou join a meeting. To save time, you can setup prior to the meeting by clic= king this link:=20 https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php=20 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://workgreen.webex.com/workgreen/systemdiagnosis.php.=20 Sign up for a free trial of WebEx=20 http://www.webex.com/go/mcemfreetrial=20 http://www.webex.com=20 CCP:+14087926300x961449580#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation.=20 -------------------------------------------------------- 1) Agenda bash, notetakers, etc 2) Scope of requirements / use cases document [Note identified presenters are those that were designated for Paris - plea= se let me know if this now changes, or you wish to revise your slides, othe= rwise I'll upload the existing slidepacks from IETF83] Session Initiation Protocol (SIP) Header Parameter for Debugging draft-dawes-dispatch-debug-00 Peter Dawes https://datatracker.ietf.org/doc/draft-dawes-dispatch-debug Session Initiation Protocol (SIP) Extension for logging and debugging draft-kaithal-dispatch-sip-log-information-00 Parthasarathi Ravindran (on behalf of Adarsh Kaithal / Sandeep K S) https://datatracker.ietf.org/doc/draft-kaithal-dispatch-sip-log-information= / [Listed because it is identified by draft-dawes-dispatch-debug] A Session Identifier for the Session Initiation Protocol (SIP) (ANNEX A ONL= Y) draft-kaplan-dispatch-session-id-03 Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03 3) Discussion of individual requirements Requirements for an End-to-End Session Identification in IP-Based Multimedi= a Communication Networks draft-jones-ipmc-session-id-reqts-01 Paul Jones / James Polk / Parthasarathi Ravindran / Laura Liess / Roland Je= sske / Salvatore Loreto / Hadriel Kaplan https://datatracker.ietf.org/doc/draft-jones-ipmc-session-id-reqts/ Focus on specific issues from mailing list discussion 4) Next steps --------------------------------- Cheers, Gonzalo _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From gonzalo.camarillo@ericsson.com Tue May 29 08:19:46 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144AF11E808A for ; Tue, 29 May 2012 08:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv+inYwPUinb for ; Tue, 29 May 2012 08:19:45 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A297421F8733 for ; Tue, 29 May 2012 08:19:44 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-eb-4fc4e90f64d7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 46.A3.00702.F09E4CF4; Tue, 29 May 2012 17:19:43 +0200 (CEST) Received: from [131.160.126.134] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Tue, 29 May 2012 17:19:43 +0200 Message-ID: <4FC4E90E.6000405@ericsson.com> Date: Tue, 29 May 2012 18:19:42 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "insipid@ietf.org" References: <0E05A9D5-9337-4DAE-8FC6-BC04C3BFC120@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3Vpf/5RF/gy9HNCzm33/G5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPl/DzAWzDWsmNFykLWBca5mFyMnh4SAicTF3zuZIGwxiQv3 1rN1MXJxCAmcYpTY2HiDHcJZyyhxbFc3WBWvgLbE0cbTYDaLgKrEhb8n2UFsNgELiS237rOA 2KICwRLzum+yQNQLSpyc+QTMFhHQlPh44xwziC0MVPNo2zuobX2MEk9v72YDSXAKxEnMOrSN EeIkSYmD/66BLWAW0JOYcrWFEcKWl9j+dg7YICGgg5Y/a2GZwCg4C8m+WUhaZiFpWcDIvIpR ODcxMye93FwvtSgzubg4P0+vOHUTIzA0D275bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUw7uqObGFvi1vB3xhconrrl+1t2w8P+p0nG7veNfOKP79xr3GQ f1Ju+qmCHg4ncYe9i/2zS7z2OLyQPMnw5c7KQ2yhE07Psc49tX2y680tHQtVYq6Zqn+2TkzO f/I6eNqX1OPTirTWPAs+d2aJ6pFNB5b5CR2ecL24vWH/pzsMt9VzRb2z70zNUWIpzkg01GIu Kk4EAFcWRT0bAgAA Subject: Re: [Insipid] INSIPID Virtual Interim Meeting: Dial-in details via Webex X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 15:19:46 -0000 Hi, in particular, you can find the slides at: http://www.ietf.org/proceedings/interim/2012/05/29/insipid/proceedings.html Cheers, Gonzalo On 29/05/2012 4:04 PM, DRAGE, Keith (Keith) wrote: > A reminder of the interim today. > > While the Webex bridge will come up at 8:45, in order to allow you all to get connected in time, the interim will start at 9:00 Pacific time. Details below. > > I have so far received no refreshed slides. If you have any then please send them. > > I am about to start uploading existing slides to the meeting materials site which you will find here: > > http://www.ietf.org/meeting/interim/proceedings.html > > regards > > Keith > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro > Sent: 15 May 2012 21:54 > To: insipid@ietf.org > Subject: [Insipid] INSIPID Virtual Interim Meeting: Dial-in details via Webex > > Hello Folks - > > We will use Webex to host the INSIPID virtual interim meeting. See below for the "dial-in" details. For completeness the previously published agenda is included at the bottom of this message. > > > INtermediary-safe SIP session ID (INSIPID) Group invites you to attend this online meeting. > > Topic: INSIPID WG Interim > Date: Tuesday, May 29, 2012 > Time: 8:45 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 961 449 580 > Meeting Password: 1234 > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=193859087&UID=1285555207&PW=NZGJjMGI0Mzgz&RT=MiM0 > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: 1234 > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://workgreen.webex.com/workgreen/j.php?ED=193859087&UID=1285555207&PW=NZGJjMGI0Mzgz&ORT=MiM0 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. > Call-in toll number (US/Canada): 1-408-792-6300 > Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=193859087&tollFree=0 > > Access code:961 449 580 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > cmorgan@amsl.com > 1-510-492-4085 > > To update this meeting to your calendar program (for example Microsoft Outlook), click this link: > https://workgreen.webex.com/workgreen/j.php?ED=193859087&UID=1285555207&ICS=MRS1&LD=1&RD=2&ST=1&SHA2=07eDCG0TzTGC2TAQfqHhZ7Xz22qylDWvzPyQidKMKD8=&RT=MiM0 > > > WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: > https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+14087926300x961449580# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. > > -------------------------------------------------------- > 1) Agenda bash, notetakers, etc > > 2) Scope of requirements / use cases document > > [Note identified presenters are those that were designated for Paris - please let me know if this now changes, or you wish to revise your slides, otherwise I'll upload the existing slidepacks from IETF83] > > Session Initiation Protocol (SIP) Header Parameter for Debugging > draft-dawes-dispatch-debug-00 > Peter Dawes > https://datatracker.ietf.org/doc/draft-dawes-dispatch-debug > > Session Initiation Protocol (SIP) Extension for logging and debugging > draft-kaithal-dispatch-sip-log-information-00 > Parthasarathi Ravindran (on behalf of Adarsh Kaithal / Sandeep K S) > https://datatracker.ietf.org/doc/draft-kaithal-dispatch-sip-log-information/ > [Listed because it is identified by draft-dawes-dispatch-debug] > > A Session Identifier for the Session Initiation Protocol (SIP) (ANNEX A ONLY) > draft-kaplan-dispatch-session-id-03 > Hadriel Kaplan > http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03 > > 3) Discussion of individual requirements > > Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks > draft-jones-ipmc-session-id-reqts-01 > Paul Jones / James Polk / Parthasarathi Ravindran / Laura Liess / Roland Jesske / Salvatore Loreto / Hadriel Kaplan > https://datatracker.ietf.org/doc/draft-jones-ipmc-session-id-reqts/ > > Focus on specific issues from mailing list discussion > > 4) Next steps > --------------------------------- > > Cheers, > > Gonzalo > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > > From adam@nostrum.com Tue May 29 09:34:11 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C8B11E80B0 for ; Tue, 29 May 2012 09:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrC8vrwf-Nlt for ; Tue, 29 May 2012 09:34:11 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 64DB911E80AD for ; Tue, 29 May 2012 09:34:09 -0700 (PDT) Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4TGY8xg022089 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 29 May 2012 11:34:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4FC4FA80.8040600@nostrum.com> Date: Tue, 29 May 2012 11:34:08 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "insipid@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: [Insipid] Logging and its relationship with INSIPID X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:34:11 -0000 I get the impression that my audio input into the bridge was pretty bad, so I want to summarize my comment here. From what I can tell, the issue of call logging is a fairly large problem space, possibly as large as or larger than the whole call identification problem itself. So, I think the impact on the INSIPID working group is a requirement along the lines of "The identifier MUST be suitable for use in correlating logs generated by multiple network entities." The rest of the problem, I believe, needs to be brought to DISPATCH. I suspect a new working group would be warranted, given the scope of the work I've seen proposed so far. /a From gsalguei@cisco.com Tue May 29 10:20:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B079621F85AE for ; Tue, 29 May 2012 10:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xElrfJThlKNG for ; Tue, 29 May 2012 10:20:00 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 93CF921F844A for ; Tue, 29 May 2012 10:19:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4THJl8U003876 for ; Tue, 29 May 2012 13:19:47 -0400 (EDT) Received: from dhcp-10-150-53-247.cisco.com (dhcp-10-150-53-247.cisco.com [10.150.53.247]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4THJkvW007928; Tue, 29 May 2012 13:19:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <4FC4FA80.8040600@nostrum.com> Date: Tue, 29 May 2012 13:19:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2137A9C2-AE0E-42E3-B768-4F7E030331F0@cisco.com> References: <4FC4FA80.8040600@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1278) Cc: insipid@ietf.org Subject: Re: [Insipid] Logging and its relationship with INSIPID X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 17:20:01 -0000 +1 on all points Cheers, Gonzalo On May 29, 2012, at 12:34 PM, Adam Roach wrote: > I get the impression that my audio input into the bridge was pretty = bad, so I want to summarize my comment here. >=20 > =46rom what I can tell, the issue of call logging is a fairly large = problem space, possibly as large as or larger than the whole call = identification problem itself. >=20 > So, I think the impact on the INSIPID working group is a requirement = along the lines of "The identifier MUST be suitable for use in = correlating logs generated by multiple network entities." >=20 > The rest of the problem, I believe, needs to be brought to DISPATCH. I = suspect a new working group would be warranted, given the scope of the = work I've seen proposed so far. >=20 > /a > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From paulej@packetizer.com Tue May 29 12:45:36 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D43011E8117 for ; Tue, 29 May 2012 12:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOgwOeVS+C88 for ; Tue, 29 May 2012 12:45:35 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC5C11E80E2 for ; Tue, 29 May 2012 12:45:35 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q4TJjYAZ001007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 29 May 2012 15:45:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1338320734; bh=7boLEE53zmPOuXaw1TeOP8PyhndBXG28Oh3lTP8PhT0=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=UPII8rLwLwl09T51k+g4WER/fpWrKoONg8fq8IIDf/i3hSxGQl3RSWMqfIjutPUop 53E0dpknYyqnboKWUP8r+ZIb+oIoqMPMkVg9PnrNovJvsgcMFcVn4pvAtvpjHJRoGY oNf9xOBRULnkOy+KBb+d5R6pmtEzj8Il3mi0ZzaQ= From: "Paul E. Jones" To: Date: Tue, 29 May 2012 15:45:39 -0400 Message-ID: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FE_01CD3DB2.193F3C20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac090wzWy9p+WCsrQk27dM+DK4ieVQ== Content-Language: en-us Subject: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 19:45:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02FE_01CD3DB2.193F3C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, As requested, I posted a revised version of the INSIPID requirements document, taking into consideration the discussions from the call today. Here's the text: http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01 Note that Requirement 1a needs to be completed. I'd be delighted if someone could propose some wording for that. As discussed on the call, the meaning of requirement 6 was changed quite substantially in meaning from the -00 draft. We need to decide exactly what meaning we want or introduce a new requirement if we want to both hide information and also not reveal that an SBC, for example, might have changed any of that information. Paul ------=_NextPart_000_02FE_01CD3DB2.193F3C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

As = requested, I posted a revised version of the INSIPID requirements = document, taking into consideration the discussions from the call = today.  Here’s the text:

http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01=

 

Note that Requirement 1a needs to be completed.  = I’d be delighted if someone could propose some wording for = that.

 

As discussed on the call, the meaning of requirement 6 = was changed quite substantially in meaning from the -00 draft.  We = need to decide exactly what meaning we want or introduce a new = requirement if we want to both hide information and also not reveal that = an SBC, for example, might have changed any of that = information.

 

Paul

 

------=_NextPart_000_02FE_01CD3DB2.193F3C20-- From pravindran@sonusnet.com Wed May 30 00:08:53 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841C421F86B4 for ; Wed, 30 May 2012 00:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l28M27Abu+e0 for ; Wed, 30 May 2012 00:08:53 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id DAE6B11E8079 for ; Wed, 30 May 2012 00:08:47 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKT8XHf8kOfPOGU2BFhpF/t01PCYAXHorU@postini.com; Wed, 30 May 2012 00:08:47 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 30 May 2012 03:09:11 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 30 May 2012 12:38:41 +0530 From: "Ravindran, Parthasarathi" To: Gonzalo Salgueiro , Adam Roach Thread-Topic: [Insipid] Logging and its relationship with INSIPID Thread-Index: AQHNPbjkNwE8W+0oaEKFJkoLLVsWjZbgptcAgAE5B0A= Date: Wed, 30 May 2012 07:08:40 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160387EE@inba-mail01.sonusnet.com> References: <4FC4FA80.8040600@nostrum.com> <2137A9C2-AE0E-42E3-B768-4F7E030331F0@cisco.com> In-Reply-To: <2137A9C2-AE0E-42E3-B768-4F7E030331F0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid@ietf.org" Subject: Re: [Insipid] Logging and its relationship with INSIPID X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 07:08:53 -0000 +1 I have presented "Session Initiation Protocol (SIP) Extension for logging = and debugging" draft usecase for the below reason. Thanks Partha >-----Original Message----- >From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >Behalf Of Gonzalo Salgueiro >Sent: Tuesday, May 29, 2012 10:50 PM >To: Adam Roach >Cc: insipid@ietf.org >Subject: Re: [Insipid] Logging and its relationship with INSIPID > >+1 on all points > > > >Cheers, > >Gonzalo > >On May 29, 2012, at 12:34 PM, Adam Roach wrote: > >> I get the impression that my audio input into the bridge was pretty >bad, so I want to summarize my comment here. >> >> From what I can tell, the issue of call logging is a fairly large >problem space, possibly as large as or larger than the whole call >identification problem itself. >> >> So, I think the impact on the INSIPID working group is a requirement >along the lines of "The identifier MUST be suitable for use in >correlating logs generated by multiple network entities." >> >> The rest of the problem, I believe, needs to be brought to DISPATCH. I >suspect a new working group would be warranted, given the scope of the >work I've seen proposed so far. >> >> /a >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >> > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Wed May 30 01:53:34 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9721F86D7 for ; Wed, 30 May 2012 01:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 lSCBtvzQ0JYK for ; Wed, 30 May 2012 01:53:34 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C633321F86C8 for ; Wed, 30 May 2012 01:53:33 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 656E31EB8468; Wed, 30 May 2012 10:53:32 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Wed, 30 May 2012 10:53:32 +0200 From: "Hutton, Andrew" To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] Revised requirements document Thread-Index: Ac090wzWy9p+WCsrQk27dM+DK4ieVQAbUlpg Date: Wed, 30 May 2012 08:53:31 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013969@MCHP04MSX.global-ad.net> References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> In-Reply-To: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.249.76] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 08:53:34 -0000 Hi, Yesterday in the call we did not discuss the use cases at all which I think= we need to do as these are from what the requirements are derived. I think it is important to understand what use cases are within scope of IN= SIPID I would like to see the document restructured to describe real use ca= ses and the derived use cases. I think the RTCWEB use case and requirements= draft is a good example of how such requirements drafts should look like. = See http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements= -07.=20 The current draft currently contains the following use cases to which I hav= e some comments. * End-to-end identification of a communication session This is the basic case and as long as we all agree what is meant by a "Comm= unication Session" then it is ok however I would like to see it reworded in= to the form of a real use case. * Association of session signaling and media flows, made possible by including the session identifier in media-related messages (e.g., RSVP or RTCP) I don't think that this use case is within scope of INSIPID which is limite= d to association at the signaling level. Association of media streams shoul= d probably done at the SDP level if needed. We could within INSIPID try to = make sure that any new identifier is in a suitable format to be carried in = other protocols but I don't think we want to specify procedures for includi= ng it in for example RTCP. * Identification of devices taking part in the same multipoint conference Should this be "Association of sessions taking part in the same multipoint = conference"? However I think it should be reworked in to a use case. * Tracking sessions transferred from one endpoint to another Does this need rewording in the form of a use case? I think we will need a = few transfer / redirection use cases to really flesh out the requirements. * Facilitate the recording of SIP sessions and correlating those Sessions This is not a use case and does not add any new requirements over the 1st b= asic end to end identification case. * Logging for the purposes of accounting, billing, debugging, communication tracking (such as for security purposes in case of theft of service), etc. Again these are not use cases from which specific requirements can be deriv= ed. Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: 29 May 2012 20:46 > To: insipid@ietf.org > Subject: [Insipid] Revised requirements document >=20 > Folks, >=20 > As requested, I posted a revised version of the INSIPID requirements > document, taking into consideration the discussions from the call > today.=A0 Here's the text: > http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01 >=20 > Note that Requirement 1a needs to be completed.=A0 I'd be delighted if > someone could propose some wording for that. >=20 > As discussed on the call, the meaning of requirement 6 was changed > quite substantially in meaning from the -00 draft.=A0 We need to decide > exactly what meaning we want or introduce a new requirement if we want > to both hide information and also not reveal that an SBC, for example, > might have changed any of that information. >=20 > Paul From pravindran@sonusnet.com Wed May 30 02:58:36 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D2021F86DB for ; Wed, 30 May 2012 02:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JArpWlYNC+Wm for ; Wed, 30 May 2012 02:58:35 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id BCB1A21F86C4 for ; Wed, 30 May 2012 02:58:34 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKT8XvStk7SXySU8jc1sWx4CSQ+9K2xatm@postini.com; Wed, 30 May 2012 02:58:34 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 30 May 2012 05:58:58 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 30 May 2012 15:28:28 +0530 From: "Ravindran, Parthasarathi" To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] Revised requirements document Thread-Index: Ac090wzWy9p+WCsrQk27dM+DK4ieVQAdt+zg Date: Wed, 30 May 2012 09:58:27 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16038963@inba-mail01.sonusnet.com> References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> In-Reply-To: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.54] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C16038963inbamail01sonus_" MIME-Version: 1.0 Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 09:58:36 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C16038963inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, IMO, REQ-5 and REQ-6 shall be merged together to indicate that "session-id = mechanism MUST not reveal any form of identity in REQ-5 and any form of SIP= messages in REQ-6". REQ-6 is important because it provides confidence to the operator/admin tha= t session-id is safe to be passed across in SBC/PBX. In case it is possible= to use any of the existing SIP headers/body, IMO there is no need to new s= ession-id itself. AFAIK, there is no SIP headers/body exists which qualify = for session-id as of now. Thanks Partha From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: Wednesday, May 30, 2012 1:16 AM To: insipid@ietf.org Subject: [Insipid] Revised requirements document Folks, As requested, I posted a revised version of the INSIPID requirements docume= nt, taking into consideration the discussions from the call today. Here's = the text: http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01 Note that Requirement 1a needs to be completed. I'd be delighted if someon= e could propose some wording for that. As discussed on the call, the meaning of requirement 6 was changed quite su= bstantially in meaning from the -00 draft. We need to decide exactly what = meaning we want or introduce a new requirement if we want to both hide info= rmation and also not reveal that an SBC, for example, might have changed an= y of that information. Paul --_000_387F9047F55E8C42850AD6B3A7A03C6C16038963inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,

 

IMO, REQ-5 and REQ-6 s= hall be merged together to indicate that “session-id mechanism MUST n= ot reveal any form of identity in REQ-5 and any form of SIP messages in REQ= -6”.

 

REQ-6 is important bec= ause it provides confidence to the operator/admin that session-id is safe t= o be passed across in SBC/PBX. In case it is possible to use any of the exi= sting SIP headers/body, IMO there is no need to new session-id itself. AFAIK, there is no SIP headers/body exis= ts which qualify for session-id as of now.

 

Thanks

Partha

 

From: insipid-= bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, May 30, 2012 1:16 AM
To: insipid@ietf.org
Subject: [Insipid] Revised requirements document

 

Folks,

 

As requested, I posted a revised version of the INSI= PID requirements document, taking into consideration the discussions from t= he call today.  Here’s the text:

http://tools.ietf.org/html/draft-jones-insipid-s= ession-id-reqts-01

 

Note that Requirement 1a needs to be completed. = ; I’d be delighted if someone could propose some wording for that.

 

As discussed on the call, the meaning of requirement= 6 was changed quite substantially in meaning from the -00 draft.  We = need to decide exactly what meaning we want or introduce a new requirement = if we want to both hide information and also not reveal that an SBC, for example, might have changed any of that i= nformation.

 

Paul

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C16038963inbamail01sonus_-- From keith.drage@alcatel-lucent.com Wed May 30 11:05:37 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FC021F858D for ; Wed, 30 May 2012 11:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.249 X-Spam-Level: X-Spam-Status: No, score=-108.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 heDPCjYnMe7d for ; Wed, 30 May 2012 11:05:36 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4B77821F858A for ; Wed, 30 May 2012 11:05:35 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4UI5YCe004820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 30 May 2012 20:05:35 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 May 2012 20:05:34 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Wed, 30 May 2012 20:05:33 +0200 Thread-Topic: Future interim meeting dates Thread-Index: Ac0+js5Ths4xYjOSSlSUR920F9w/jA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [Insipid] Future interim meeting dates X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 18:05:37 -0000 (As WG cochair) We had a successful virtual interim yesterday and agreed on dates for a cou= ple more before Vancouver. We still need to deal with the formal announcement of these, but the planne= d dates and times are: Virtual interim 2: Monday June 25th 2012 9:00 am - 11:00 am Pacific Time Virtual interim 3: Tuesday July 10th 2012 9:00 am - 11:00 am Pacific Time Please make a note in your diaries We have also requested a meeting slot in the Vancouver IETF meeting Regards Keith From gsalguei@cisco.com Wed May 30 12:31:34 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C85B11E8111 for ; Wed, 30 May 2012 12:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 NlAuqG-bmKzr for ; Wed, 30 May 2012 12:31:33 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD4F11E80BC for ; Wed, 30 May 2012 12:31:33 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4UJVTLq003341 for ; Wed, 30 May 2012 15:31:29 -0400 (EDT) Received: from dhcp-10-150-53-247.cisco.com (dhcp-10-150-53-247.cisco.com [10.150.53.247]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4UJVThd002027 for ; Wed, 30 May 2012 15:31:29 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 May 2012 15:31:29 -0400 Message-Id: <2FD16C93-CEF9-4D5E-9D2F-F7F455342319@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Insipid] Session ID solution drafts request X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 19:31:34 -0000 Folks: =20 We appear to be making reasonable progress on the requirements and use = cases document. For this reason we are considering dedicating agenda = time at the next virtual interim (June 25th) to preliminary discussions = about the solution proposals for the session id. In order to facilitate = that discussion I would like to encourage folks to submit any candidate = solutions for session id that they wish to be considered by the WG. Cheers, Gonzalo From jmpolk@cisco.com Wed May 30 13:03:06 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DED511E80B7 for ; Wed, 30 May 2012 13:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 CR-UJvHghm7j for ; Wed, 30 May 2012 13:03:06 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0462311E809C for ; Wed, 30 May 2012 13:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=794; q=dns/txt; s=iport; t=1338408186; x=1339617786; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=4wXw9GSgtlJTjhUVNIiL8CTNwJL4fRU7pEjTbQfjTbM=; b=For31sA1IppRFjIz4drsy411YeMwg0TOAtvItSvRAs+AA6shG7mGuIK3 giLYeI6ZQY5h3Xro5CYIf5AkO+mp/OYm5pnZ/Z3/8fzEgy/CzbYIa7HN4 gWUKzs9aIev+rmgZ9mAHlmO2HwuYGiVPirUMx82Lb3+RL06Zret30H0Wa Y=; X-IronPort-AV: E=Sophos;i="4.75,686,1330905600"; d="scan'208";a="47014936" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 30 May 2012 20:03:05 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4UK35am005292; Wed, 30 May 2012 20:03:05 GMT Message-Id: <201205302003.q4UK35am005292@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 May 2012 15:03:05 -0500 To: insipid@ietf.org From: James Polk In-Reply-To: <2FD16C93-CEF9-4D5E-9D2F-F7F455342319@cisco.com> References: <2FD16C93-CEF9-4D5E-9D2F-F7F455342319@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Gonzalo Salgueiro Subject: Re: [Insipid] Session ID solution drafts request X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 20:03:06 -0000 There's this ID that some of us proposed as a solution offering draft-jones-insipid-session-id James At 02:31 PM 5/30/2012, Gonzalo Salgueiro wrote: >Folks: > >We appear to be making reasonable progress on the requirements and >use cases document. For this reason we are considering dedicating >agenda time at the next virtual interim (June 25th) to preliminary >discussions about the solution proposals for the session id. In >order to facilitate that discussion I would like to encourage folks >to submit any candidate solutions for session id that they wish to >be considered by the WG. > >Cheers, > >Gonzalo > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Wed May 30 13:23:32 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5200121F8627 for ; Wed, 30 May 2012 13:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.249 X-Spam-Level: X-Spam-Status: No, score=-107.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UpBG+PcPKsV for ; Wed, 30 May 2012 13:23:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22621F84CD for ; Wed, 30 May 2012 13:23:31 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4UKNR18028662 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 May 2012 22:23:27 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 30 May 2012 22:23:27 +0200 From: "DRAGE, Keith (Keith)" To: James Polk , "insipid@ietf.org" Date: Wed, 30 May 2012 22:23:26 +0200 Thread-Topic: [Insipid] Session ID solution drafts request Thread-Index: Ac0+nz44YBL/2ZFRQxKxdXcJqkkU+wAAjYKw Message-ID: References: <2FD16C93-CEF9-4D5E-9D2F-F7F455342319@cisco.com> <201205302003.q4UK35am005292@mtv-core-2.cisco.com> In-Reply-To: <201205302003.q4UK35am005292@mtv-core-2.cisco.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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: Gonzalo Salgueiro Subject: Re: [Insipid] Session ID solution drafts request X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 20:23:32 -0000 (As WG cochair) Thanks. This was of course already on our list, although if you want to rev= iew and revise it before potential discussion on 25th you are welcome to do= so. So this was more a prompt to identify other ideas they wanted in the soluti= on space. Regards Keith -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of James Polk Sent: 30 May 2012 21:03 To: insipid@ietf.org Cc: Gonzalo Salgueiro Subject: Re: [Insipid] Session ID solution drafts request There's this ID that some of us proposed as a solution offering draft-jones-insipid-session-id James At 02:31 PM 5/30/2012, Gonzalo Salgueiro wrote: >Folks: > >We appear to be making reasonable progress on the requirements and=20 >use cases document. For this reason we are considering dedicating=20 >agenda time at the next virtual interim (June 25th) to preliminary=20 >discussions about the solution proposals for the session id. In=20 >order to facilitate that discussion I would like to encourage folks=20 >to submit any candidate solutions for session id that they wish to=20 >be considered by the WG. > >Cheers, > >Gonzalo > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From laura.liess.dt@googlemail.com Thu May 31 01:35:47 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACC021F869D for ; Thu, 31 May 2012 01:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbHMnGafi5pv for ; Thu, 31 May 2012 01:35:47 -0700 (PDT) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0E36021F852C for ; Thu, 31 May 2012 01:35:46 -0700 (PDT) Received: by ghbz22 with SMTP id z22so978901ghb.27 for ; Thu, 31 May 2012 01:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oDn/40UhbF0C91K7BGu02A8EYz5tif7LGpo6hI39NUA=; b=lkGcdEtbCOL39p8awgyc65LUC/6Vwk2of2+++7p1Wq5nhHVUewulkkdvvkmEFpUOpb MSFpE56mdkJqSW7geQ6jV77FX5ebBAQxh7+kDTrhg/tXZKqklb10MzNDRekTU9X1s7nu rzIQh7X6IGXk3DCZyao90csrtdXPEIa1uUlhHceiQBf4YIKBunm7QlUA/OQtkE1WZHsZ yrQ41ZVzNCYmndwgk9ZrmnrAco6xBZXNLSo5I20dS/IMXgMNNiVdxsBL8O1WTtTb2u35 6qnom34RQ9PJM3jEVYaPXkxzdeDO5wTmu/Q0A60tVEWsj3ljs7YglDo6PHsrVsB3g87T pNEw== MIME-Version: 1.0 Received: by 10.50.91.233 with SMTP id ch9mr744710igb.8.1338453346195; Thu, 31 May 2012 01:35:46 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Thu, 31 May 2012 01:35:46 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16038963@inba-mail01.sonusnet.com> References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C16038963@inba-mail01.sonusnet.com> Date: Thu, 31 May 2012 10:35:46 +0200 Message-ID: From: Laura Liess To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , "insipid@ietf.org" Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 08:35:48 -0000 Partha, 2012/5/30 Ravindran, Parthasarathi : > > and any form of SIP messages in REQ-6. I think you meant here "any parts of the SIP message (header, body)" . Is this correct or did you thought of something else? If this is what you mean, I am OK with it. Kind regards Laura > > > > REQ-6 is important because it provides confidence to the operator/admin t= hat > session-id is safe to be passed across in SBC/PBX. In case it is possible= to > use any of the existing SIP headers/body, IMO there is no need to new > session-id itself. AFAIK, there is no SIP headers/body exists which quali= fy > for session-id as of now. > > > > Thanks > > Partha > > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Paul E. Jones > Sent: Wednesday, May 30, 2012 1:16 AM > > > To: insipid@ietf.org > Subject: [Insipid] Revised requirements document > > > > Folks, > > > > As requested, I posted a revised version of the INSIPID requirements > document, taking into consideration the discussions from the call today. > Here=92s the text: > > http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01 > > > > Note that Requirement 1a needs to be completed.=A0 I=92d be delighted if = someone > could propose some wording for that. > > > > As discussed on the call, the meaning of requirement 6 was changed quite > substantially in meaning from the -00 draft.=A0 We need to decide exactly= what > meaning we want or introduce a new requirement if we want to both hide > information and also not reveal that an SBC, for example, might have chan= ged > any of that information. > > > > Paul > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From pravindran@sonusnet.com Thu May 31 01:38:50 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B754D21F869D for ; Thu, 31 May 2012 01:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 Fq6vMAW5+pc6 for ; Thu, 31 May 2012 01:38:50 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with ESMTP id C73DF21F852C for ; Thu, 31 May 2012 01:38:49 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKT8cuGY/EnjF2ZTAe/8vIPt6Q6ukGqnvz@postini.com; Thu, 31 May 2012 01:38:49 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 May 2012 04:39:14 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 31 May 2012 14:08:37 +0530 From: "Ravindran, Parthasarathi" To: Laura Liess Thread-Topic: [Insipid] Revised requirements document Thread-Index: Ac090wzWy9p+WCsrQk27dM+DK4ieVQAdt+zgACQWVwAAC5W6gA== Date: Thu, 31 May 2012 08:38:36 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16038C61@inba-mail01.sonusnet.com> References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C16038963@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Paul E. Jones" , "insipid@ietf.org" Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 08:38:50 -0000 Laura, It is good to hear that we are in the same page about REQ-6 that "any parts= of the SIP message (header, body)" Thanks Partha >-----Original Message----- >From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >Sent: Thursday, May 31, 2012 2:06 PM >To: Ravindran, Parthasarathi >Cc: insipid@ietf.org; Paul E. Jones >Subject: Re: [Insipid] Revised requirements document > >Partha, > >2012/5/30 Ravindran, Parthasarathi : > >> >> and any form of SIP messages in REQ-6. > >I think you meant here "any parts of the SIP message (header, body)" . >Is this correct or did you thought of something else? > >If this is what you mean, I am OK with it. > >Kind regards >Laura > >> >> >> >> REQ-6 is important because it provides confidence to the >> operator/admin that session-id is safe to be passed across in SBC/PBX. >> In case it is possible to use any of the existing SIP headers/body, >> IMO there is no need to new session-id itself. AFAIK, there is no SIP >> headers/body exists which qualify for session-id as of now. >> >> >> >> Thanks >> >> Partha >> >> >> >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Paul E. Jones >> Sent: Wednesday, May 30, 2012 1:16 AM >> >> >> To: insipid@ietf.org >> Subject: [Insipid] Revised requirements document >> >> >> >> Folks, >> >> >> >> As requested, I posted a revised version of the INSIPID requirements >> document, taking into consideration the discussions from the call >today. >> Here's the text: >> >> http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01 >> >> >> >> Note that Requirement 1a needs to be completed.=A0 I'd be delighted if >> someone could propose some wording for that. >> >> >> >> As discussed on the call, the meaning of requirement 6 was changed >> quite substantially in meaning from the -00 draft.=A0 We need to decide >> exactly what meaning we want or introduce a new requirement if we want >> to both hide information and also not reveal that an SBC, for example, >> might have changed any of that information. >> >> >> >> Paul >> >> >> >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >> From paulej@packetizer.com Thu May 31 06:49:51 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BDA21F8648 for ; Thu, 31 May 2012 06:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 85d6ilNqxz5Q for ; Thu, 31 May 2012 06:49:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D041121F84B3 for ; Thu, 31 May 2012 06:49:47 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q4VDnkB3014352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 09:49:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1338472187; bh=5pOBcLhVG+s5ToA3fuCUPXah4O4zc6ZFjQOhEsX+D90=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sz9xMWZn0vk/Ed8evB3iT1P9OmQNkDOgu93xzFqsZseF/tDdrlNCIQ3/tnyMi8mpY KeDMsQsH3nLotR0YMR76wZdsdybNRw5mzSnuUA/evQJIO21mr4b2wsxrudPml3jsjG c1wqXQjVQRVSIymWt9jUazzUhBIZy7cB/633UhGc= From: "Paul E. Jones" To: "'Hutton, Andrew'" , References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <9F33F40F6F2CD847824537F3C4E37DDF013969@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013969@MCHP04MSX.global-ad.net> Date: Thu, 31 May 2012 09:49:55 -0400 Message-ID: <04ec01cd3f34$435278a0$c9f769e0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE4U5YzCDejwUHVpKZ/Wgs+HlZqTQKdFm0Yl/jUNkA= Content-Language: en-us Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 13:49:51 -0000 > I think it is important to understand what use cases are within scope of > INSIPID I would like to see the document restructured to describe real use > cases and the derived use cases. I think the RTCWEB use case and > requirements draft is a good example of how such requirements drafts > should look like. See http://tools.ietf.org/html/draft-ietf-rtcweb-use- > cases-and-requirements-07. Agreed, that's a nice format. Input solicited :-) > The current draft currently contains the following use cases to which I > have some comments. > > * End-to-end identification of a communication session > > This is the basic case and as long as we all agree what is meant by a > "Communication Session" then it is ok however I would like to see it > reworded in to the form of a real use case. Can someone provide the text? I'll put it in. > * Association of session signaling and media flows, made possible > by including the session identifier in media-related messages > (e.g., RSVP or RTCP) > > I don't think that this use case is within scope of INSIPID which is > limited to association at the signaling level. Association of media > streams should probably done at the SDP level if needed. We could within > INSIPID try to make sure that any new identifier is in a suitable format > to be carried in other protocols but I don't think we want to specify > procedures for including it in for example RTCP. You're correct, though I still think it is important that we do not use something that does not lend itself to signaling and media correlation. That might be outside the charter, but it ought not be outside our thinking of the problem. If we actually did use this value to correlate signaling and media, it would be in a different draft. So, yes, outside of INSPID. I just don't want to see us do something that would preclude this possibility, though I fully agree it's not a primary objective. > * Identification of devices taking part in the same multipoint > conference > > Should this be "Association of sessions taking part in the same multipoint > conference"? However I think it should be reworked in to a use case. Yes, that would be a better word to use. > * Tracking sessions transferred from one endpoint to another > > Does this need rewording in the form of a use case? I think we will need a > few transfer / redirection use cases to really flesh out the requirements. An expanded use case, as with others, might be useful. > * Facilitate the recording of SIP sessions and correlating those > Sessions > > This is not a use case and does not add any new requirements over the 1st > basic end to end identification case. This came from the SIPREC work. Somebody working in that area might have a say here. > * Logging for the purposes of accounting, billing, debugging, > communication tracking (such as for security purposes in case of > theft of service), etc. > > Again these are not use cases from which specific requirements can be > derived. Requirements can be derived. For example, this requirement might result in the construction of an ID suitable for logging. I'm sure we would have done that, anyway, but there are logging challenges with one solution versus another. For example, in the solution we propose, there Alice and Bob have UUIDs. If Alice wants to log the initial INVITE she sends, it would not be a complete Session-ID, but only her UUID. We need to consider message flows and logging. Paul From gsalguei@cisco.com Thu May 31 08:11:45 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230F521F879B for ; Thu, 31 May 2012 08:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VdMIbi9Uj-D for ; Thu, 31 May 2012 08:11:44 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9A28D21F8735 for ; Thu, 31 May 2012 08:11:44 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4VFBg5V020905 for ; Thu, 31 May 2012 11:11:42 -0400 (EDT) Received: from dhcp-10-150-53-247.cisco.com (dhcp-10-150-53-247.cisco.com [10.150.53.247]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4VFBgKG001801 for ; Thu, 31 May 2012 11:11:42 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 31 May 2012 11:11:41 -0400 Message-Id: <33016F5E-EA39-4236-8DEF-AFCCAAE9AF7D@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Insipid] New milestone added to charter X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:11:45 -0000 Hi, As agreed upon in the INSIPID WG Virtual Interim #1 the chairs asked for = a new milestone to be added to the charter for a separate requirements = and use case document. The milestone request was approved and is now = reflected in the charter = (http://datatracker.ietf.org/wg/insipid/charter/): * Aug 2012 Requirements and use cases for new identifier sent to IESG = (as informational) Cheers, Gonzalo (As WG co-chair) =20= From pravindran@sonusnet.com Thu May 31 08:46:40 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4511E8128 for ; Thu, 31 May 2012 08:46:40 -0700 (PDT) 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 QzCU1wHZKGT2 for ; Thu, 31 May 2012 08:46:40 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 905C411E811C for ; Thu, 31 May 2012 08:46:39 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT8eSXZ7k7B3tKlQ6ddcdOcglLu/RrKTG@postini.com; Thu, 31 May 2012 08:46:39 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 May 2012 11:47:02 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 31 May 2012 21:16:31 +0530 From: "Ravindran, Parthasarathi" To: "Paul E. Jones" , "'Hutton, Andrew'" , "insipid@ietf.org" Thread-Topic: [Insipid] Revised requirements document Thread-Index: Ac090wzWy9p+WCsrQk27dM+DK4ieVQAbUlpgADF0oYAADwyl8A== Date: Thu, 31 May 2012 15:46:30 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16038D73@inba-mail01.sonusnet.com> References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <9F33F40F6F2CD847824537F3C4E37DDF013969@MCHP04MSX.global-ad.net> <04ec01cd3f34$435278a0$c9f769e0$@packetizer.com> In-Reply-To: <04ec01cd3f34$435278a0$c9f769e0$@packetizer.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:46:41 -0000 Andy, >> * Facilitate the recording of SIP sessions and correlating those >> Sessions >> >> This is not a use case and does not add any new requirements over the >> 1st basic end to end identification case. > >This came from the SIPREC work. Somebody working in that area might >have a say here. I have requested to add this usecase as session in INSIPID context shall be= mapped to Communication Session(CS) in terms of SIPREC.=20 =09 Thanks Partha >-----Original Message----- >From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >Behalf Of Paul E. Jones >Sent: Thursday, May 31, 2012 7:20 PM >To: 'Hutton, Andrew'; insipid@ietf.org >Subject: Re: [Insipid] Revised requirements document > >> I think it is important to understand what use cases are within scope >> of INSIPID I would like to see the document restructured to describe >> real use cases and the derived use cases. I think the RTCWEB use case >> and requirements draft is a good example of how such requirements >> drafts should look like. See >> http://tools.ietf.org/html/draft-ietf-rtcweb-use- >> cases-and-requirements-07. > >Agreed, that's a nice format. Input solicited :-) > >> The current draft currently contains the following use cases to which >> I have some comments. >> >> * End-to-end identification of a communication session >> >> This is the basic case and as long as we all agree what is meant by a >> "Communication Session" then it is ok however I would like to see it >> reworded in to the form of a real use case. > >Can someone provide the text? I'll put it in. > >> * Association of session signaling and media flows, made possible >> by including the session identifier in media-related messages >> (e.g., RSVP or RTCP) >> >> I don't think that this use case is within scope of INSIPID which is >> limited to association at the signaling level. Association of media >> streams should probably done at the SDP level if needed. We could >> within INSIPID try to make sure that any new identifier is in a >> suitable format to be carried in other protocols but I don't think we >> want to specify procedures for including it in for example RTCP. > >You're correct, though I still think it is important that we do not use >something that does not lend itself to signaling and media correlation. >That might be outside the charter, but it ought not be outside our >thinking of the problem. If we actually did use this value to correlate >signaling and media, it would be in a different draft. So, yes, outside >of INSPID. I just don't want to see us do something that would preclude >this possibility, though I fully agree it's not a primary objective. > >> * Identification of devices taking part in the same multipoint >> conference >> >> Should this be "Association of sessions taking part in the same >> multipoint conference"? However I think it should be reworked in to a >use case. > >Yes, that would be a better word to use. > >> * Tracking sessions transferred from one endpoint to another >> >> Does this need rewording in the form of a use case? I think we will >> need a few transfer / redirection use cases to really flesh out the >requirements. > >An expanded use case, as with others, might be useful. > >> * Facilitate the recording of SIP sessions and correlating those >> Sessions >> >> This is not a use case and does not add any new requirements over the >> 1st basic end to end identification case. > >This came from the SIPREC work. Somebody working in that area might >have a say here. > >> * Logging for the purposes of accounting, billing, debugging, >> communication tracking (such as for security purposes in case >of >> theft of service), etc. >> >> Again these are not use cases from which specific requirements can be >> derived. > >Requirements can be derived. For example, this requirement might result >in the construction of an ID suitable for logging. I'm sure we would >have done that, anyway, but there are logging challenges with one >solution versus another. For example, in the solution we propose, there >Alice and Bob have UUIDs. If Alice wants to log the initial INVITE she >sends, it would not be a complete Session-ID, but only her UUID. We >need to consider message flows and logging. > >Paul > > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Thu May 31 09:09:03 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE9B11E80C8 for ; Thu, 31 May 2012 09:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.563, 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 FRSrlrpnPfkK for ; Thu, 31 May 2012 09:09:02 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 64C2511E8091 for ; Thu, 31 May 2012 09:09:02 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A18FD1EB8433; Thu, 31 May 2012 18:09:00 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Thu, 31 May 2012 18:09:00 +0200 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] Revised requirements document Thread-Index: Ac090wzWy9p+WCsrQk27dM+DK4ieVQAbUlpgADjKLYAABBJWAAAEh00Q Date: Thu, 31 May 2012 16:08:58 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF015956@MCHP04MSX.global-ad.net> References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <9F33F40F6F2CD847824537F3C4E37DDF013969@MCHP04MSX.global-ad.net> <04ec01cd3f34$435278a0$c9f769e0$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C16038D73@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16038D73@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.249.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:09:03 -0000 Hi Partha, Understood but it needed to be worded as a use case. The use case could be something like this. A SIP Session is established between UA-A and UA-B with a SIP B2BUA acting = as a middlebox. Both UA-A and UA-B establish a recording session with a ses= sion recording server (SRS) using the SIPREC protocol. The SRS needs to be = able to determine from the metadata provided by UA-A and UA-B that the medi= a streams are associated with the same communication session (CS). The assumption is that the SIPREC metadata from both UA-A and UA-B would in= clude the session identifier for the CS. Regards Andy > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 31 May 2012 16:47 > To: Paul E. Jones; Hutton, Andrew; insipid@ietf.org > Subject: RE: [Insipid] Revised requirements document >=20 > Andy, >=20 > > >> * Facilitate the recording of SIP sessions and correlating > those > >> Sessions > >> > >> This is not a use case and does not add any new requirements over > the > >> 1st basic end to end identification case. > > > >This came from the SIPREC work. Somebody working in that area might > >have a say here. > >=20 > I have requested to add this usecase as session in INSIPID context > shall be mapped to Communication Session(CS) in terms of SIPREC. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >Behalf Of Paul E. Jones > >Sent: Thursday, May 31, 2012 7:20 PM > >To: 'Hutton, Andrew'; insipid@ietf.org > >Subject: Re: [Insipid] Revised requirements document > > > >> I think it is important to understand what use cases are within > scope > >> of INSIPID I would like to see the document restructured to describe > >> real use cases and the derived use cases. I think the RTCWEB use > case > >> and requirements draft is a good example of how such requirements > >> drafts should look like. See > >> http://tools.ietf.org/html/draft-ietf-rtcweb-use- > >> cases-and-requirements-07. > > > >Agreed, that's a nice format. Input solicited :-) > > > >> The current draft currently contains the following use cases to > which > >> I have some comments. > >> > >> * End-to-end identification of a communication session > >> > >> This is the basic case and as long as we all agree what is meant by > a > >> "Communication Session" then it is ok however I would like to see it > >> reworded in to the form of a real use case. > > > >Can someone provide the text? I'll put it in. > > > >> * Association of session signaling and media flows, made > possible > >> by including the session identifier in media-related messages > >> (e.g., RSVP or RTCP) > >> > >> I don't think that this use case is within scope of INSIPID which is > >> limited to association at the signaling level. Association of media > >> streams should probably done at the SDP level if needed. We could > >> within INSIPID try to make sure that any new identifier is in a > >> suitable format to be carried in other protocols but I don't think > we > >> want to specify procedures for including it in for example RTCP. > > > >You're correct, though I still think it is important that we do not > use > >something that does not lend itself to signaling and media > correlation. > >That might be outside the charter, but it ought not be outside our > >thinking of the problem. If we actually did use this value to > correlate > >signaling and media, it would be in a different draft. So, yes, > outside > >of INSPID. I just don't want to see us do something that would > preclude > >this possibility, though I fully agree it's not a primary objective. > > > >> * Identification of devices taking part in the same multipoint > >> conference > >> > >> Should this be "Association of sessions taking part in the same > >> multipoint conference"? However I think it should be reworked in to > a > >use case. > > > >Yes, that would be a better word to use. > > > >> * Tracking sessions transferred from one endpoint to another > >> > >> Does this need rewording in the form of a use case? I think we will > >> need a few transfer / redirection use cases to really flesh out the > >requirements. > > > >An expanded use case, as with others, might be useful. > > > >> * Facilitate the recording of SIP sessions and correlating > those > >> Sessions > >> > >> This is not a use case and does not add any new requirements over > the > >> 1st basic end to end identification case. > > > >This came from the SIPREC work. Somebody working in that area might > >have a say here. > > > >> * Logging for the purposes of accounting, billing, debugging, > >> communication tracking (such as for security purposes in case > >of > >> theft of service), etc. > >> > >> Again these are not use cases from which specific requirements can > be > >> derived. > > > >Requirements can be derived. For example, this requirement might > result > >in the construction of an ID suitable for logging. I'm sure we would > >have done that, anyway, but there are logging challenges with one > >solution versus another. For example, in the solution we propose, > there > >Alice and Bob have UUIDs. If Alice wants to log the initial INVITE > she > >sends, it would not be a complete Session-ID, but only her UUID. We > >need to consider message flows and logging. > > > >Paul > > > > > >_______________________________________________ > >insipid mailing list > >insipid@ietf.org > >https://www.ietf.org/mailman/listinfo/insipid From pravindran@sonusnet.com Thu May 31 09:49:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5911E8138 for ; Thu, 31 May 2012 09:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 2sCaooJP8c3U for ; Thu, 31 May 2012 09:49:37 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id E605B11E80F4 for ; Thu, 31 May 2012 09:49:36 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT8ehICclI9EFzGRBTwnjS77Uw9pO6by9@postini.com; Thu, 31 May 2012 09:49:37 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 May 2012 12:50:01 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 31 May 2012 22:19:30 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] Revised requirements document Thread-Index: Ac090wzWy9p+WCsrQk27dM+DK4ieVQAbUlpgADF0oYAADwyl8P//rnQA//+hYrA= Date: Thu, 31 May 2012 16:49:29 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16038DB2@inba-mail01.sonusnet.com> References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <9F33F40F6F2CD847824537F3C4E37DDF013969@MCHP04MSX.global-ad.net> <04ec01cd3f34$435278a0$c9f769e0$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C16038D73@inba-mail01.sonusnet.com> <9F33F40F6F2CD847824537F3C4E37DDF015956@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF015956@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:49:38 -0000 Hi Andy, Your below mentioned usecase is one of the usecase related to SIPREC. Anoth= er two SIPREC usecase comes to my mind immediately are 1) B2BUA+SRC could include session-identifier in the SIPREC metadata which = helps SRS to retrieve non-SIPREC(Call Centre specific) metadata. Even thoug= h this usecase is complicated, I'm seeing most of the deployment depends up= on the proprietary IP PBX vendor's session-id to make this happen as of now= . 2) SRS could send session-identifier as part of SRS-initiated session where= in SRC shall start recording the corresponding (communication) session. Yo= ur SIPREC mail (http://www.ietf.org/mail-archive/web/siprec/current/msg0319= 2.html) :-) As long as session-id meets one of the SIPREC usecase, it shall be used in = other use cases as well. So, I agree with your wordings. Thanks Partha >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Thursday, May 31, 2012 9:39 PM >To: Ravindran, Parthasarathi; Paul E. Jones; insipid@ietf.org >Subject: RE: [Insipid] Revised requirements document > >Hi Partha, > >Understood but it needed to be worded as a use case. > >The use case could be something like this. > >A SIP Session is established between UA-A and UA-B with a SIP B2BUA >acting as a middlebox. Both UA-A and UA-B establish a recording session >with a session recording server (SRS) using the SIPREC protocol. The SRS >needs to be able to determine from the metadata provided by UA-A and UA- >B that the media streams are associated with the same communication >session (CS). > >The assumption is that the SIPREC metadata from both UA-A and UA-B would >include the session identifier for the CS. > >Regards >Andy > > > > > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 31 May 2012 16:47 >> To: Paul E. Jones; Hutton, Andrew; insipid@ietf.org >> Subject: RE: [Insipid] Revised requirements document >> >> Andy, >> >> >> >> * Facilitate the recording of SIP sessions and correlating >> those >> >> Sessions >> >> >> >> This is not a use case and does not add any new requirements over >> the >> >> 1st basic end to end identification case. >> > >> >This came from the SIPREC work. Somebody working in that area might >> >have a say here. >> >> >> I have requested to add this usecase as session in INSIPID context >> shall be mapped to Communication Session(CS) in terms of SIPREC. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> >Behalf Of Paul E. Jones >> >Sent: Thursday, May 31, 2012 7:20 PM >> >To: 'Hutton, Andrew'; insipid@ietf.org >> >Subject: Re: [Insipid] Revised requirements document >> > >> >> I think it is important to understand what use cases are within >> scope >> >> of INSIPID I would like to see the document restructured to >> >> describe real use cases and the derived use cases. I think the >> >> RTCWEB use >> case >> >> and requirements draft is a good example of how such requirements >> >> drafts should look like. See >> >> http://tools.ietf.org/html/draft-ietf-rtcweb-use- >> >> cases-and-requirements-07. >> > >> >Agreed, that's a nice format. Input solicited :-) >> > >> >> The current draft currently contains the following use cases to >> which >> >> I have some comments. >> >> >> >> * End-to-end identification of a communication session >> >> >> >> This is the basic case and as long as we all agree what is meant by >> a >> >> "Communication Session" then it is ok however I would like to see >> >> it reworded in to the form of a real use case. >> > >> >Can someone provide the text? I'll put it in. >> > >> >> * Association of session signaling and media flows, made >> possible >> >> by including the session identifier in media-related >messages >> >> (e.g., RSVP or RTCP) >> >> >> >> I don't think that this use case is within scope of INSIPID which >> >> is limited to association at the signaling level. Association of >> >> media streams should probably done at the SDP level if needed. We >> >> could within INSIPID try to make sure that any new identifier is in >> >> a suitable format to be carried in other protocols but I don't >> >> think >> we >> >> want to specify procedures for including it in for example RTCP. >> > >> >You're correct, though I still think it is important that we do not >> use >> >something that does not lend itself to signaling and media >> correlation. >> >That might be outside the charter, but it ought not be outside our >> >thinking of the problem. If we actually did use this value to >> correlate >> >signaling and media, it would be in a different draft. So, yes, >> outside >> >of INSPID. I just don't want to see us do something that would >> preclude >> >this possibility, though I fully agree it's not a primary objective. >> > >> >> * Identification of devices taking part in the same multipoint >> >> conference >> >> >> >> Should this be "Association of sessions taking part in the same >> >> multipoint conference"? However I think it should be reworked in to >> a >> >use case. >> > >> >Yes, that would be a better word to use. >> > >> >> * Tracking sessions transferred from one endpoint to another >> >> >> >> Does this need rewording in the form of a use case? I think we will >> >> need a few transfer / redirection use cases to really flesh out the >> >requirements. >> > >> >An expanded use case, as with others, might be useful. >> > >> >> * Facilitate the recording of SIP sessions and correlating >> those >> >> Sessions >> >> >> >> This is not a use case and does not add any new requirements over >> the >> >> 1st basic end to end identification case. >> > >> >This came from the SIPREC work. Somebody working in that area might >> >have a say here. >> > >> >> * Logging for the purposes of accounting, billing, debugging, >> >> communication tracking (such as for security purposes in >> >> case >> >of >> >> theft of service), etc. >> >> >> >> Again these are not use cases from which specific requirements can >> be >> >> derived. >> > >> >Requirements can be derived. For example, this requirement might >> result >> >in the construction of an ID suitable for logging. I'm sure we would >> >have done that, anyway, but there are logging challenges with one >> >solution versus another. For example, in the solution we propose, >> there >> >Alice and Bob have UUIDs. If Alice wants to log the initial INVITE >> she >> >sends, it would not be a complete Session-ID, but only her UUID. We >> >need to consider message flows and logging. >> > >> >Paul >> > >> > >> >_______________________________________________ >> >insipid mailing list >> >insipid@ietf.org >> >https://www.ietf.org/mailman/listinfo/insipid