From christer.holmberg@ericsson.com Tue Jun 1 02:37:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17223A695E for ; Tue, 1 Jun 2010 02:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-2.818, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jeFZEpWIsCR for ; Tue, 1 Jun 2010 02:37:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E23C63A6972 for ; Tue, 1 Jun 2010 02:37:28 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-16-4c04d4cb3553 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 72.14.06817.BC4D40C4; Tue, 1 Jun 2010 11:37:15 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 1 Jun 2010 11:37:13 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 1 Jun 2010 11:37:13 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 1 Jun 2010 11:37:12 +0200 Thread-Topic: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer Thread-Index: AcsBLa4KrfF9i7FpTVuYoU3JfIE8aQAP97fg Message-ID: References: <4C02D9E0.5060306@cisco.com> <4C0468CF.4010006@cisco.com> In-Reply-To: <4C0468CF.4010006@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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" , Harbhanu Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 09:37:32 -0000 DQpIaSwgDQoNCj4+PkkgYWdyZWUgdGhhdCB0aGVyZSBhcmUgaXNzdWVzIHdpdGggc2Vzc2lvbi10 aW1lci4NCj4+Pg0KPj4+Tm9ybWFsbHkgc2Vzc2lvbi10aW1lciBpcyBzaW1wbGUsIGJlY2F1c2Ug aXQgaXMgbmVnb3RpYXRlZCBhbmV3IHdpdGggDQo+Pj5lYWNoIGV4Y2hhbmdlLiBUaGF0IHdvcmtz IHJlYXNvbmFibHkgd2VsbCBmb3IgcmVJTlZJVEUgYW5kIGZvciBVUERBVEUgDQo+Pj5vdXRzaWRl IG9mIGFuIGludml0ZSB0cmFuc2FjdGlvbi4gSXRzIGEgbWVzcyBpZiBhbiBVUERBVEUgd2l0aGlu IGEgDQo+Pj4ocmUpSU5WSVRFIHRyYW5zYWN0aW9uIG5lZ290aWF0ZXMgUy1ULiBJIHRoaW5rIHRo YXQgbmVlZHMgdG8gYmUgDQo+Pj5mb3JiaWRkZW4sIHdoaWNoIHdpbGwgYmUgYSByZXZpc2lvbiB0 byA0MDI4Lg0KPj4gDQo+PlRoYXQgY291bGQgYmUgYWRkZWQgdG8gbXkgIk5FVyBERUFMIiBsaXN0 IG9mIHRoaW5ncyB3aGljaCBzaG91bGRuJ3QgYmUgDQo+PmRvbmUgd2l0aGluIGEgcmUtSU5WSVRF IDopDQo+PiANCj4+ICANCj4+PihBIHJlSU5WSVRFIHNob3VsZCBub3QgdGFrZSBzbyBsb25nIHRo YXQgYSBzZXNzaW9uLXRpbWVyIHdpbGwgZXhwaXJlIA0KPj4+YmVmb3JlIGl0IGlzIGNvbXBsZXRl LiBQZXJoYXBzIGl0IHNob3VsZCBiZSBzcGVjaWZpZWQgdGhhdCAqaWYqIGEgDQo+Pj5zZXNzaW9u LXRpbWVyIGRvZXMgZXhwaXJlIHdoaWxlIGEgcmVJTlZJVEUgaXMgaW4gcHJvZ3Jlc3MsIHRoYXQg DQo+Pj5leHBpcmF0aW9uIGlzIGlnbm9yZWQuKQ0KPj4gDQo+PkkgZG9uJ3QgdGhpbmsgb25lIHNo b3VsZCB0cnkgdG8gZG8gdG9vIG1hbnkgdGhpbmdzIHdpdGggYSBzaW5nbGUgcmUtSU5WSVRFIChv ciBVUERBVEUpIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4+IA0KPj5JZiB5b3UgYXJlIGdvaW5nIHRv IHBlcmZvcm0gYSByZS1JTlZJVEUsIHdoaWNoIG1heSB0YWtlIHNvbWUgdGltZSB0byBmaW5pc2gs IGRvIHlvdSBTLVQgcmVmcmVzaCAqYmVmb3JlKiB0aGF0LCBpbiBhIA0KPj5zZXBhcmF0ZSB0cmFu c2FjdGlvbi4NCj4gDQo+QnkgY3VycmVudCBkZWZpbml0aW9uLCB5b3UgY2FuJ3QgZG8gdGhpcy4g RXZlcnkgcmVpbnZpdGUgYW5kIA0KPmV2ZXJ5IHVwZGF0ZSByZW5lZ290aWF0ZXMgdGhlIHNlc3Np b24gdGltZXIgLSBlaXRoZXIgYSBuZXcgDQo+dGltZXIgdmFsdWUgb3IgZWxzZSAgdGhlIGFic2Vu Y2Ugb2YgYSBzZXNzaW9uIHRpbWVyLiBTbyBpZiANCj55b3Ugd2FudCB0byBrZWVwIHlvdXIgc2Vz c2lvbiB0aW1lciBnb2luZyB5b3UgbXVzdCByZXNwZWNpZnkgDQo+aXQgb24gZWFjaCByZWludml0 ZS4NCg0KWWVzLg0KDQpCdXQsIGlmIHlvdSBmaXJzdCBwZXJmb3JtIHRoZSBzZXNzaW9uIHRpbWVy IHJlZnJlc2gsIHRoZW4gSSBndWVzcyB0aGUgY2hhbmNlIG9mIHRpbWVyIGV4cGlyeSBpcyByYXRo ZXIgc21hbGwsIGV2ZW4gaWYgaXQgdGFrZXMgYSB3aGlsZSBmb3IgdGhlIHN1YnNlcXVlbnQgcmUt SU5WSVRFIHRvIGZpbmlzaC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCj5JdCB3aWxs IHJlcXVpcmUgYSBub3JtYXRpdmUgY2hhbmdlIHRvIGFsdGVyIHRoaXMuDQo+IA0KPlRoZSBub3Jt YXRpdmUgY2hhbmdlIEkgYWR2b2NhdGUgaXMgc2ltcGx5IHRoZSBvbmUgdGhhdCBzYXlzIA0KPmFu IHVwZGF0ZSB3aXRoaW4gYSByZWludml0ZSB0cmFuc2FjdGlvbiBkb2VzIG5vdCBhZmZlY3QgdGhl IA0KPnNlc3Npb24gdGltZXIuIFRoaXMgaG93ZXZlciBzdGlsbCBoYXMgaXNzdWVzIHdoZW4gdGhl cmUgaXMgDQo+YW1iaWd1aXR5IGFzIHRvIHdoZXRoZXIgdGhlIHVwZGF0ZSBpcyB3aXRoaW4gdGhl IHJlaW52aXRlIG9yIG5vdC4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPiA+IFJlZ2Fy ZHMsDQo+ID4gDQo+ID4gQ2hyaXN0ZXINCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4g PiANCj4gPj4gZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4+PiBIaSwNCj4gPj4+DQo+ ID4+PiBOb3QgbGlrZSBPL0EgdXNhZ2UgYW5kIHRhcmdldCByZWZyZXNoIHVzYWdlLCB0aGVyZSdz IG5vIGV4cGxpY2l0IA0KPiA+Pj4gZGVmaW5pdGlvbiBvZiBhbGxvd2luZyBzdWJzZXF1ZW50IHNl c3Npb24gcmVmcmVzaCByZXF1ZXN0DQo+ID4+IGluIGVtYmVkZGVkDQo+ID4+PiByZXF1ZXN0cyhz dWNoIGFzIFVQREFURSBkdXJpbmcgcGVuZGluZyBSZS1JTlZJVEUpLiBTbywgSQ0KPiA+PiB0aGlu ayBpdCBpcw0KPiA+Pj4gbm90IHJlY29tbWVuZGVkIHRvIHNlbmRpbmcgVVBEQVRFIGFzIHN1YnNl cXVlbnQgc2Vzc2lvbiByZWZyZXNoIA0KPiA+Pj4gcmVxdWVzdCBpbiBwZW5kaW5nIElOVklURS9S ZS1JTlZJVEUuDQo+ID4+Pg0KPiA+Pj4gSSdkIGxpa2UgdG8gdGFsayBtb3JlIGFib3V0IHNlc3Np b24gdGltZXIuIElmIHBlb3BsZSB3YW50IA0KPiB0byBkbyB0aGUgDQo+ID4+PiBzZW1hbnRpY3Mg ZXh0ZW5zaW9uIGZvciBzZXNzaW9uIHRpbWVyJ3MgdG8gYWxsb3cgZW1iZWRkZWQgDQo+ID4+PiBy ZXF1ZXN0cyhzdWNoIGFzIFVQREFURSBkdXJpbmcgcGVuZGluZyBSZS1JTlZJVEUpLCB0aGVyZSdz IG9uZSANCj4gPj4+IHN1Z2dlc3Rpb24gd2F5KElORk9STUFUSVZFIGF0IGFsbCk6DQo+ID4+Pg0K PiA+Pj4gRG8gaXQgbGlrZSB0YXJnZXQgcmVmcmVzaCwgdGhlbiB0aGUgMnh4IG9mDQo+ID4+IElO VklURS9SZS1JTlZJVEUncyBTRSB2YWx1ZQ0KPiA+Pj4gc2hvdWxkIGJlIGFzIHRoZSBTRSB2YWx1 ZSBpbiB0aGUgbGFzdCBlbWJlZGRlZCBzdWJzZXF1ZW50IHNlc3Npb24gDQo+ID4+PiByZWZyZXNo IHJlcXVlc3QncyAyeHguDQo+ID4+Pg0KPiA+Pj4gVGhlbiwgdGhlIGdsYXJlIGhhbmRsaW5nIGZv ciBzdWNoIHVzYWdlIHdvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZSANCj4gPj4+IFRhcmdldCBSZWZy ZXNoIHBhcnQgaW4gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLg0KPiA+Pj4NCj4gPj4+IFRo YW5rcywNCj4gPj4+DQo+ID4+PiBHYW8NCj4gPj4+DQo+ID4+PiA9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPiA+Pj4gWmlwICAgIDogMjEwMDEyDQo+ID4+PiBUZWwgICAgOiA4 NzIxMQ0KPiA+Pj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4gPj4+IGVfbWFpbCA6IGdh by55YW5nMkB6dGUuY29tLmNuDQo+ID4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAqSGFyYmhhbnUgPGhhcmJoYW51QGh1YXdlaS5jb20+ Kg0KPiA+Pj4gt6K8/sjLOiAgc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQo+ID4+Pg0KPiA+Pj4g MjAxMC0wNS0yNCAxMzo0MA0KPiA+Pj4NCj4gPj4+IAkNCj4gPj4+IMrVvP7Iyw0KPiA+Pj4gCXNp cGNvcmVAaWV0Zi5vcmcNCj4gPj4+ILOty80NCj4gPj4+IAkNCj4gPj4+INb3zOINCj4gPj4+IAlb c2lwY29yZV0gUkVnLiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQNCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4gCQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgDQo+ ID4+PiAxLiBVRTEgLS0tIElOVklURSBTRS0xODAwIKikIFVFMg0KPiA+Pj4gMi4gVUUxIDwtLS0g MTgzIC0tLS0tLS0tLS0tLS0tLS0tLSBVRTINCj4gPj4+ICANCj4gPj4+IDMuIFVFMSAtLS0gVVBE QVRFIFNFLTYwMCCopCBVRTINCj4gPj4+IDQuIFVFMSA8LS0tIDIwMCBVUERBVEUgLVNFNjAwIC0t IFVFMg0KPiA+Pj4gIA0KPiA+Pj4gNS4gVUUxIDwtLS0gMjAwIElOVklURSBTRS0xODAwIC0tIFVF Mg0KPiA+Pj4gIA0KPiA+Pj4gUGxlYXNlIHJlZmVyIHRoZSBzY2VuYXJpbyBhYm92ZSBmb3IgaGFu ZGxpbmcgb2YNCj4gPj4gU2Vzc2lvbi1UaW1lciwgKDQwMjgpLg0KPiA+Pj4gQXMgcGVyIHRoZSBE cmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQgc2VjdGlvbiA0LjU6DQo+ID4+PiChsCAgV2hl biBjaGVja2luZyBmb3IgZ2xhcmUgc2l0dWF0aW9ucywgVUFzIE1VU1QgdHJlYXQgZXZlcnkgVVBE QVRFDQo+ID4+PiAgICByZXF1ZXN0IGFzIGlmIGl0IGNvbnRhaW5lZCBhbiBvZmZlci4gIEFkZGl0 aW9uYWxseSwgVUFzDQo+ID4+IE1VU1QgdHJlYXQNCj4gPj4+ICAgIHRoZSBleGNoYW5nZSBvZiBh IDJ4eCByZXNwb25zZSB0byBhbiBJTlZJVEUgcmVxdWVzdCBhbmQgaXRzDQo+ID4+PiAgICBjb3Jy ZXNwb25kaW5nIEFDSyByZXF1ZXN0IGFzIGFuIG9mZmVyL2Fuc3dlciBleGNoYW5nZS4gIA0KPiA+ PiBDb25zZXF1ZW50bHksDQo+ID4+PiAgICB0aGUgcnVsZXMgcmVnYXJkaW5nIGdsYXJlIHNpdHVh dGlvbnMgYXBwbGljYWJsZSB0byBvZmZlci9hbnN3ZXINCj4gPj4+ICAgIGV4Y2hhbmdlcyBhcmUg YWxzbyBhcHBsaWNhYmxlIHRvIHRob3NlIGV4Y2hhbmdlcy6hsQ0KPiA+Pj4gIA0KPiA+Pj4gSGVy ZSwgd2UgYXJlIG5vdCBhYmxlIHRvIGNvbmNsdWRlIHdoZXRoZXIgYm90aCBVQXMgc2hvdWxkDQo+ ID4+IHJ1biBzZXNzaW9uDQo+ID4+PiB0aW1lciB3aXRoIDE4MDAgb3IgNjAwLCBvciBvdGhlcndp c2Ugd2hldGhlciB0aGUgVVBEQVRFIHNob3VsZCBiZSANCj4gPj4+IHJlamVjdGVkLg0KPiA+Pj4g IA0KPiA+Pj4gQXMgcGVyIG15IHVuZGVyc3RhbmRpbmcgdGhpcyBkcmFmdCBkb2VzbqGvdCAqKmV4 cGxpY2l0bHkqKiBtZW50aW9uIA0KPiA+Pj4gYW55dGhpbmcgYWJvdXQgdGhlIFNlc3Npb24tVGlt ZXIsIHdoZXJlaW4gdGhlcmUgaXMgYW4gZWFybHkNCj4gPj4gbmVnb3RpYXRpb24uDQo+ID4+PiBT aW5jZSA0MDI4IGFsc28gZG9lc26hr3QNCj4gPj4+IGhhdmUgYW55IHJlZmVyZW5jZSBmb3IgZWFy bHkgbmVnb3RpYXRpb24sIHNvIHdlIHN1Z2dlc3QgDQo+IHRoYXQgaXQgY2FuIA0KPiA+Pj4gYmV0 dGVyIGJlIGluY29ycG9yYXRlZCBpbiB0aGUgYWJvdmUgbWVudGlvbmVkIA0KPiA+Pj4gZHJhZnRb aWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0XS4NCj4gPj4+ICANCj4gPj4+IFBsZWFzZSBzaGFyZSB5 b3VyIG9waW5pb24gYW5kIGRvIGd1aWRlIHVzIGluY2FzZSBhbnkgb2YgdGhlDQo+ID4+IGV4aXN0 aW5nDQo+ID4+PiBSRkMvYWN0aXZlLWRyYWZ0IGFscmVhZHkgY2FwdHVyZXMgdGhpcy4NCj4gPj4+ ICANCj4gPj4+IFRoYW5rcyENCj4gPj4+ICANCj4gPj4+IFJlZ2FyZHMsDQo+ID4+PiBIYXJiaGFu dQ0KPiA+Pj4gIA0KPiA+Pj4NCj4gPj4gDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+PiAqDQo+ID4+PiAq KioqKioqKioqKioqKioqKiBUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiANCj4g Y29uZmlkZW50aWFsIA0KPiA+Pj4gaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGlu dGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgDQo+ID4+PiBlbnRpdHkgd2hvc2UgYWRkcmVz cyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIA0KPiA+Pj4gY29u dGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywN Cj4gPj4gdG90YWwgb3INCj4gPj4+IHBhcnRpYWwgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBv ciBkaXNzZW1pbmF0aW9uKSBieQ0KPiA+PiBwZXJzb25zIG90aGVyDQo+ID4+PiB0aGFuIHRoZSBp bnRlbmRlZA0KPiA+Pj4gcmVjaXBpZW50J3MpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZl IHRoaXMgZS1tYWlsIGluIGVycm9yLCANCj4gPj4+IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBi eSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQNCj4gPj4gZGVsZXRlIGl0IQ0KPiA+Pj4g IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBz aXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4+PiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkDQo+ID4+IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhl IHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gDQo+ID4+IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlz IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCANCj4gYWJvdmUgYXJlIA0KPiA+PiBvYmxp Z2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gDQo+IGRp c2Nsb3NlIHRoZSANCj4gPj4gY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NCj4gPj4+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFy ZQ0KPiA+PiBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciANCj4gPj4gZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCANCj4gdGhpcyBlbWFpbCBpbiANCj4gPj4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIA0KPiA+ PiBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQo+ID4+PiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUNCj4gPj4gQW50aS1TcGFtIHN5c3RlbS4NCj4gPj4+DQo+ID4+Pg0KPiA+ PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4+IC0tDQo+ID4+Pg0KPiA+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IHNpcGNvcmUg bWFpbGluZyBsaXN0DQo+ID4+PiBzaXBjb3JlQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gc2lwY29yZSBtYWlsaW5nIGxpc3QN Cj4gPj4gc2lwY29yZUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmUNCj4g From brett@broadsoft.com Tue Jun 1 05:19:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6651628C2EA for ; Tue, 1 Jun 2010 05:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[AWL=-1.308, BAYES_50=0.001, FRT_SLUT=2.522] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GiplnC8z4EH for ; Tue, 1 Jun 2010 05:19:57 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id B4A7028C202 for ; Tue, 1 Jun 2010 05:17:58 -0700 (PDT) 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; Tue, 1 Jun 2010 05:17:44 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Date: Tue, 1 Jun 2010 05:16:37 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr9PBcaJzm+EIrNQJeTYgrDwarlawERoElg Message-ID: <747A6506A991724FB09B129B79D5FEB614938EEC93@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481797BB1@EXMBXCLUS01.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 12:19:58 -0000 > > How can you only apply "checking for glare situations" during > > a glare situation? > >=20 > > Checking for offer/answer glare is part of normal RFC3311=20 > > UPDATE processing. > > Making two analyzers in series as:=20 >=20 > ---> analyzer1 -----> analyzer2 ---->=20 >=20 > analyzer1 using the rules in RFC3311, and if there's glares case=20 > under it's rule, send 491 or (500+retry) directly;=20 > analyzer2 using the rules in the draft.=20 >=20 > analyzer2 also has two process:=20 > 1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE.=20 > If it can do so, pass the UPDATE to the next step normally;=20 > 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE)=20 > as if it contains Offer and using O/A rules to reject.=20 > > The effected cases/siutation is only these cases/situation which=20 > are ambiguous before the draft.=20 If this is how the changes mandated by sections 3.5 (last paragraph) and 4.= 5 are to be interpreted, I recommend that the draft be updated to clarify t= he rules. From brett@broadsoft.com Tue Jun 1 05:56:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC543A69E2 for ; Tue, 1 Jun 2010 05:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1hV4wLBit1k for ; Tue, 1 Jun 2010 05:56:28 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 1BA7C3A6883 for ; Tue, 1 Jun 2010 05:56:28 -0700 (PDT) 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; Tue, 1 Jun 2010 05:56:15 -0700 From: Brett Tate To: Paul Kyzivat , "sipcore@ietf.org" Date: Tue, 1 Jun 2010 05:55:12 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: AcsAPqnFFjMH6nVCRKy6X18ybUw9vwBSCuPg Message-ID: <747A6506A991724FB09B129B79D5FEB614938EECC2@EXMBXCLUS01.citservers.local> References: <4C02D7D1.70400@cisco.com> In-Reply-To: <4C02D7D1.70400@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: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 12:56:28 -0000 > In light of all the discussion this has generated,=20 > I think -reinvite- is not sufficiently clear on what it=20 > means. I think we need to be looking for a way to revise=20 > it to be more clear, regardless of its current post-WGLC=20 > status. (Note that -offeranswer- is also in post-WGLC=20 > status, and we are debating changes to it.) I agree. From gao.yang2@zte.com.cn Tue Jun 1 18:40:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB12A3A67D2 for ; Tue, 1 Jun 2010 18:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.477 X-Spam-Level: X-Spam-Status: No, score=-97.477 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_40=-0.185, FRT_SLUT=2.522, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv4DwCh66x14 for ; Tue, 1 Jun 2010 18:40:57 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 95E433A68BA for ; Tue, 1 Jun 2010 18:40:56 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Wed, 2 Jun 2010 09:34:45 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3612446977; Wed, 2 Jun 2010 09:40:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o521eMIx099413; Wed, 2 Jun 2010 09:40:22 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614938EEC93@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 2 Jun 2010 09:37:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-02 09:40:21, Serialize complete at 2010-06-02 09:40:21 Content-Type: multipart/alternative; boundary="=_alternative 000923ED48257736_=" X-MAIL: mse2.zte.com.cn o521eMIx099413 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 01:40:58 -0000 This is a multipart message in MIME format. --=_alternative 000923ED48257736_= Content-Type: text/plain; charset="US-ASCII" > > Making two analyzers in series as: > > > > ---> analyzer1 -----> analyzer2 ----> > > > > analyzer1 using the rules in RFC3311, and if there's glares case > > under it's rule, send 491 or (500+retry) directly; > > analyzer2 using the rules in the draft. > > > > analyzer2 also has two process: > > 1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. > > If it can do so, pass the UPDATE to the next step normally; > > 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) > > as if it contains Offer and using O/A rules to reject. > > > > The effected cases/siutation is only these cases/situation which > > are ambiguous before the draft. > > If this is how the changes mandated by sections 3.5 (last paragraph) > and 4.5 are to be interpreted, I recommend that the draft be updated > to clarify the rules. I'd like to confrim do you think it is OK by *my understanding* technically? And if *my understanding* is the same as Gonzalo's, I think we can do the revision about it. But I'd like to point out that the *analyzers* is BCP level thing, so we *may* use the same protocol semantics replace. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000923ED48257736_= Content-Type: text/html; charset="US-ASCII"

> > Making two analyzers in series as:
> >
> >  ---> analyzer1 -----> analyzer2 ---->
> >
> > analyzer1 using the rules in RFC3311, and if there's glares case
> > under it's rule, send 491 or (500+retry) directly;
> > analyzer2 using the rules in the draft.
> >
> > analyzer2 also has two process:
> > 1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE.
> > If it can do so, pass the UPDATE to the next step normally;
> > 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE)
> > as if it contains Offer and using O/A rules to reject.
> >
> > The effected cases/siutation is only these cases/situation which
> > are ambiguous before the draft.
>
> If this is how the changes mandated by sections 3.5 (last paragraph)
> and 4.5 are to be interpreted, I recommend that the draft be updated
> to clarify the rules.
I'd like to confrim do you think it is OK by *my understanding* technically?

And if *my understanding* is the same as Gonzalo's, I think we can do the revision about it. But I'd like to point out that the *analyzers* is BCP level thing, so we *may* use the same protocol semantics replace.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000923ED48257736_=-- From gao.yang2@zte.com.cn Tue Jun 1 18:47:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B54B3A6894 for ; Tue, 1 Jun 2010 18:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.601 X-Spam-Level: X-Spam-Status: No, score=-99.601 tagged_above=-999 required=5 tests=[AWL=1.637, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwM8Ge-wobAe for ; Tue, 1 Jun 2010 18:47:03 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C10E03A685A for ; Tue, 1 Jun 2010 18:47:02 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Wed, 2 Jun 2010 09:41:01 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.6396279943; Wed, 2 Jun 2010 09:46:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o521k9Ef008418; Wed, 2 Jun 2010 09:46:09 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: "sipcore@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 2 Jun 2010 09:43:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-02 09:46:08, Serialize complete at 2010-06-02 09:46:08 Content-Type: multipart/alternative; boundary="=_alternative 0009ABD448257736_=" X-MAIL: mse2.zte.com.cn o521k9Ef008418 Subject: [sipcore] draft-ietf-sipcore-reinvite-04: //more about [Discussion 2] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 01:47:04 -0000 This is a multipart message in MIME format. --=_alternative 0009ABD448257736_= Content-Type: text/plain; charset="US-ASCII" I'd like to say more about my [Discussion 2]. As I said in one previous mail, request needing authentication can be reject by 4xx, and the modification in the request would not been enforced. So, I think we *might* get back the atomicity semantic for all usage(*negotiated* and *non-negotiated-declare*) for Re-INVITE. The key for it is clarification the commitment occasion for all the usage(*we may do the clarification for the two class*). Current usage is clear for this commitment occasion: O/A with out precondition: the real Answer; // the same as current draft. O/A with preconditoin: the occasion UAS start to use the modified media. // the same as current draft. Target Refresh: the first reliable response or one request send to the new target(such as a Re-INVITE-in-scope UPDATE). //the same as current darft. the difference here is that as my [Discussion 2], if UA confirmed the new target, UAS should always send 2xx to the Re-INVITE. PAI: I guess it is the same as Target Refresh //current draft doesn't cover this. Session Timer: I am not sure will we add this topic to this draft. I once talked this in: http://www.ietf.org/mail-archive/web/sipcore/current/msg02723.html And I think the comitment occasion is equal to the *in use* semantics mentioned in current text. It seems thing would be clear by this track. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0009ABD448257736_= Content-Type: text/html; charset="US-ASCII"
I'd like to say more about my [Discussion 2].

As I said in one previous mail, request needing authentication can be reject by 4xx, and the modification in the request would not been enforced.

So, I think we *might* get back the atomicity semantic for all usage(*negotiated* and *non-negotiated-declare*) for Re-INVITE.

The key for it is clarification the commitment occasion for all the usage(*we may do the clarification for the two class*). Current usage is clear for this commitment occasion:

O/A with out precondition: the real Answer; // the same as current draft.

O/A with preconditoin: the occasion UAS start to use the modified media.  // the same as current draft.

Target Refresh: the first reliable response or one request send to the new target(such as a Re-INVITE-in-scope UPDATE).  //the same as current darft. the difference here is that as my [Discussion 2], if UA confirmed the new target, UAS should always send 2xx to the Re-INVITE.

PAI: I guess it is the same as Target Refresh  //current draft doesn't cover this.

Session Timer: I am not sure will we add this topic to this draft. I once talked this in:
http://www.ietf.org/mail-archive/web/sipcore/current/msg02723.html

And I think the comitment occasion is equal to the *in use* semantics mentioned in current text.

It seems thing would be clear by this track.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0009ABD448257736_=-- From brett@broadsoft.com Wed Jun 2 05:38:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51C928C1A8 for ; Wed, 2 Jun 2010 05:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+BXSq-9bE2D for ; Wed, 2 Jun 2010 05:38:24 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id B100028C168 for ; Wed, 2 Jun 2010 05:38:06 -0700 (PDT) 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; Wed, 2 Jun 2010 05:37:52 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" Date: Wed, 2 Jun 2010 05:36:45 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: AcsB9Kn3s+4j/iYDQbWJWTHDyF74pgAVKQow Message-ID: <747A6506A991724FB09B129B79D5FEB614938EF4B0@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614938EEC93@EXMBXCLUS01.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 12:38:28 -0000 > I'd like to confirm do you think it is OK by *my understanding*=20 > technically?=20 It would satisfy my concerns about UPDATE without SDP being restricted by t= he current offer/answer state on an early dialog. =20 Otherwise I currently don't have a strong opinion on the topic. Because th= ere are so many race conditions within SIP and the working group likes the = current flexibility leading to the issues, I doubt that the working group w= ould approve a complete mandatory fix. Thus it is mostly just picking whic= h glare/race conditions the working group wants closed so the fix isn't con= sidered worse than the problem. From shinji.okumura@softfront.jp Wed Jun 2 21:57:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684903A67B2 for ; Wed, 2 Jun 2010 21:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.967 X-Spam-Level: X-Spam-Status: No, score=-94.967 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3JI0km5via0 for ; Wed, 2 Jun 2010 21:57:55 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id ABD013A677C for ; Wed, 2 Jun 2010 21:57:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 17069428018 for ; Thu, 3 Jun 2010 13:57:42 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmEQ+ujb7pSD for ; Thu, 3 Jun 2010 13:57:40 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id EC141428016 for ; Thu, 3 Jun 2010 13:57:39 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Thu, 03 Jun 2010 13:57:39 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) Message-Id: Subject: [sipcore] draft-ietf-sipcore-reinvite-04: precondition X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 04:57:56 -0000 Hi all, I have some questions about a behavior of UAs using a precondition. Q1. Does the new behavior of a UAC have nothing to do with a precondition? Q2. If a UAC receives a 4xx to reINVITE before the preconditons have been met, does the UAC send a new offer to synchronize both views? Q3. In 3.3. UAS Behavior "Therefore, it is RECOMMENDED that when a UAS decides to start using the new parameters for a stream for which all mandatory preconditions have been met, the UAS either sends media using the new parameters or sends a new offer where the precondition-related attributes for the stream have been removed. As indicated above, the successful completion of an offer/answer exchange without preconditions indicates that the new parameters for the media stream are already considered to be in use." After preconditions have been met, precondition-related attributes in a SDP are unnecessary? Does the UAC misunderstand that the preconditions have became unnecessary? Regards, Shinji From gao.yang2@zte.com.cn Wed Jun 2 22:14:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF7C3A69A3 for ; Wed, 2 Jun 2010 22:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.292 X-Spam-Level: X-Spam-Status: No, score=-98.292 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhzPDsR1o7xD for ; Wed, 2 Jun 2010 22:14:50 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B78553A6A01 for ; Wed, 2 Jun 2010 22:14:47 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Thu, 3 Jun 2010 13:08:40 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 46012.3015714703; Thu, 3 Jun 2010 13:08:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o535ELxc010464; Thu, 3 Jun 2010 13:14:21 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 3 Jun 2010 13:11:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-03 13:14:14, Serialize complete at 2010-06-03 13:14:14 Content-Type: multipart/alternative; boundary="=_alternative 001CB94548257737_=" X-MAIL: mse2.zte.com.cn o535ELxc010464 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: precondition X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 05:14:52 -0000 This is a multipart message in MIME format. --=_alternative 001CB94548257737_= Content-Type: text/plain; charset="US-ASCII" > Q1. Does the new behavior of a UAC have nothing to do with > a precondition? If the UAS "conf" the precondition state, UAC should send a new Offer when it reach the confirmed state. Further, if the UAC has no way to reach the confirmed state, it can send CANCEL to the UAS. > > Q2. If a UAC receives a 4xx to reINVITE before the preconditons havebeen met, > does the UAC send a new offer to synchronize both views? Needn't. The reason here is that the modification is not *in use*. > > Q3. In 3.3. UAS Behavior > "Therefore, it is RECOMMENDED that when a UAS decides to start using > the new parameters for a stream for which all mandatory preconditions > have been met, the UAS either sends media using the new parameters or > sends a new offer where the precondition-related attributes for the > stream have been removed. As indicated above, the successful > completion of an offer/answer exchange without preconditions > indicates that the new parameters for the media stream are already > considered to be in use." > > After preconditions have been met, precondition-related > attributes in a SDP are unnecessary? Does the UAC misunderstand > that the preconditions have became unnecessary? No. The precondition ability is express in support header. And if the UA want to express precondition state re-enter to unmet state(such as in wireless access network, UA lose the wireless network resource which is needed for some of the media streams), UA can send a new Offer, expressing the related streams's precondition state as unsatisfied. > > Regards, > Shinji > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001CB94548257737_= Content-Type: text/html; charset="US-ASCII"

> Q1. Does the new behavior of a UAC have nothing to do with
>     a precondition?

If the UAS "conf" the precondition state, UAC should send a new Offer when it reach the confirmed state.

Further, if the UAC has no way to reach the confirmed state, it can send CANCEL to the UAS.

>
> Q2. If a UAC receives a 4xx to reINVITE before the preconditons havebeen met,
>     does the UAC send a new offer to synchronize both views?

Needn't.

The reason here is that the modification is not *in use*.

>
> Q3. In 3.3.  UAS Behavior
>   "Therefore, it is RECOMMENDED that when a UAS decides to start using
>    the new parameters for a stream for which all mandatory preconditions
>    have been met, the UAS either sends media using the new parameters or
>    sends a new offer where the precondition-related attributes for the
>    stream have been removed.  As indicated above, the successful
>    completion of an offer/answer exchange without preconditions
>    indicates that the new parameters for the media stream are already
>    considered to be in use."
>
>     After preconditions have been met, precondition-related
>     attributes in a SDP are unnecessary?  Does the UAC misunderstand
>     that the preconditions have became unnecessary?

No.

The precondition ability is express in support header.

And if the UA want to express precondition state re-enter to unmet state(such as in wireless access network, UA lose the wireless network resource which is needed for some of the media streams), UA can send a new Offer, expressing the related streams's precondition state as unsatisfied.

>
> Regards,
> Shinji
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001CB94548257737_=-- From adam@nostrum.com Thu Jun 3 12:54:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740A93A6A17 for ; Thu, 3 Jun 2010 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rPpL8jArXdz for ; Thu, 3 Jun 2010 12:54:20 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EF5CB3A69D9 for ; Thu, 3 Jun 2010 12:54:19 -0700 (PDT) Received: from dn3-110.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o53Js58L014166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Jun 2010 14:54:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C08085C.70005@nostrum.com> Date: Thu, 03 Jun 2010 14:54:04 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/mixed; boundary="------------030401050808060107020400" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] IETF 78 - Meeting and Sponsorship Information X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 19:54:21 -0000 This is a multi-part message in MIME format. --------------030401050808060107020400 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 78th IETF Meeting Maastricht, Netherlands July 25-30, 2010 1. Sponsorship Opportunities 2. Registration Types 3. Visas and Letters of Invitation 4. Accommodations & Breakfast Information 5. IETF 79 (Beijing) Visa Information 1) Sponsorship Opportunities There are still sponsorship opportunities and benefits for high profile company/organizational exposure at the upcoming IETF meeting in Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go directly to fund the operations of the IETF. See the options at: http://www.ietf.org/meeting/78/index.html "Sponsorship Opportunities" under "General". Each of the sponsorship options provide extended and repeat exposure at this weeklong meeting. Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions and/or to reserve your organization's spot. Thanks in advance for supporting the critical work of the IETF! 2) Register online at: http://www.ietf.org/meetings/78/ 3) Letters of Invitation and Visas Letters of Invitation After you complete the meeting registration process, you will be given the option to request a letter of invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Visas Please check the Netherlands Ministry of Foreign Affairs site (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of countries with visa exemptions. We recommend you give yourself at least one month to complete the visa process. 4) Accommodations & Breakfast Information http://www.ietf.org/meeting/78/hotel.html 5) If you want to start planning for your trip to IETF 79 in Beijing, we have visa information online here: http://www.ietf.org/meeting/79/visa.html Only 52 days until IETF 78! --------------030401050808060107020400 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSUVURi1B bm5vdW5jZSBtYWlsaW5nIGxpc3QKSUVURi1Bbm5vdW5jZUBpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UKCg== --------------030401050808060107020400-- From shinji.okumura@softfront.jp Thu Jun 3 19:01:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A049A3A67CF for ; Thu, 3 Jun 2010 19:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.69 X-Spam-Level: X-Spam-Status: No, score=-94.69 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_54=0.6, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZRRAeRdHtqK for ; Thu, 3 Jun 2010 19:01:34 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 9B6223A6782 for ; Thu, 3 Jun 2010 19:01:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id B9502428018; Fri, 4 Jun 2010 11:01:19 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy0OmkXSkY-3; Fri, 4 Jun 2010 11:01:18 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 752A142800D; Fri, 4 Jun 2010 11:01:17 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Fri, 04 Jun 2010 11:01:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: <63CB0389D0A7C5shinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: precondition X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 02:01:35 -0000 Hi Gao, I have thought about a precondition as below: When UAs use a precondition, all SDP have precondition attributes and all UPDATE are certainly belong to any one of INVITE transaction. But if a UA can send an UPDATE without a precondition, it seems to be ambiguous whether the UPDATE occurs within an INVITE transaction. And your explanations seem to be a new usage of a precondition. Regards, Shinji gao.yang2@zte.com.cn Thu, 3 Jun 2010 13:11:11 +0800 >> Q1. Does the new behavior of a UAC have nothing to do with >> a precondition? > >If the UAS "conf" the precondition state, UAC should send a >new Offer when it reach the confirmed state. > >Further, if the UAC has no way to reach the confirmed state, >it can send CANCEL to the UAS. > >> Q2. If a UAC receives a 4xx to reINVITE before the >> preconditons have been met, does the UAC send a new >> offer to synchronize both views? > >Needn't. > >The reason here is that the modification is not *in use*. > >> Q3. In 3.3. UAS Behavior >> "Therefore, it is RECOMMENDED that when a UAS decides to start using >> the new parameters for a stream for which all mandatory preconditions >> have been met, the UAS either sends media using the new parameters or >> sends a new offer where the precondition-related attributes for the >> stream have been removed. As indicated above, the successful >> completion of an offer/answer exchange without preconditions >> indicates that the new parameters for the media stream are already >> considered to be in use." >> >> After preconditions have been met, precondition-related >> attributes in a SDP are unnecessary? >> Does the UAC misunderstand that the preconditions have >> became unnecessary? > >No. > >The precondition ability is express in support header. > >And if the UA want to express precondition state re-enter to >unmet state(such as in wireless access network, UA lose the >wireless network resource which is needed for some of the >media streams), UA can send a new Offer, expressing the >related streams's precondition state as unsatisfied. > >> >> Regards, >> Shinji From gao.yang2@zte.com.cn Thu Jun 3 22:08:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9363A6911 for ; Thu, 3 Jun 2010 22:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.371 X-Spam-Level: X-Spam-Status: No, score=-99.371 tagged_above=-999 required=5 tests=[AWL=2.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmGXbj9hezqs for ; Thu, 3 Jun 2010 22:08:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 13FF93A6908 for ; Thu, 3 Jun 2010 22:08:12 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Fri, 4 Jun 2010 12:59:59 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 70765.3015714703; Fri, 4 Jun 2010 13:02:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5456vfZ007399; Fri, 4 Jun 2010 13:07:28 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <63CB0389D0A7C5shinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 4 Jun 2010 13:04:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-04 13:07:21, Serialize complete at 2010-06-04 13:07:21 Content-Type: multipart/alternative; boundary="=_alternative 001C178C48257738_=" X-MAIL: mse2.zte.com.cn o5456vfZ007399 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: precondition X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 05:08:14 -0000 This is a multipart message in MIME format. --=_alternative 001C178C48257738_= Content-Type: text/plain; charset="US-ASCII" > I have thought about a precondition as below: > When UAs use a precondition, all SDP have precondition > attributes and all UPDATE are certainly belong to any one of > INVITE transaction. > > But if a UA can send an UPDATE without a precondition, > it seems to be ambiguous whether the UPDATE occurs within an > INVITE transaction. UPDATE and INVITE are two transactions. > > And your explanations seem to be a new usage of a precondition. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001C178C48257738_= Content-Type: text/html; charset="US-ASCII"

> I have thought about a precondition as below:
> When UAs use a precondition, all SDP have precondition
> attributes and all UPDATE are certainly belong to any one of
> INVITE transaction.
>
> But if a UA can send an UPDATE without a precondition,
> it seems to be ambiguous whether the UPDATE occurs within an
> INVITE transaction.

UPDATE and INVITE are two transactions.

>
> And your explanations seem to be a new usage of a precondition.


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001C178C48257738_=-- From jmpolk@cisco.com Fri Jun 4 12:31:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880393A69F5 for ; Fri, 4 Jun 2010 12:31:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ROix4Fkauxs for ; Fri, 4 Jun 2010 12:31:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E7DDD3A69DB for ; Fri, 4 Jun 2010 12:31:01 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANrwCEyrR7H+/2dsb2JhbACeRHGlNZoGhRcEg0k X-IronPort-AV: E=Sophos;i="4.53,362,1272844800"; d="scan'208";a="540075032" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 04 Jun 2010 19:30:48 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o54JUlUi019058; Fri, 4 Jun 2010 19:30:48 GMT Message-Id: <201006041930.o54JUlUi019058@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Jun 2010 14:30:47 -0500 To: gao.yang2@zte.com.cn, OKUMURA Shinji From: "James M. Polk" In-Reply-To: References: <63CB0389D0A7C5shinji.okumura@softfront.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: precondition X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 19:31:05 -0000 At 12:04 AM 6/4/2010, gao.yang2@zte.com.cn wrote: > > I have thought about a precondition as below: > > When UAs use a precondition, all SDP have precondition > > attributes and all UPDATE are certainly belong to any one of > > INVITE transaction. > > > > But if a UA can send an UPDATE without a precondition, > > it seems to be ambiguous whether the UPDATE occurs within an > > INVITE transaction. > >UPDATE and INVITE are two transactions. but within the same dialog > > > > And your explanations seem to be a new usage of a precondition. > > > > >-------------------------------------------------------- >ZTE Information Security Notice: The information contained in this >mail is solely property of the sender's organization. This mail >communication is confidential. Recipients named above are obligated >to maintain secrecy and are not permitted to disclose the contents >of this communication to others. >This email and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they >are addressed. If you have received this email in error please >notify the originator of the message. Any views expressed in this >message are those of the individual sender. >This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > >_______________________________________________ >sipcore mailing list >sipcore@ietf.orghttps://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Mon Jun 7 08:13:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E9B3A679F for ; Mon, 7 Jun 2010 08:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hcenhp5zUuz for ; Mon, 7 Jun 2010 08:13:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2B6A03A8418 for ; Sun, 6 Jun 2010 07:53:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-86-4c0bb65934b2 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9A.C2.29106.956BB0C4; Sun, 6 Jun 2010 16:53:13 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Jun 2010 16:53:13 +0200 Received: from [131.160.126.213] ([131.160.126.213]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Jun 2010 16:53:12 +0200 Message-ID: <4C0BB658.4080705@ericsson.com> Date: Sun, 06 Jun 2010 17:53:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2010 14:53:12.0740 (UTC) FILETIME=[FCA22640:01CB0587] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Fwd: Clarifications on draft-ietf-sipcore-reinvite-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:13:52 -0000 Resending, since the mailing list seemed to be down yesterday. -------- Original Message -------- Subject: Clarifications on draft-ietf-sipcore-reinvite-04.txt Date: Sat, 05 Jun 2010 11:57:46 +0300 From: Gonzalo Camarillo To: SIPCORE Hi, there have been many emails on the glare situations described in: https://datatracker.ietf.org/doc/draft-ietf-sipcore-reinvite/ I have been asked to clarify the meaning of Sections 3.5 and 4.5 of the draft. As the draft indicates, there are glare situations that were not covered by earlier RFCs such as RFC 3261 and RFC 3311. This draft covers those situations. In the beginning, we started working on glare detection and avoidance rules that were as little restrictive as possible. That is, we tried to minimize false positives (i.e., the rules tell you there is a glare when there really is no glare). Such rules would need to analyze the messages involved in a given race condition and decide if the endpoints could end up with different views on the value of any of all the parameters involved in the SIP dialog and its related session. The problem with this approach was that rules were getting too complex. So, we decided to follow the KISS principle and provide simpler rules. The idea was to come up with a relatively simple rule that may cause false positives but would be simple to implement (and understand). SIP already had glare-related rules. When sending or receiving a message with an offer or an answer, UAs use those rules to decide whether or not the outgoing message can be sent at that point and how to respond to the incoming message. So, we decided to use the already existing rules, which deal with glares related to offer/answer exchanges and modify them so that, when using them, UPDATEs were always treated as if they contained an offer. For example, RFC 3311 says: "If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response." Before draft-ietf-sipcore-reinvite-04.txt, if a UA sent an UPDATE and before receiving a 200 for it, the UA received an UPDATE from the remote end, it would not have been considered a glare if either of the UPDATEs did not contain an offer. However, those offerless UPDATEs could be changing non-offer/answer parameters. Consequently, the UAs may end up with different views on the values of those parameters. Draft-ietf-sipcore-reinvite-04.txt treats this scenario as glare to keep the UAs from getting out of synch. The advantage of this approach is that it is relatively simple. The disadvantage is that there are false positives (e.g., maybe the UPDATEs in the example above were not negotiating parameters but simply communicating the value of a non-negotiable parameter to the other end). If people can think of situations were the new rules cause false positives that are *really* problematic, we could look at them. However, let's all keep in mind the KISS principle. It is way too easy to come up with very complicated rules that only give us small gains when compared with the simpler rules in this area. In any case, I will probably clarify the text in the draft so that it is clearer in which situations the glare rules are to be applied. Right now, the draft references RFC 3261 and RFC 3311 but adding informative descriptions to the draft would probably make it easier to understand. Thanks, Gonzalo From shinji.okumura@softfront.jp Mon Jun 7 09:17:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6C428C9D6 for ; Mon, 7 Jun 2010 09:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.669 X-Spam-Level: X-Spam-Status: No, score=-94.669 tagged_above=-999 required=5 tests=[HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_54=0.6, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuUFkWXrL9+D for ; Mon, 7 Jun 2010 09:17:40 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id C9B5C3AA204 for ; Sun, 6 Jun 2010 19:03:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 99B4E428018; Mon, 7 Jun 2010 11:03:58 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3Gm-+YX8ISk; Mon, 7 Jun 2010 11:03:57 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 0E832428010; Mon, 7 Jun 2010 11:03:56 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 07 Jun 2010 11:03:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <63CB0389D0A7C5shinji.okumura@softfront.jp> References: <63CB0389D0A7C5shinji.okumura@softfront.jp> Message-Id: <70CB05E5AF34C7shinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: precondition X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 16:17:45 -0000 Hi, I have additional questions. Q4. If UAs use preconditons but any precondition is not "mandatory", is a behavior of both UAs the same as a case without a precondition? Q5. In 3.3. UAS Behavior The fact that all mandatory preconditions for the stream are met indicates that the new parameters for the media stream are ready to be used. However, they will not actually be used until the UAS decides so. During a session establishment, the UAS can wait before using the media parameters until the callee starts being alerted or until the callee accepts the session. During a session modification, the UAS can wait until its user accepts the changes to the session. Why does the above behavior apply only to mandatory preconditions? I think this behavior can apply also to the case without a precondition. It seems to be an implementation matter. Regards, Shinji >Hi Gao, > >I have thought about a precondition as below: >When UAs use a precondition, all SDP have precondition >attributes and all UPDATE certainly belong to any one of >INVITE transactions. > >But if a UA can send an UPDATE without a precondition, >it seems to be ambiguous whether the UPDATE occurs within an >INVITE transaction. > >And your explanations seem to be a new usage of a precondition. > >Regards, >Shinji > >gao.yang2@zte.com.cn >Thu, 3 Jun 2010 13:11:11 +0800 >>> Q1. Does the new behavior of a UAC have nothing to do with >>> a precondition? >> >>If the UAS "conf" the precondition state, UAC should send a >>new Offer when it reach the confirmed state. >> >>Further, if the UAC has no way to reach the confirmed state, >>it can send CANCEL to the UAS. >> >>> Q2. If a UAC receives a 4xx to reINVITE before the >>> preconditons have been met, does the UAC send a new >>> offer to synchronize both views? >> >>Needn't. >> >>The reason here is that the modification is not *in use*. >> >>> Q3. In 3.3. UAS Behavior >>> "Therefore, it is RECOMMENDED that when a UAS decides to start using >>> the new parameters for a stream for which all mandatory preconditions >>> have been met, the UAS either sends media using the new parameters or >>> sends a new offer where the precondition-related attributes for the >>> stream have been removed. As indicated above, the successful >>> completion of an offer/answer exchange without preconditions >>> indicates that the new parameters for the media stream are already >>> considered to be in use." >>> >>> After preconditions have been met, precondition-related >>> attributes in a SDP are unnecessary? >>> Does the UAC misunderstand that the preconditions have >>> became unnecessary? >> >>No. >> >>The precondition ability is express in support header. >> >>And if the UA want to express precondition state re-enter to >>unmet state(such as in wireless access network, UA lose the >>wireless network resource which is needed for some of the >>media streams), UA can send a new Offer, expressing the >>related streams's precondition state as unsatisfied. >> >>> >>> Regards, >>> Shinji >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From shinji.okumura@softfront.jp Mon Jun 7 09:21:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAF428C981 for ; Mon, 7 Jun 2010 09:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.969 X-Spam-Level: X-Spam-Status: No, score=-94.969 tagged_above=-999 required=5 tests=[AWL=0.300, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY7ugBCoDXYJ for ; Mon, 7 Jun 2010 09:21:12 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id E2DD828C27C for ; Sun, 6 Jun 2010 20:56:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 9F7EF428018 for ; Mon, 7 Jun 2010 12:56:32 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuzUioEvOGmL for ; Mon, 7 Jun 2010 12:56:31 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 789B8428010 for ; Mon, 7 Jun 2010 12:56:30 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Mon, 07 Jun 2010 12:56:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) Message-Id: <9ACB05F5690400shinji.okumura@softfront.jp> Subject: [sipcore] draft-ietf-sipcore-reinvite-04: 4xx and UPDATE from UAS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 16:21:13 -0000 Hi all, In following cases, should a UAC(A) send a new offer to sync a common view? A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| non-2xx|s1 |<------------------------------| s0|ACK ACK |s0 |------------> ------------>| | UPD(offer2)| |<==============================| |2xx-UPD(answer2) | |==============================>| s2| |s2 | | A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| UPD(offer2)|s1 | /============| | / non-2xx| |<---------------/--------------| s0|ACK / ACK |s0 |------------> / ----------->| | / | |<===========/ | |2xx-UPD(answer2) | |==============================>| s2| |s2 | | I think a common view of both UAs has been already synchronized. Regards, Shinji From pkyzivat@cisco.com Mon Jun 7 09:36:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129D528C630 for ; Mon, 7 Jun 2010 09:36:00 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKAzYo2ZuGlQ for ; Mon, 7 Jun 2010 09:35:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C1B1428CB85 for ; Mon, 7 Jun 2010 05:51:57 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMeIDExAZnwN/2dsb2JhbACeRHGkU5llhRcE X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="118868749" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Jun 2010 12:51:45 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o57CpjnC029618 for ; Mon, 7 Jun 2010 12:51:45 GMT Message-ID: <4C0CEB61.5070104@cisco.com> Date: Mon, 07 Jun 2010 08:51:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] test X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 16:36:00 -0000 Please ignore this. There have been reports that the mailing list isn't working, so I'm trying it out. Thanks, Paul From pkyzivat@cisco.com Mon Jun 7 10:39:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E98428C2D3 for ; Mon, 7 Jun 2010 10:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpXxIzo4vz1Q for ; Mon, 7 Jun 2010 10:39:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1B14A28C1A1 for ; Mon, 7 Jun 2010 09:48:07 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGK/DEyrR7H+/2dsb2JhbACeJHGmM5ofglmCPgQ X-IronPort-AV: E=Sophos;i="4.53,379,1272844800"; d="scan'208";a="260248814" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2010 16:48:07 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o57Gm77q004345; Mon, 7 Jun 2010 16:48:07 GMT Message-ID: <4C0D22C6.8090002@cisco.com> Date: Mon, 07 Jun 2010 12:48:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C0BB658.4080705@ericsson.com> In-Reply-To: <4C0BB658.4080705@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Fwd: Clarifications on draft-ietf-sipcore-reinvite-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:39:15 -0000 Gonzalo, Thank you for clarification. More inline. Gonzalo Camarillo wrote: > Resending, since the mailing list seemed to be down yesterday. > > -------- Original Message -------- > Subject: Clarifications on draft-ietf-sipcore-reinvite-04.txt > Date: Sat, 05 Jun 2010 11:57:46 +0300 > From: Gonzalo Camarillo > To: SIPCORE > > Hi, > > there have been many emails on the glare situations described in: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-reinvite/ > > I have been asked to clarify the meaning of Sections 3.5 and 4.5 of the > draft. > > As the draft indicates, there are glare situations that were not covered > by earlier RFCs such as RFC 3261 and RFC 3311. This draft covers those > situations. In the beginning, we started working on glare detection and > avoidance rules that were as little restrictive as possible. That is, we > tried to minimize false positives (i.e., the rules tell you there is a > glare when there really is no glare). Such rules would need to analyze > the messages involved in a given race condition and decide if the > endpoints could end up with different views on the value of any of all > the parameters involved in the SIP dialog and its related session. > > The problem with this approach was that rules were getting too complex. > So, we decided to follow the KISS principle and provide simpler rules. > The idea was to come up with a relatively simple rule that may cause > false positives but would be simple to implement (and understand). This seems reasonable, especially since such glare situations are rare in the first place. > SIP already had glare-related rules. When sending or receiving a message > with an offer or an answer, UAs use those rules to decide whether or not > the outgoing message can be sent at that point and how to respond to the > incoming message. So, we decided to use the already existing rules, > which deal with glares related to offer/answer exchanges and modify them > so that, when using them, UPDATEs were always treated as if they > contained an offer. > > For example, RFC 3311 says: > > "If an UPDATE is received that contains an offer, and the UAS has > generated an offer (in an UPDATE, PRACK or INVITE) to which it has > not yet received an answer, the UAS MUST reject the UPDATE with a 491 > response." > > Before draft-ietf-sipcore-reinvite-04.txt, if a UA sent an UPDATE and > before receiving a 200 for it, the UA received an UPDATE from the remote > end, it would not have been considered a glare if either of the UPDATEs > did not contain an offer. However, those offerless UPDATEs could be > changing non-offer/answer parameters. Consequently, the UAs may end up > with different views on the values of those parameters. > Draft-ietf-sipcore-reinvite-04.txt treats this scenario as glare to keep > the UAs from getting out of synch. > The advantage of this approach is that it is relatively simple. The > disadvantage is that there are false positives (e.g., maybe the UPDATEs > in the example above were not negotiating parameters but simply > communicating the value of a non-negotiable parameter to the other end). I think the case is good wrt two *negotiable* pieces of state, such as sdp and session-timer. Not so good wrt non-negotiable state. > If people can think of situations were the new rules cause false > positives that are *really* problematic, we could look at them. However, > let's all keep in mind the KISS principle. It is way too easy to come up > with very complicated rules that only give us small gains when compared > with the simpler rules in this area. ISTM that when non-negotiable info is concerned the situation is different. These don't conflict. There are a couple of those sorts of things (I don't know how many others there might be) that have come up for discussion: - called party identity - remote target In the case of called party identity, it might be harmless to lump it in with the glare cases, even though it really isn't one. But in the case of remote target, if the sender has lost its old address there is only one chance to fix it. Perhaps the probability losing an address and getting glare while trying to update it is so low that we don't care about it failing. I'm willing to entertain that, as long as we all recognize that is what we are doing. > In any case, I will probably clarify the text in the draft so that it is > clearer in which situations the glare rules are to be applied. Right > now, the draft references RFC 3261 and RFC 3311 but adding informative > descriptions to the draft would probably make it easier to understand. IMO that will go a long way to sorting this out. The "treat as if the update had an offer" has proven to leave many questions open to further interpretation. Among other things, 3261 and 3311 address offer/answer glare, and only incidentally glare between messages. There is no real addressing of invite-update glare. Of course the o/a draft has worked to clarify that. We will have to now decide whether to put more specificity into the reinvite draft, or to just put some basics there and elaborate in the o/a draft. Thanks, Paul From gao.yang2@zte.com.cn Mon Jun 7 17:56:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33B63A6844 for ; Mon, 7 Jun 2010 17:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.435 X-Spam-Level: X-Spam-Status: No, score=-94.435 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMtLwb7aQYU8 for ; Mon, 7 Jun 2010 17:56:58 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id AF9E13A67B2 for ; Mon, 7 Jun 2010 17:56:52 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Tue, 8 Jun 2010 08:50:40 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 2748.3015714703; Tue, 8 Jun 2010 08:56:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o580uhY2045387; Tue, 8 Jun 2010 08:56:43 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <70CB05E5AF34C7shinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 8 Jun 2010 08:53:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-08 08:56:41, Serialize complete at 2010-06-08 08:56:41 Content-Type: multipart/alternative; boundary="=_alternative 0005242D4825773C_=" X-MAIL: mse2.zte.com.cn o580uhY2045387 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: precondition X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 00:56:59 -0000 This is a multipart message in MIME format. --=_alternative 0005242D4825773C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlIHNlbWFudGljcyBvZiAiU3VzcGVuZGluZyBhbmQgUmVzdW1pbmcgU2Vzc2lvbiBFc3RhYmxp c2htZW50IiBpcyBqdXN0IA0KYWJvdXQgbWFuZGF0b3J5IHByZWNvbmRpdG9uLg0KDQpUaGVuLCBv dGhlciBwcmVjb25kaXRvbiB3aXRob3V0IG1hbmRhdG9yeSBzdHJvbmduZXNzIGNhbiBiZSBoYW5k bGVkIGFzIA0KUkZDMzI2NCdzIGRlZmluaXRpb24uIFRoYXQgaXMganVzdCAqaW4gdXNlKiBhZnRl ciBPL0EuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDog MjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVf bWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQoNCg0KT0tVTVVSQSBTaGluamkgPHNoaW5qaS5va3VtdXJhQHNvZnRmcm9udC5q cD4gDQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDYtMDcgMTA6MDMN Cg0KytW8/sjLDQoic2lwY29yZUBpZXRmLm9yZyIgPHNpcGNvcmVAaWV0Zi5vcmc+DQqzrcvNDQpn YW8ueWFuZzJAenRlLmNvbS5jbg0K1vfM4g0KUmU6IFtzaXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNv cmUtcmVpbnZpdGUtMDQ6IHByZWNvbmRpdGlvbg0KDQoNCg0KDQoNCg0KSGksDQoNCkkgaGF2ZSBh ZGRpdGlvbmFsIHF1ZXN0aW9ucy4NCg0KUTQuIElmIFVBcyB1c2UgcHJlY29uZGl0b25zIGJ1dCBh bnkgcHJlY29uZGl0aW9uIGlzIG5vdA0KICAgICJtYW5kYXRvcnkiLCBpcyBhIGJlaGF2aW9yIG9m IGJvdGggVUFzIHRoZSBzYW1lIGFzIGENCiAgICBjYXNlIHdpdGhvdXQgYSBwcmVjb25kaXRpb24/ DQoNClE1LiBJbiAzLjMuICBVQVMgQmVoYXZpb3INCiAgIFRoZSBmYWN0IHRoYXQgYWxsIG1hbmRh dG9yeSBwcmVjb25kaXRpb25zIGZvciB0aGUgc3RyZWFtIGFyZSBtZXQNCiAgIGluZGljYXRlcyB0 aGF0IHRoZSBuZXcgcGFyYW1ldGVycyBmb3IgdGhlIG1lZGlhIHN0cmVhbSBhcmUgcmVhZHkgdG8N CiAgIGJlIHVzZWQuICBIb3dldmVyLCB0aGV5IHdpbGwgbm90IGFjdHVhbGx5IGJlIHVzZWQgdW50 aWwgdGhlIFVBUw0KICAgZGVjaWRlcyBzby4gIER1cmluZyBhIHNlc3Npb24gZXN0YWJsaXNobWVu dCwgdGhlIFVBUyBjYW4gd2FpdCBiZWZvcmUNCiAgIHVzaW5nIHRoZSBtZWRpYSBwYXJhbWV0ZXJz IHVudGlsIHRoZSBjYWxsZWUgc3RhcnRzIGJlaW5nIGFsZXJ0ZWQgb3INCiAgIHVudGlsIHRoZSBj YWxsZWUgYWNjZXB0cyB0aGUgc2Vzc2lvbi4gIER1cmluZyBhIHNlc3Npb24gbW9kaWZpY2F0aW9u LA0KICAgdGhlIFVBUyBjYW4gd2FpdCB1bnRpbCBpdHMgdXNlciBhY2NlcHRzIHRoZSBjaGFuZ2Vz IHRvIHRoZSBzZXNzaW9uLg0KDQogICAgV2h5IGRvZXMgdGhlIGFib3ZlIGJlaGF2aW9yIGFwcGx5 IG9ubHkgdG8gbWFuZGF0b3J5DQogICAgcHJlY29uZGl0aW9ucz8gSSB0aGluayB0aGlzIGJlaGF2 aW9yIGNhbiBhcHBseSBhbHNvIHRvDQogICAgdGhlIGNhc2Ugd2l0aG91dCBhIHByZWNvbmRpdGlv bi4NCiAgICBJdCBzZWVtcyB0byBiZSBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIuDQoNClJlZ2Fy ZHMsDQpTaGluamkNCg0KPkhpIEdhbywNCj4NCj5JIGhhdmUgdGhvdWdodCBhYm91dCBhIHByZWNv bmRpdGlvbiBhcyBiZWxvdzoNCj5XaGVuIFVBcyB1c2UgYSBwcmVjb25kaXRpb24sIGFsbCBTRFAg aGF2ZSBwcmVjb25kaXRpb24NCj5hdHRyaWJ1dGVzIGFuZCBhbGwgVVBEQVRFIGNlcnRhaW5seSBi ZWxvbmcgdG8gYW55IG9uZSBvZg0KPklOVklURSB0cmFuc2FjdGlvbnMuDQo+DQo+QnV0IGlmIGEg VUEgY2FuIHNlbmQgYW4gVVBEQVRFIHdpdGhvdXQgYSBwcmVjb25kaXRpb24sDQo+aXQgc2VlbXMg dG8gYmUgYW1iaWd1b3VzIHdoZXRoZXIgdGhlIFVQREFURSBvY2N1cnMgd2l0aGluIGFuDQo+SU5W SVRFIHRyYW5zYWN0aW9uLg0KPg0KPkFuZCB5b3VyIGV4cGxhbmF0aW9ucyBzZWVtIHRvIGJlIGEg bmV3IHVzYWdlIG9mIGEgcHJlY29uZGl0aW9uLg0KPg0KPlJlZ2FyZHMsDQo+U2hpbmppDQo+DQo+ Z2FvLnlhbmcyQHp0ZS5jb20uY24NCj5UaHUsIDMgSnVuIDIwMTAgMTM6MTE6MTEgKzA4MDANCj4+ PiBRMS4gRG9lcyB0aGUgbmV3IGJlaGF2aW9yIG9mIGEgVUFDIGhhdmUgbm90aGluZyB0byBkbyB3 aXRoDQo+Pj4gICAgIGEgcHJlY29uZGl0aW9uPw0KPj4NCj4+SWYgdGhlIFVBUyAiY29uZiIgdGhl IHByZWNvbmRpdGlvbiBzdGF0ZSwgVUFDIHNob3VsZCBzZW5kIGENCj4+bmV3IE9mZmVyIHdoZW4g aXQgcmVhY2ggdGhlIGNvbmZpcm1lZCBzdGF0ZS4gDQo+Pg0KPj5GdXJ0aGVyLCBpZiB0aGUgVUFD IGhhcyBubyB3YXkgdG8gcmVhY2ggdGhlIGNvbmZpcm1lZCBzdGF0ZSwNCj4+aXQgY2FuIHNlbmQg Q0FOQ0VMIHRvIHRoZSBVQVMuDQo+Pg0KPj4+IFEyLiBJZiBhIFVBQyByZWNlaXZlcyBhIDR4eCB0 byByZUlOVklURSBiZWZvcmUgdGhlDQo+Pj4gICAgIHByZWNvbmRpdG9ucyBoYXZlIGJlZW4gbWV0 LCBkb2VzIHRoZSBVQUMgc2VuZCBhIG5ldw0KPj4+ICAgICBvZmZlciB0byBzeW5jaHJvbml6ZSBi b3RoIHZpZXdzPw0KPj4NCj4+TmVlZG4ndC4NCj4+DQo+PlRoZSByZWFzb24gaGVyZSBpcyB0aGF0 IHRoZSBtb2RpZmljYXRpb24gaXMgbm90ICppbiB1c2UqLg0KPj4NCj4+PiBRMy4gSW4gMy4zLiAg VUFTIEJlaGF2aW9yDQo+Pj4gICAiVGhlcmVmb3JlLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHdo ZW4gYSBVQVMgZGVjaWRlcyB0byBzdGFydCB1c2luZw0KPj4+ICAgIHRoZSBuZXcgcGFyYW1ldGVy cyBmb3IgYSBzdHJlYW0gZm9yIHdoaWNoIGFsbCBtYW5kYXRvcnkgDQpwcmVjb25kaXRpb25zDQo+ Pj4gICAgaGF2ZSBiZWVuIG1ldCwgdGhlIFVBUyBlaXRoZXIgc2VuZHMgbWVkaWEgdXNpbmcgdGhl IG5ldyBwYXJhbWV0ZXJzIA0Kb3INCj4+PiAgICBzZW5kcyBhIG5ldyBvZmZlciB3aGVyZSB0aGUg cHJlY29uZGl0aW9uLXJlbGF0ZWQgYXR0cmlidXRlcyBmb3IgdGhlDQo+Pj4gICAgc3RyZWFtIGhh dmUgYmVlbiByZW1vdmVkLiAgQXMgaW5kaWNhdGVkIGFib3ZlLCB0aGUgc3VjY2Vzc2Z1bA0KPj4+ ICAgIGNvbXBsZXRpb24gb2YgYW4gb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIHdpdGhvdXQgcHJlY29u ZGl0aW9ucw0KPj4+ICAgIGluZGljYXRlcyB0aGF0IHRoZSBuZXcgcGFyYW1ldGVycyBmb3IgdGhl IG1lZGlhIHN0cmVhbSBhcmUgYWxyZWFkeQ0KPj4+ICAgIGNvbnNpZGVyZWQgdG8gYmUgaW4gdXNl LiINCj4+PiANCj4+PiAgICAgQWZ0ZXIgcHJlY29uZGl0aW9ucyBoYXZlIGJlZW4gbWV0LCBwcmVj b25kaXRpb24tcmVsYXRlZA0KPj4+ICAgICBhdHRyaWJ1dGVzIGluIGEgU0RQIGFyZSB1bm5lY2Vz c2FyeT8NCj4+PiAgICAgRG9lcyB0aGUgVUFDIG1pc3VuZGVyc3RhbmQgdGhhdCB0aGUgcHJlY29u ZGl0aW9ucyBoYXZlDQo+Pj4gICAgIGJlY2FtZSB1bm5lY2Vzc2FyeT8NCj4+DQo+Pk5vLg0KPj4N Cj4+VGhlIHByZWNvbmRpdGlvbiBhYmlsaXR5IGlzIGV4cHJlc3MgaW4gc3VwcG9ydCBoZWFkZXIu DQo+Pg0KPj5BbmQgaWYgdGhlIFVBIHdhbnQgdG8gZXhwcmVzcyBwcmVjb25kaXRpb24gc3RhdGUg cmUtZW50ZXIgdG8NCj4+dW5tZXQgc3RhdGUoc3VjaCBhcyBpbiB3aXJlbGVzcyBhY2Nlc3MgbmV0 d29yaywgVUEgbG9zZSB0aGUNCj4+d2lyZWxlc3MgbmV0d29yayByZXNvdXJjZSB3aGljaCBpcyBu ZWVkZWQgZm9yIHNvbWUgb2YgdGhlDQo+Pm1lZGlhIHN0cmVhbXMpLCBVQSBjYW4gc2VuZCBhIG5l dyBPZmZlciwgZXhwcmVzc2luZyB0aGUNCj4+cmVsYXRlZCBzdHJlYW1zJ3MgcHJlY29uZGl0aW9u IHN0YXRlIGFzIHVuc2F0aXNmaWVkLg0KPj4NCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IFNoaW5q aQ0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2lw Y29yZSBtYWlsaW5nIGxpc3QNCj5zaXBjb3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 0005242D4825773C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBzZW1hbnRpY3Mgb2YgJnF1 b3Q7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDAyMDQxIGZhY2U9IkNvdXJpZXIgTmV3Ij48 Yj5TdXNwZW5kaW5nDQphbmQgUmVzdW1pbmcgU2Vzc2lvbiBFc3RhYmxpc2htZW50PC9iPjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7DQppcyBqdXN0IGFib3V0IG1h bmRhdG9yeSBwcmVjb25kaXRvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlRoZW4sIG90aGVyIHByZWNvbmRpdG9uIHdpdGhvdXQgbWFuZGF0b3J5DQpz dHJvbmduZXNzIGNhbiBiZSBoYW5kbGVkIGFzIFJGQzMyNjQncyBkZWZpbml0aW9uLiBUaGF0IGlz IGp1c3QgKmluIHVzZSoNCmFmdGVyIE8vQS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJy Pg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3 MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDog Z2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MzQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5PS1VNVVJBIFNoaW5qaSAmbHQ7c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwJmd0OzwvYj4N CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJz cDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAxMC0wNi0wNyAxMDowMzwvZm9udD4NCjx0ZCB3aWR0aD02NSU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7 ICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Z2FvLnlhbmcyQHp0 ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBj b3JlLXJlaW52aXRlLTA0Og0KcHJlY29uZGl0aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSw8YnI+DQo8YnI+DQpJIGhhdmUgYWRk aXRpb25hbCBxdWVzdGlvbnMuPGJyPg0KPGJyPg0KUTQuIElmIFVBcyB1c2UgcHJlY29uZGl0b25z IGJ1dCBhbnkgcHJlY29uZGl0aW9uIGlzIG5vdDxicj4NCiAmbmJzcDsgJm5ic3A7JnF1b3Q7bWFu ZGF0b3J5JnF1b3Q7LCBpcyBhIGJlaGF2aW9yIG9mIGJvdGggVUFzIHRoZSBzYW1lDQphcyBhPGJy Pg0KICZuYnNwOyAmbmJzcDtjYXNlIHdpdGhvdXQgYSBwcmVjb25kaXRpb24/PGJyPg0KPGJyPg0K UTUuIEluIDMuMy4gJm5ic3A7VUFTIEJlaGF2aW9yPGJyPg0KICZuYnNwOyBUaGUgZmFjdCB0aGF0 IGFsbCBtYW5kYXRvcnkgcHJlY29uZGl0aW9ucyBmb3IgdGhlIHN0cmVhbSBhcmUgbWV0PGJyPg0K ICZuYnNwOyBpbmRpY2F0ZXMgdGhhdCB0aGUgbmV3IHBhcmFtZXRlcnMgZm9yIHRoZSBtZWRpYSBz dHJlYW0gYXJlIHJlYWR5DQp0bzxicj4NCiAmbmJzcDsgYmUgdXNlZC4gJm5ic3A7SG93ZXZlciwg dGhleSB3aWxsIG5vdCBhY3R1YWxseSBiZSB1c2VkIHVudGlsIHRoZQ0KVUFTPGJyPg0KICZuYnNw OyBkZWNpZGVzIHNvLiAmbmJzcDtEdXJpbmcgYSBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIHRoZSBV QVMgY2FuIHdhaXQNCmJlZm9yZTxicj4NCiAmbmJzcDsgdXNpbmcgdGhlIG1lZGlhIHBhcmFtZXRl cnMgdW50aWwgdGhlIGNhbGxlZSBzdGFydHMgYmVpbmcgYWxlcnRlZA0Kb3I8YnI+DQogJm5ic3A7 IHVudGlsIHRoZSBjYWxsZWUgYWNjZXB0cyB0aGUgc2Vzc2lvbi4gJm5ic3A7RHVyaW5nIGEgc2Vz c2lvbiBtb2RpZmljYXRpb24sPGJyPg0KICZuYnNwOyB0aGUgVUFTIGNhbiB3YWl0IHVudGlsIGl0 cyB1c2VyIGFjY2VwdHMgdGhlIGNoYW5nZXMgdG8gdGhlIHNlc3Npb24uPGJyPg0KPGJyPg0KICZu YnNwOyAmbmJzcDtXaHkgZG9lcyB0aGUgYWJvdmUgYmVoYXZpb3IgYXBwbHkgb25seSB0byBtYW5k YXRvcnk8YnI+DQogJm5ic3A7ICZuYnNwO3ByZWNvbmRpdGlvbnM/IEkgdGhpbmsgdGhpcyBiZWhh dmlvciBjYW4gYXBwbHkgYWxzbyB0bzxicj4NCiAmbmJzcDsgJm5ic3A7dGhlIGNhc2Ugd2l0aG91 dCBhIHByZWNvbmRpdGlvbi48YnI+DQogJm5ic3A7ICZuYnNwO0l0IHNlZW1zIHRvIGJlIGFuIGlt cGxlbWVudGF0aW9uIG1hdHRlci48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClNoaW5qaTxicj4N Cjxicj4NCiZndDtIaSBHYW8sPGJyPg0KJmd0Ozxicj4NCiZndDtJIGhhdmUgdGhvdWdodCBhYm91 dCBhIHByZWNvbmRpdGlvbiBhcyBiZWxvdzo8YnI+DQomZ3Q7V2hlbiBVQXMgdXNlIGEgcHJlY29u ZGl0aW9uLCBhbGwgU0RQIGhhdmUgcHJlY29uZGl0aW9uPGJyPg0KJmd0O2F0dHJpYnV0ZXMgYW5k IGFsbCBVUERBVEUgY2VydGFpbmx5IGJlbG9uZyB0byBhbnkgb25lIG9mPGJyPg0KJmd0O0lOVklU RSB0cmFuc2FjdGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDtCdXQgaWYgYSBVQSBjYW4gc2VuZCBh biBVUERBVEUgd2l0aG91dCBhIHByZWNvbmRpdGlvbiw8YnI+DQomZ3Q7aXQgc2VlbXMgdG8gYmUg YW1iaWd1b3VzIHdoZXRoZXIgdGhlIFVQREFURSBvY2N1cnMgd2l0aGluIGFuPGJyPg0KJmd0O0lO VklURSB0cmFuc2FjdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0O0FuZCB5b3VyIGV4cGxhbmF0aW9u cyBzZWVtIHRvIGJlIGEgbmV3IHVzYWdlIG9mIGEgcHJlY29uZGl0aW9uLjxicj4NCiZndDs8YnI+ DQomZ3Q7UmVnYXJkcyw8YnI+DQomZ3Q7U2hpbmppPGJyPg0KJmd0Ozxicj4NCiZndDtnYW8ueWFu ZzJAenRlLmNvbS5jbjxicj4NCiZndDtUaHUsIDMgSnVuIDIwMTAgMTM6MTE6MTEgKzA4MDA8YnI+ DQomZ3Q7Jmd0OyZndDsgUTEuIERvZXMgdGhlIG5ldyBiZWhhdmlvciBvZiBhIFVBQyBoYXZlIG5v dGhpbmcgdG8gZG8gd2l0aDxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IGEgcHJlY29u ZGl0aW9uPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtJZiB0aGUgVUFTICZxdW90O2NvbmYm cXVvdDsgdGhlIHByZWNvbmRpdGlvbiBzdGF0ZSwgVUFDIHNob3VsZA0Kc2VuZCBhPGJyPg0KJmd0 OyZndDtuZXcgT2ZmZXIgd2hlbiBpdCByZWFjaCB0aGUgY29uZmlybWVkIHN0YXRlLiA8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7RnVydGhlciwgaWYgdGhlIFVBQyBoYXMgbm8gd2F5IHRvIHJl YWNoIHRoZSBjb25maXJtZWQgc3RhdGUsPGJyPg0KJmd0OyZndDtpdCBjYW4gc2VuZCBDQU5DRUwg dG8gdGhlIFVBUy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBRMi4gSWYgYSBVQUMg cmVjZWl2ZXMgYSA0eHggdG8gcmVJTlZJVEUgYmVmb3JlIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyAm bmJzcDsgJm5ic3A7IHByZWNvbmRpdG9ucyBoYXZlIGJlZW4gbWV0LCBkb2VzIHRoZSBVQUMgc2Vu ZA0KYSBuZXc8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyBvZmZlciB0byBzeW5jaHJv bml6ZSBib3RoIHZpZXdzPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtOZWVkbid0Ljxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtUaGUgcmVhc29uIGhlcmUgaXMgdGhhdCB0aGUgbW9kaWZp Y2F0aW9uIGlzIG5vdCAqaW4gdXNlKi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBR My4gSW4gMy4zLiAmbmJzcDtVQVMgQmVoYXZpb3I8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZx dW90O1RoZXJlZm9yZSwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCB3aGVuIGEgVUFTDQpkZWNpZGVz IHRvIHN0YXJ0IHVzaW5nPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt0aGUgbmV3IHBh cmFtZXRlcnMgZm9yIGEgc3RyZWFtIGZvciB3aGljaCBhbGwNCm1hbmRhdG9yeSBwcmVjb25kaXRp b25zPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtoYXZlIGJlZW4gbWV0LCB0aGUgVUFT IGVpdGhlciBzZW5kcyBtZWRpYSB1c2luZw0KdGhlIG5ldyBwYXJhbWV0ZXJzIG9yPGJyPg0KJmd0 OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtzZW5kcyBhIG5ldyBvZmZlciB3aGVyZSB0aGUgcHJlY29u ZGl0aW9uLXJlbGF0ZWQNCmF0dHJpYnV0ZXMgZm9yIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7c3RyZWFtIGhhdmUgYmVlbiByZW1vdmVkLiAmbmJzcDtBcyBpbmRpY2F0ZWQNCmFi b3ZlLCB0aGUgc3VjY2Vzc2Z1bDxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7Y29tcGxl dGlvbiBvZiBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2Ugd2l0aG91dA0KcHJlY29uZGl0aW9uczxi cj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7aW5kaWNhdGVzIHRoYXQgdGhlIG5ldyBwYXJh bWV0ZXJzIGZvciB0aGUgbWVkaWENCnN0cmVhbSBhcmUgYWxyZWFkeTxicj4NCiZndDsmZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7Y29uc2lkZXJlZCB0byBiZSBpbiB1c2UuJnF1b3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IEFmdGVyIHByZWNvbmRpdGlv bnMgaGF2ZSBiZWVuIG1ldCwgcHJlY29uZGl0aW9uLXJlbGF0ZWQ8YnI+DQomZ3Q7Jmd0OyZndDsg Jm5ic3A7ICZuYnNwOyBhdHRyaWJ1dGVzIGluIGEgU0RQIGFyZSB1bm5lY2Vzc2FyeT88YnI+DQom Z3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyBEb2VzIHRoZSBVQUMgbWlzdW5kZXJzdGFuZCB0aGF0 IHRoZSBwcmVjb25kaXRpb25zDQpoYXZlPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsg YmVjYW1lIHVubmVjZXNzYXJ5Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtOby48YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7VGhlIHByZWNvbmRpdGlvbiBhYmlsaXR5IGlzIGV4cHJlc3Mg aW4gc3VwcG9ydCBoZWFkZXIuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0FuZCBpZiB0aGUg VUEgd2FudCB0byBleHByZXNzIHByZWNvbmRpdGlvbiBzdGF0ZSByZS1lbnRlciB0bzxicj4NCiZn dDsmZ3Q7dW5tZXQgc3RhdGUoc3VjaCBhcyBpbiB3aXJlbGVzcyBhY2Nlc3MgbmV0d29yaywgVUEg bG9zZSB0aGU8YnI+DQomZ3Q7Jmd0O3dpcmVsZXNzIG5ldHdvcmsgcmVzb3VyY2Ugd2hpY2ggaXMg bmVlZGVkIGZvciBzb21lIG9mIHRoZTxicj4NCiZndDsmZ3Q7bWVkaWEgc3RyZWFtcyksIFVBIGNh biBzZW5kIGEgbmV3IE9mZmVyLCBleHByZXNzaW5nIHRoZTxicj4NCiZndDsmZ3Q7cmVsYXRlZCBz dHJlYW1zJ3MgcHJlY29uZGl0aW9uIHN0YXRlIGFzIHVuc2F0aXNmaWVkLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsm Z3Q7Jmd0OyBTaGluamk8YnI+DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7c2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7c2lw Y29yZUBpZXRmLm9yZzxicj4NCiZndDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmU8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxi cj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjxi cj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24m bmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNw O2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVs eSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2Fu aXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZu YnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZu YnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5 Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtk aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5k Jm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZu YnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29s ZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5i c3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Jl Y2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFz ZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZu YnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hh cyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZu YnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwv cHJlPg== --=_alternative 0005242D4825773C_=-- From gao.yang2@zte.com.cn Mon Jun 7 18:06:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F5E3A68DA for ; Mon, 7 Jun 2010 18:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.735 X-Spam-Level: X-Spam-Status: No, score=-94.735 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm6w9zPGy8Bx for ; Mon, 7 Jun 2010 18:06:27 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B8A7E3A68D4 for ; Mon, 7 Jun 2010 18:06:26 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Tue, 8 Jun 2010 09:00:14 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 37079.3721391490; Tue, 8 Jun 2010 09:00:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5812Psk051074; Tue, 8 Jun 2010 09:02:25 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <201006041930.o54JUlUi019058@sj-core-2.cisco.com> To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 8 Jun 2010 08:57:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-08 09:02:23, Serialize complete at 2010-06-08 09:02:23 Content-Type: multipart/alternative; boundary="=_alternative 00057C734825773C_=" X-MAIL: mse2.zte.com.cn o5812Psk051074 Cc: OKUMURA Shinji , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: precondition X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 01:06:28 -0000 This is a multipart message in MIME format. --=_alternative 00057C734825773C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Ly9JIG9uY2Ugc2VudCB0aGUgbWFpbCBhdCB3ZWVrZW5kLCBidXQgdGhlIE1MIGRpZG4ndCBkaXNw YXRjaCB0aGUgbWFpbC4gDQpTbywgSSBhbSByZXNlbmRpbmcgaXQgbm93Lg0KDQpUaGUgcG9pbnQg aGVyZSBpcyB3aGV0aGVyIHRoaXMgbW9kaWZpY2F0aW9uICppbiB1c2UqIG9yIG5vdC4NCg0KdGhl IHVzZSBjYXNlIHRhbGtlZCBoZXJlIGlzIGFib3V0IHNlc3Npb24gbW9kaWZpY2F0aW9uIHdpdGgg cHJlY29uZGl0aW9uLg0KDQpJZiB0aGUgbW9kaWZpY2F0aW9uICppbiB1c2UqLCB0aGUgVUFTIHNo b3VsZCBzZW5kIDJ4eCB0byB0aGlzIFJlLUlOVklURS4NCg0KDQpJZiB5b3UgdGhpbmsgdGhlcmUn cyBzb21ldGhpbmcgbm90IGNsZWFyLCBmZWVsIGZyZWUgdG8gY29tbWVudC4NCg0KVGhhbmtzLA0K DQpHYW8gDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDog MjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVf bWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQoNCg0KIkphbWVzIE0uIFBvbGsiIDxqbXBvbGtAY2lzY28uY29tPiANCjIwMTAt MDYtMDUgMDM6MzANCg0KytW8/sjLDQpnYW8ueWFuZzJAenRlLmNvbS5jbiwgT0tVTVVSQSBTaGlu amkgPHNoaW5qaS5va3VtdXJhQHNvZnRmcm9udC5qcD4NCrOty80NCiJzaXBjb3JlQGlldGYub3Jn IiA8c2lwY29yZUBpZXRmLm9yZz4NCtb3zOINClJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBj b3JlLXJlaW52aXRlLTA0OiBwcmVjb25kaXRpb24NCg0KDQoNCg0KDQoNCkF0IDEyOjA0IEFNIDYv NC8yMDEwLCBnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZToNCg0KDQo+ID4gSSBoYXZlIHRob3Vn aHQgYWJvdXQgYSBwcmVjb25kaXRpb24gYXMgYmVsb3c6DQo+ID4gV2hlbiBVQXMgdXNlIGEgcHJl Y29uZGl0aW9uLCBhbGwgU0RQIGhhdmUgcHJlY29uZGl0aW9uDQo+ID4gYXR0cmlidXRlcyBhbmQg YWxsIFVQREFURSBhcmUgY2VydGFpbmx5IGJlbG9uZyB0byBhbnkgb25lIG9mDQo+ID4gSU5WSVRF IHRyYW5zYWN0aW9uLg0KPiA+DQo+ID4gQnV0IGlmIGEgVUEgY2FuIHNlbmQgYW4gVVBEQVRFIHdp dGhvdXQgYSBwcmVjb25kaXRpb24sDQo+ID4gaXQgc2VlbXMgdG8gYmUgYW1iaWd1b3VzIHdoZXRo ZXIgdGhlIFVQREFURSBvY2N1cnMgd2l0aGluIGFuDQo+ID4gSU5WSVRFIHRyYW5zYWN0aW9uLg0K Pg0KPlVQREFURSBhbmQgSU5WSVRFIGFyZSB0d28gdHJhbnNhY3Rpb25zLg0KDQpidXQgd2l0aGlu IHRoZSBzYW1lIGRpYWxvZw0KDQoNCj4gPg0KPiA+IEFuZCB5b3VyIGV4cGxhbmF0aW9ucyBzZWVt IHRvIGJlIGEgbmV3IHVzYWdlIG9mIGEgcHJlY29uZGl0aW9uLg0KPg0KPg0KPg0KPg0KPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+WlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIA0KPm1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCANCj5jb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBp ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIA0KPnRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyANCj5vZiB0aGlzIGNv bW11bmljYXRpb24gdG8gb3RoZXJzLg0KPlRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KPmludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IA0KPmFyZSBh ZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IA0KPm5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIA0KPm1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ci4NCj5UaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBi eSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+c2lwY29yZSBtYWlsaW5nIGxpc3QNCj5zaXBjb3JlQGll dGYub3JnaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg0K DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kg YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNv bW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3Nl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRo aXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3Bh bSBzeXN0ZW0uDQo= --=_alternative 00057C734825773C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi8vSSBvbmNlIHNlbnQgdGhlIG1h aWwgYXQgd2Vla2VuZCwgYnV0DQp0aGUgTUwgZGlkbid0IGRpc3BhdGNoIHRoZSBtYWlsLiBTbywg SSBhbSByZXNlbmRpbmcgaXQgbm93LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+VGhlIHBvaW50IGhlcmUgaXMgd2hldGhlciB0aGlzIG1vZGlmaWNhdGlv bg0KKmluIHVzZSogb3Igbm90LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+dGhlIHVzZSBjYXNlIHRhbGtlZCBoZXJlIGlzIGFib3V0IHNlc3Npb24NCm1v ZGlmaWNhdGlvbiB3aXRoIHByZWNvbmRpdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIHRoZSBtb2RpZmljYXRpb24gKmluIHVzZSosIHRoZSBV QVMNCnNob3VsZCBzZW5kIDJ4eCB0byB0aGlzIFJlLUlOVklURS48L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIHlvdSB0aGluayB0aGVyZSdz IHNvbWV0aGluZyBub3QgY2xlYXIsDQpmZWVsIGZyZWUgdG8gY29tbWVudC48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbyA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZu YnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8 YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzQlPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtKYW1lcyBNLiBQb2xrJnF1b3Q7DQombHQ7am1wb2xrQGNp c2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4yMDEwLTA2LTA1IDAzOjMwPC9mb250Pg0KPHRkIHdpZHRoPTY1JT4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPmdhby55YW5nMkB6dGUuY29tLmNuLCBPS1VNVVJBIFNoaW5qaQ0K Jmx0O3NoaW5qaS5va3VtdXJhQHNvZnRmcm9udC5qcCZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O3NpcGNvcmVAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0w NDoNCnByZWNvbmRpdGlvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+QXQgMTI6MDQgQU0gNi80LzIwMTAsIGdhby55YW5nMkB6dGUuY29t LmNuIHdyb3RlOjxicj4NCjxicj4NCjxicj4NCiZndDsgJmd0OyBJIGhhdmUgdGhvdWdodCBhYm91 dCBhIHByZWNvbmRpdGlvbiBhcyBiZWxvdzo8YnI+DQomZ3Q7ICZndDsgV2hlbiBVQXMgdXNlIGEg cHJlY29uZGl0aW9uLCBhbGwgU0RQIGhhdmUgcHJlY29uZGl0aW9uPGJyPg0KJmd0OyAmZ3Q7IGF0 dHJpYnV0ZXMgYW5kIGFsbCBVUERBVEUgYXJlIGNlcnRhaW5seSBiZWxvbmcgdG8gYW55IG9uZSBv Zjxicj4NCiZndDsgJmd0OyBJTlZJVEUgdHJhbnNhY3Rpb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEJ1dCBpZiBhIFVBIGNhbiBzZW5kIGFuIFVQREFURSB3aXRob3V0IGEgcHJlY29u ZGl0aW9uLDxicj4NCiZndDsgJmd0OyBpdCBzZWVtcyB0byBiZSBhbWJpZ3VvdXMgd2hldGhlciB0 aGUgVVBEQVRFIG9jY3VycyB3aXRoaW4gYW48YnI+DQomZ3Q7ICZndDsgSU5WSVRFIHRyYW5zYWN0 aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7VVBEQVRFIGFuZCBJTlZJVEUgYXJlIHR3byB0cmFuc2Fj dGlvbnMuPGJyPg0KPGJyPg0KYnV0IHdpdGhpbiB0aGUgc2FtZSBkaWFsb2c8YnI+DQo8YnI+DQo8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQW5kIHlvdXIgZXhwbGFuYXRpb25zIHNlZW0g dG8gYmUgYSBuZXcgdXNhZ2Ugb2YgYSBwcmVjb25kaXRpb24uPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDtaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCjxicj4NCiZn dDttYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgPGJyPg0KJmd0O2NvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQNCjxicj4NCiZndDt0byBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMNCjxicj4N CiZndDtvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLjxicj4NCiZndDtUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCA8 YnI+DQomZ3Q7aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aG9tIHRoZXkNCjxicj4NCiZndDthcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSA8YnI+DQomZ3Q7bm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg PGJyPg0KJmd0O21lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci48YnI+ DQomZ3Q7VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbQ0Kc3lzdGVtLjxicj4NCiZndDs8YnI+DQomZ3Q7X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7c2lwY29yZSBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7c2lwY29yZUBpZXRmLm9yZ2h0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05v dGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5i c3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5i c3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJz cDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRl ZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5i c3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNw O2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5i c3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMm bmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVu dGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhl Jm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtl bnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2Vk LiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNw O2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3Ro ZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55 Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdl Jm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJz cDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2Fu bmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNw O1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00057C734825773C_=-- From wwwrun@core3.amsl.com Tue Jun 8 06:51:18 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CB25928C1C7; Tue, 8 Jun 2010 06:51:18 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100608135118.CB25928C1C7@core3.amsl.com> Date: Tue, 8 Jun 2010 06:51:18 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] Last Call: draft-ietf-sipcore-invfix (Correct transaction handling for 2xx responses to Session Initiation Protocol (SIP) INVITE requests) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 13:51:18 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Correct transaction handling for 2xx responses to Session Initiation Protocol (SIP) INVITE requests ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipcore-invfix-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19051&rfc_flag=0 From gao.yang2@zte.com.cn Tue Jun 8 23:20:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08803A6820 for ; Tue, 8 Jun 2010 23:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.038 X-Spam-Level: X-Spam-Status: No, score=-98.038 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_73=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f6oELcvgy4N for ; Tue, 8 Jun 2010 23:20:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1E56B3A681D for ; Tue, 8 Jun 2010 23:20:27 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 552341727820181; Wed, 9 Jun 2010 14:20:21 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 55465.4786316380; Wed, 9 Jun 2010 14:14:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o596JaLI014970; Wed, 9 Jun 2010 14:19:49 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C0D22C6.8090002@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 9 Jun 2010 14:16:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-09 14:19:40, Serialize complete at 2010-06-09 14:19:40 Content-Type: multipart/alternative; boundary="=_alternative 0022B6014825773D_=" X-MAIL: mse2.zte.com.cn o596JaLI014970 Cc: SIPCORE Subject: Re: [sipcore] Fwd: Clarifications on draft-ietf-sipcore-reinvite-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 06:20:29 -0000 This is a multipart message in MIME format. --=_alternative 0022B6014825773D_= Content-Type: text/plain; charset="US-ASCII" Hi Paul, > > The problem with this approach was that rules were getting too complex. > > So, we decided to follow the KISS principle and provide simpler rules. > > The idea was to come up with a relatively simple rule that may cause > > false positives but would be simple to implement (and understand). > > This seems reasonable, especially since such glare situations are rare > in the first place. Yes. And I have the same point here. > > The advantage of this approach is that it is relatively simple. The > > disadvantage is that there are false positives (e.g., maybe the UPDATEs > > in the example above were not negotiating parameters but simply > > communicating the value of a non-negotiable parameter to the other end). > > I think the case is good wrt two *negotiable* pieces of state, such as > sdp and session-timer. Not so good wrt non-negotiable state. I guess we can do it as your suggestion. Or do it like this: To use a separate text do the clarfication for session timer along the basic concept clarified in "Re-INVITE Handling" text. I think any one of the two ways is OK, so I have no incline here:) > IMO that will go a long way to sorting this out. The "treat as if the > update had an offer" has proven to leave many questions open to further > interpretation. > > Among other things, 3261 and 3311 address offer/answer glare, and only > incidentally glare between messages. There is no real addressing of > invite-update glare. Of course the o/a draft has worked to clarify that. > We will have to now decide whether to put more specificity into the > reinvite draft, or to just put some basics there and elaborate in the > o/a draft. Yes. I think to shift the glare discussion in one text is a nice suggestion. As glare cases are rare(as mentioned above) and "Glare Handling" is topic might need a relative long way to sorting it out, we can remove it from "Re-INVITE Handling"'s basic concept(the *in use* concept and which kind of final response should be returned by UAS) and make "Re-INVITE Handling" go on. O/A draft is a choice as the container for the "Glare Handling" part. But there are two things need be evaluated: 1. "Glare Handling" has content beyond pure O/A handling. (Suggestion about this point: modify current O/A text's name as "O/A and Glare Handling"). 2. "Glare Handling" is *once* aimed for normative text. (Suggestion about this point: we can do the "Glare Handling" as informational at first, then someday normative.) Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0022B6014825773D_= Content-Type: text/html; charset="US-ASCII"
Hi Paul,

> > The problem with this approach was that rules were getting too complex.
> > So, we decided to follow the KISS principle and provide simpler rules.
> > The idea was to come up with a relatively simple rule that may cause
> > false positives but would be simple to implement (and understand).
>
> This seems reasonable, especially since such glare situations are rare
> in the first place.

Yes. And I have the same point here.

> > The advantage of this approach is that it is relatively simple. The
> > disadvantage is that there are false positives (e.g., maybe the UPDATEs
> > in the example above were not negotiating parameters but simply
> > communicating the value of a non-negotiable parameter to the other end).
>
> I think the case is good wrt two *negotiable* pieces of state, such as
> sdp and session-timer. Not so good wrt non-negotiable state.

I guess we can do it as your suggestion.

Or do it like this:
To use a separate text do the clarfication for session timer along the basic concept clarified in "Re-INVITE Handling" text.

I think any one of the two ways is OK, so I have no incline here:)

> IMO that will go a long way to sorting this out. The "treat as if the
> update had an offer" has proven to leave many questions open to further
> interpretation.
>
> Among other things, 3261 and 3311 address offer/answer glare, and only
> incidentally glare between messages. There is no real addressing of
> invite-update glare. Of course the o/a draft has worked to clarify that.
> We will have to now decide whether to put more specificity into the
> reinvite draft, or to just put some basics there and elaborate in the
> o/a draft.

Yes. I think to shift the glare discussion in one text is a nice suggestion.

As glare cases are rare(as mentioned above) and "Glare Handling" is topic might need a relative long way to sorting it out, we can remove it from "Re-INVITE Handling"'s basic concept(the *in use* concept and which kind of final response should be returned by UAS) and make "Re-INVITE Handling" go on.

O/A draft is a choice as the container for the "Glare Handling" part. But there are two things need be evaluated:
1. "Glare Handling" has content beyond pure O/A handling. (Suggestion about this point: modify current O/A text's name as "O/A and Glare Handling").
2. "Glare Handling" is *once* aimed for normative text. (Suggestion about this point: we can do the "Glare Handling" as informational at first, then someday normative.)

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0022B6014825773D_=-- From brett@broadsoft.com Thu Jun 10 10:44:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858D228C15A for ; Thu, 10 Jun 2010 10:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtPHk1lmR9i2 for ; Thu, 10 Jun 2010 10:44:38 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 9CFFF28C10D for ; Thu, 10 Jun 2010 10:44:38 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Thu, 10 Jun 2010 10:44:40 -0700 From: Brett Tate To: Gonzalo Camarillo , SIPCORE Date: Thu, 10 Jun 2010 10:43:31 -0700 Thread-Topic: [sipcore] Fwd: Clarifications on draft-ietf-sipcore-reinvite-04.txt Thread-Index: AcsGVAxemQLyZnZFTvCADwwdVOsaOQCS02FQ Message-ID: <747A6506A991724FB09B129B79D5FEB61493E55A0D@EXMBXCLUS01.citservers.local> References: <4C0BB658.4080705@ericsson.com> In-Reply-To: <4C0BB658.4080705@ericsson.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: [sipcore] Fwd: Clarifications on draft-ietf-sipcore-reinvite-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:44:39 -0000 > If people can think of situations were the new rules=20 > cause false positives that are *really* problematic, we=20 > could look at them. However, let's all keep in mind the=20 > KISS principle. It is way too easy to come up with very=20 > complicated rules that only give us small gains when=20 > compared with the simpler rules in this area. It looks like (not sure) the clarification is the same as how I was interpr= eting the draft. More specifically, an UPDATE without SDP sent over an ear= ly dialog which has not completed the INVITE's offer/answer exchange will r= esult in a 491 or 500 instead of 200. If this is true, it has the followin= g problems. 1) Solution does not address INFO, REFER, NOTIFY, and etcetera. Thus if th= e UPDATE fix is too restrictive, vendors will likely start using other meth= ods (when valid) to update parameters or perform a ping on the early dialog= . This can be good or bad depending upon if you want vendors to start usin= g INFO or define something like UPDATELITE as a workaround for those not wi= lling or able to complete the offer/answer exchange on an early dialog so U= PDATE can be used. 2) If caller's device is compliant and called party's device is not, reject= ing called party's UPDATE (without SDP) with 491 can lead to numerous retri= es over the early dialog. The 491 triggered retry interval would be 0-2 se= conds. 3) The work-arounds mentioned within 1 are not possible for some headers (l= ike Contact and Session-Expires). Thus the work-arounds might be more dras= tic. For instance, it might require using things like REFER. I didn't not= ice if the draft actually clarifies rfc3261 concerning if an INVITE's 18x a= nd 2xx response with different Contact can "update" a target during call se= tup. The clarification was requested within http://www.ietf.org/mail-archive/web/sipcore/current/msg01472.html=20 > In any case, I will probably clarify the text in the=20 > draft so that it is clearer in which situations the=20 > glare rules are to be applied. Right now, the draft=20 > references RFC 3261 and RFC 3311 but adding informative > descriptions to the draft would probably make it easier=20 > to understand. Since I'm still not positive how to interpret the draft, I definitely would= like to see the draft updated. =20 Similarly if the draft updates RFC 3311, the draft should indicate that it = is updating RFC 3311. From rjsparks@nostrum.com Thu Jun 10 13:14:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5633A6768 for ; Thu, 10 Jun 2010 13:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJWpoumhOmn1 for ; Thu, 10 Jun 2010 13:14:29 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3F2173A659A for ; Thu, 10 Jun 2010 13:14:29 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-46-227.dllstx.fios.verizon.net [173.71.46.227]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5AKETur074050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 10 Jun 2010 15:14:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jun 2010 15:14:29 -0500 Message-Id: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Received-SPF: pass (nostrum.com: 173.71.46.227 is authenticated by a trusted mechanism) Subject: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 20:14:31 -0000 Summary: This draft has a few adjustments that are needed before moving = it into IETF Last Call. Major question: Why isn't this an Update to 3265? Is there text here that prevents a = subscriber from generating Event headers in 200 OKs to NOTIFYs mid-subscription = (when he didn't probe for support using the SUBSCRIBE?) How would they know the = request got honored? The possibility of running into implementations that break = should be called out. 4.2 indicates the subscriber only gets a "hint" about = support for rate-control in the notifier - is the condition it describes really = only a hint? In several places, the notifier is given permission to adjust an = interval based on local policy. The document should be explicit about allowing the = adjustment in any direction (increasing or decreasing) since there are so many = other uses of intervals in SIP and SIP Events that allow adjustment only in one = direction. A few places I noted when reading the document were the Note in REQ7, = 4.3 4th paragraph, 5.2 paragraph 3, 6.2 paragraph 3. The last paragraph of section 3.6 claims "exactly the same properties" = except for being generated constrained to a schedule. Can you clarify which = properties you mean? Many properties of the notifications beside their timing are = clearly different (for instance, you may miss state transitions). The security considerations section deserves more text:=20 * What is the forward reference from section 3.4 supposed to be pointing = to? * Call out the implications on a Notifier having to store/aggregate = partial state * Note that the Event header (particularly in 200 OKs) is not integrity = protected.=20 This would allow anything that could modify the message in flight (or = an=20 eavesdropper that could race a 200 OK in) to suppress (or flood) = notifications=20 without the subscriber seeing what caused it. The assertion that applying rate limiting and compression together = results in savings as good as the sum of applying them independently should be = supported or adjusted. I think it's sufficient to say they can be applied = together. Below are several suggestions for text tweaks. The first few (staring = with *) are the most important.=20 * Section 3.2 paragraph 4: suggest replacing "does not typically" with = "may not" * Section 3.2 last paragraph: The sentence 'The "max-interval" parameter=20= indicates ... complete state information' is difficult to parse. = Could it be simplified? * Section 4.3 first paragraph, last sentence: "For such cases" is = ambiguous. Suggest "If the min-interval value is greater than the subscription = expiry". * Section 6.2 last paragraph: This currently says the timeout mechanism = does not affect when 3261 transaction retransmissions are generated. It = should also explicitly note that retransmissions do not affect the = calculation of the next timeout. Introduction, paragraph 2: suggest replacing "congestion" with "load" Section 3.1 paragraph 3: suggest replacing "amount of traffic" with=20 "number of notifications" Section 3.5 paragraph 1: Suggest a reference for RLS after "list = subscription". The sentence "Moreover, the list event notifier..." should be more = explicit about using the rate mechanism for any back-end subscriptions it might = have. Suggest referencing 3261 in the last paragraph of 4.2 Section 4.3, 3rd paragraph last sentence. The only way the subscriber = _can_ resume notifications is to renew the subscription with a resubscribe = request. Would this text work? "This results in receiving no further = notifications until the subscription expires or the subscriber sends a SUBSCRIBE request = refreshing the subscription (perhaps resuming notifications)". The text needs to be adjusted to reflect subnot-etags being issued as an = RFC Adam suggested some RFC-Editor notes in the proto writeup (which may = address some of the above comments). Please be sure to incorporate those when = revising the draft. One last question: If the combination of min-interval, max-interval, and average-interval = make little sense, why does the document allow them to be combined? I think = what the group was trying to say is that we currently don't forsee a use for = combining those options, but do not wish to forbid their combination. From andrew.hutton@siemens-enterprise.com Fri Jun 11 03:05:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A594E28C161 for ; Fri, 11 Jun 2010 03:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFmisHiT8srq for ; Fri, 11 Jun 2010 03:05:41 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 110083A68B5 for ; Fri, 11 Jun 2010 03:05:40 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-477981; Fri, 11 Jun 2010 12:05:42 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 626751EB82B0; Fri, 11 Jun 2010 12:05:42 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 11 Jun 2010 12:05:42 +0200 From: "Hutton, Andrew" To: Brett Tate , Gonzalo Camarillo , SIPCORE Date: Fri, 11 Jun 2010 12:05:40 +0200 Thread-Topic: [sipcore] Fwd: Clarifications on draft-ietf-sipcore-reinvite-04.txt Thread-Index: AcsGVAxemQLyZnZFTvCADwwdVOsaOQCS02FQACtCEtA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3070DC24FAC@MCHP058A.global-ad.net> References: <4C0BB658.4080705@ericsson.com> <747A6506A991724FB09B129B79D5FEB61493E55A0D@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61493E55A0D@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: [sipcore] Fwd: Clarifications on draft-ietf-sipcore-reinvite-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 10:05:42 -0000 I tend to agree with Brett's argument below and would be concerned about th= e consequences for interoperability if UA's start rejecting UPDATE's withou= t SDP due to this draft. This would probably cause problems for some existi= ng deployments and workarounds would have to be found. Regards Andy =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: 10 June 2010 18:44 > To: Gonzalo Camarillo; SIPCORE > Subject: Re: [sipcore] Fwd: Clarifications on=20 > draft-ietf-sipcore-reinvite-04.txt >=20 > > If people can think of situations were the new rules=20 > > cause false positives that are *really* problematic, we=20 > > could look at them. However, let's all keep in mind the=20 > > KISS principle. It is way too easy to come up with very=20 > > complicated rules that only give us small gains when=20 > > compared with the simpler rules in this area. >=20 > It looks like (not sure) the clarification is the same as how=20 > I was interpreting the draft. More specifically, an UPDATE=20 > without SDP sent over an early dialog which has not completed=20 > the INVITE's offer/answer exchange will result in a 491 or=20 > 500 instead of 200. If this is true, it has the following problems. >=20 > 1) Solution does not address INFO, REFER, NOTIFY, and=20 > etcetera. Thus if the UPDATE fix is too restrictive, vendors=20 > will likely start using other methods (when valid) to update=20 > parameters or perform a ping on the early dialog. This can=20 > be good or bad depending upon if you want vendors to start=20 > using INFO or define something like UPDATELITE as a=20 > workaround for those not willing or able to complete the=20 > offer/answer exchange on an early dialog so UPDATE can be used. >=20 > 2) If caller's device is compliant and called party's device=20 > is not, rejecting called party's UPDATE (without SDP) with=20 > 491 can lead to numerous retries over the early dialog. The=20 > 491 triggered retry interval would be 0-2 seconds. >=20 > 3) The work-arounds mentioned within 1 are not possible for=20 > some headers (like Contact and Session-Expires). Thus the=20 > work-arounds might be more drastic. For instance, it might=20 > require using things like REFER. I didn't notice if the=20 > draft actually clarifies rfc3261 concerning if an INVITE's=20 > 18x and 2xx response with different Contact can "update" a=20 > target during call setup. The clarification was requested within > http://www.ietf.org/mail-archive/web/sipcore/current/msg01472.html=20 >=20 >=20 > > In any case, I will probably clarify the text in the=20 > > draft so that it is clearer in which situations the=20 > > glare rules are to be applied. Right now, the draft=20 > > references RFC 3261 and RFC 3311 but adding informative > > descriptions to the draft would probably make it easier=20 > > to understand. >=20 > Since I'm still not positive how to interpret the draft, I=20 > definitely would like to see the draft updated. =20 >=20 > Similarly if the draft updates RFC 3311, the draft should=20 > indicate that it is updating RFC 3311. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From shinji.okumura@softfront.jp Fri Jun 11 08:09:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E2628C11A for ; Fri, 11 Jun 2010 08:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.268 X-Spam-Level: X-Spam-Status: No, score=-95.268 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QNyORIh6bvO for ; Fri, 11 Jun 2010 08:09:06 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 158BC28C10F for ; Fri, 11 Jun 2010 08:09:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 8332742801B; Sat, 12 Jun 2010 00:09:06 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njwsxDJCuH4B; Sat, 12 Jun 2010 00:09:04 +0900 (JST) Received: from softfront.jp (123.230.193.179.er.eaccess.ne.jp [123.230.193.179]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id A78E442801A; Sat, 12 Jun 2010 00:09:03 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Sat, 12 Jun 2010 00:09:02 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: <4C0D22C6.8090002@cisco.com> References: <4C0BB658.4080705@ericsson.com> <4C0D22C6.8090002@cisco.com> Message-Id: <9BCB097806BD03shinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] Fwd: Clarifications ondraft-ietf-sipcore-reinvite-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 15:09:07 -0000 Hi, In any cases, IMO an interworking of an UPDATE and a 4xx to a reINVITE should be described more concretely. Here is the rules that I think. UAC behavior for an error response to a reINVITE. 1. In the following cases, a UA should generate a new offer request in order to synchronize a common view of both UAs. a. The UA receives an error response to a re-INVITE, and any offer-answer exchanges by using an UPDATE transaction have already completed. b. The UAC sends an UPDATE request with an offer, and receives an error response to the re-INVITE and a following 2xx response to the UPDATE request. 2. If The UA receive another offer request before sending an own offer request, the UA may accept the UPDATE and then the UA may not send the own offer request. UAS behavior for an error response to a reINVITE. 1. It is recommended that a UAS return a 2xx response to a re-INVITE request. 2. If the UAS return an error response to the re-INVITE, the UA may accept an new offer request before receiving an ACK. 3. If the UAS sends an UPDATE with an offer and a following error response to the reINVITE, and receives a 2xx to the UPDATE, then the offer-answer state is not rolled back. To put it another way, it is assumed that the offer-answer state doesn't belong to the re-INVITE. At present, I think that these rules are a minimum set. And following figures are main puzzles and the answers. A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| non-2xx|s1 |<------------------------------|<-+ s0|ACK ACK |s0| |------------> ----------->| | accept UPDATE | | v A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| non-2xx|s1 | /---------------|<-+ |UPD(offer2) / |s0| |=============/================>| | accept UPDATE | / 2xx-UPD(answer2)| | |<==========/===================| | s2| / |s2| |<--------/ ----------->| | s0|ACK | | |-------------> | | |UPD(offer0) | | |==============================>| | | 2xx-UPD(answer0)| | |<==============================| | s0| |s0| | | v A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| UPD(offer2)|s1 | /============| | / non-2xx| |<---------------/--------------|<-+ s0|ACK / ACK |s0| |------------> / ----------->| | accept UPDATE | / | | |<===========/ | | |2xx-UPD(answer2) | | |==============================>| | s2| |s2| | | v A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| non-2xx|s1 | /------------|<-+ | / ACK |s0| | / ---------->| | accept UPDATE | / UPD(offer2)| | |<=============/================| | |2xx(answer2) / | | |============/=================>| | s2| / |s2| |<---------/ | | s0|ACK | | |-----------> | | |UPD(offer0) | | |==============================>| | | 2xx-UPD(answer0)| | |<==============================| | s0| |s0| | | v A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|UPD(offer2) |s1 |==============================>| | 2xx(answer2)| | /============| | / non-2xx|s2 |<---------------/--------------|<-+ s0|ACK / ACK |s0| |-------> / ------->| | accept UPDATE | / | | |<===========/ | | s2|UPD(offer0) | | |==============================>| | | 2xx-UPD(answer0)| | |<==============================| | s0| |s0| | | v >Gonzalo, > >Thank you for clarification. More inline. > >Gonzalo Camarillo wrote: >> Resending, since the mailing list seemed to be down yesterday. >> >> -------- Original Message -------- >> Subject: Clarifications on draft-ietf-sipcore-reinvite-04.txt >> Date: Sat, 05 Jun 2010 11:57:46 +0300 >> From: Gonzalo Camarillo >> To: SIPCORE >> >> Hi, >> >> there have been many emails on the glare situations described in: >> >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-reinvite/ >> >> I have been asked to clarify the meaning of Sections 3.5 and 4.5 of the >> draft. >> >> As the draft indicates, there are glare situations that were not covered >> by earlier RFCs such as RFC 3261 and RFC 3311. This draft covers those >> situations. In the beginning, we started working on glare detection and >> avoidance rules that were as little restrictive as possible. That is, we >> tried to minimize false positives (i.e., the rules tell you there is a >> glare when there really is no glare). Such rules would need to analyze >> the messages involved in a given race condition and decide if the >> endpoints could end up with different views on the value of any of all >> the parameters involved in the SIP dialog and its related session. >> >> The problem with this approach was that rules were getting too complex. >> So, we decided to follow the KISS principle and provide simpler rules. >> The idea was to come up with a relatively simple rule that may cause >> false positives but would be simple to implement (and understand). > >This seems reasonable, especially since such glare situations are rare >in the first place. I like KISS too. But unfortunately glare-related rules are not simple. Regards, Shinji >> SIP already had glare-related rules. When sending or receiving a message >> with an offer or an answer, UAs use those rules to decide whether or not >> the outgoing message can be sent at that point and how to respond to the >> incoming message. So, we decided to use the already existing rules, >> which deal with glares related to offer/answer exchanges and modify them >> so that, when using them, UPDATEs were always treated as if they >> contained an offer. >> >> For example, RFC 3311 says: >> >> "If an UPDATE is received that contains an offer, and the UAS has >> generated an offer (in an UPDATE, PRACK or INVITE) to which it has >> not yet received an answer, the UAS MUST reject the UPDATE with a 491 >> response." >> >> Before draft-ietf-sipcore-reinvite-04.txt, if a UA sent an UPDATE and >> before receiving a 200 for it, the UA received an UPDATE from the remote >> end, it would not have been considered a glare if either of the UPDATEs >> did not contain an offer. However, those offerless UPDATEs could be >> changing non-offer/answer parameters. Consequently, the UAs may end up >> with different views on the values of those parameters. >> Draft-ietf-sipcore-reinvite-04.txt treats this scenario as glare to keep >> the UAs from getting out of synch. > >> The advantage of this approach is that it is relatively simple. The >> disadvantage is that there are false positives (e.g., maybe the UPDATEs >> in the example above were not negotiating parameters but simply >> communicating the value of a non-negotiable parameter to the other end). > >I think the case is good wrt two *negotiable* pieces of state, such as >sdp and session-timer. Not so good wrt non-negotiable state. > >> If people can think of situations were the new rules cause false >> positives that are *really* problematic, we could look at them. However, >> let's all keep in mind the KISS principle. It is way too easy to come up >> with very complicated rules that only give us small gains when compared >> with the simpler rules in this area. > >ISTM that when non-negotiable info is concerned the situation is >different. These don't conflict. There are a couple of those sorts of >things (I don't know how many others there might be) that have come up >for discussion: >- called party identity >- remote target > >In the case of called party identity, it might be harmless to lump it in >with the glare cases, even though it really isn't one. > >But in the case of remote target, if the sender has lost its old address >there is only one chance to fix it. Perhaps the probability losing an >address and getting glare while trying to update it is so low that we >don't care about it failing. I'm willing to entertain that, as long as >we all recognize that is what we are doing. > >> In any case, I will probably clarify the text in the draft so that it is >> clearer in which situations the glare rules are to be applied. Right >> now, the draft references RFC 3261 and RFC 3311 but adding informative >> descriptions to the draft would probably make it easier to understand. > >IMO that will go a long way to sorting this out. The "treat as if the >update had an offer" has proven to leave many questions open to further >interpretation. > >Among other things, 3261 and 3311 address offer/answer glare, and only >incidentally glare between messages. There is no real addressing of >invite-update glare. Of course the o/a draft has worked to clarify that. >We will have to now decide whether to put more specificity into the >reinvite draft, or to just put some basics there and elaborate in the >o/a draft. From jgunn6@csc.com Fri Jun 11 08:43:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A940F3A68A7; Fri, 11 Jun 2010 08:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoWW8+o320Ty; Fri, 11 Jun 2010 08:43:33 -0700 (PDT) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 681273A685A; Fri, 11 Jun 2010 08:43:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-3.tower-164.messagelabs.com!1276271014!18838307!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 9422 invoked from network); 11 Jun 2010 15:43:34 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-3.tower-164.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Jun 2010 15:43:34 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o5BFhWCC014906; Fri, 11 Jun 2010 11:43:33 -0400 In-Reply-To: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> To: Robert Sparks MIME-Version: 1.0 X-KeepSent: 4F5824FD:1BDC5FCA-8525773F:0055F2E4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Fri, 11 Jun 2010 11:43:28 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF293|April 16, 2010) at 06/11/2010 11:44:10 AM, Serialize complete at 06/11/2010 11:44:10 AM Content-Type: multipart/alternative; boundary="=_alternative 0056612F8525773F_=" Cc: SIPCORE , sipcore-bounces@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 15:43:35 -0000 This is a multipart message in MIME format. --=_alternative 0056612F8525773F_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBoYXZlIHNvbWUgZnVydGhlciBjb21tZW50cywgbW9zdGx5IGFib3V0IHRoZSAiYXZlcmFnZSIg bWVjaGFuaXNtLg0KDQpXaGlsZSDigJxtYXgtaW50ZXJ2YWzigJ0gaXMgc3lub255bW91cyB3aXRo IOKAnG1pbmltdW0gcmF0ZeKAnSwgYW5kIOKAnG1pbi1pbnRlcnZhbOKAnSANCmlzIHN5bm9ueW1v dXMgd2l0aCDigJxtYXhpbXVtIHJhdGXigJ0sIHRoZSBjb25zdGFudCBzd2l0Y2hpbmcgYmFjayBh bmQgZm9ydGggDQpiZXR3ZWVuIHRoZSB0d28gc2V0cyBvZiB0ZXJtaW5vbG9neSBtYWtlcyBpdCB2 ZXJ5IGRpZmZpY3VsdCB0byBmb2xsb3cuDQoNClBpY2sgb25lIHNldCwgYW5kIHVzZSB0aGF0IGFz IHRoZSBkb21pbmFudCB0ZXJtLiAgQXQgYSBtaW5pbXVtLCB0aGUgDQpzZWN0aW9uIGhlYWRpbmcg c2hvdWxkIGJlIGNvbnNpc3RlbnQuDQoNClRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgaW50ZW5kZWQg ZWZmZWN0IG9mIHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCdIGlzIA0KdW5jbGVhciBhbmQgaW5j b25zaXN0ZW50Lg0KDQpJbiB0aGUgaW50cm9kdWN0aW9uLCBpdCBzYXlzIA0K4oCcICAgYXZlcmFn ZS1pbnRlcnZhbDogIHNwZWNpZmllcyBhbiBhdmVyYWdlIGNhZGVuY2UgYXQgd2hpY2ggbm90aWZp Y2F0aW9ucyANCmFyZSBkZXNpcmVkLCBpbiBzZWNvbmRzLuKAnQ0KDQpUaGlzIGltcGxpZXMgdGhh dCBpdCB3aWxsIHNwZWVkIHVwIHRoZSByYXRlIG9mIG5vdGlmaWNhdGlvbnMgd2hlbiB0aGV5IA0K d291bGQgb3RoZXJ3aXNlIGJlIHRvbyBzbG93LCBhbmQgc2xvdyB0aGVtIGRvd24gd2hlbiB0aGV5 IHdvdWxkIG90aGVyd2lzZSANCmJlIHRvbyBxdWljay4NCg0KTGF0ZXIgaW4gdGhlIGludHJvIGl0 IHNheXMgDQrigJxBbGwgdGhvc2UgbWVjaGFuaXNtcyBhcmUgc2ltcGx5IHRpbWVyIHZhbHVlcyB0 aGF0IGluZGljYXRlcyAoc2ljKSB0aGUgDQptaW5pbXVtLCBtYXhpbXVtIGFuZCBhdmVyYWdlIHRp bWUgcGVyaW9kIGFsbG93ZWQgYmV0d2VlbiB0d28gDQpub3RpZmljYXRpb25zLiBBcyBhIHJlc3Vs dCBvZiB0aG9zZSBtZWNoYW5pc20sIGEgY29tcGxpYW50IG5vdGlmaWVyIHdpbGwgDQphZGp1c3Qg dGhlIHJhdGUgYXQgd2hpY2ggaXQgZ2VuZXJhdGVzIG5vdGlmaWNhdGlvbnMu4oCdDQoNClRoaXMg YWxzbyBpbXBsaWVzIHRoYXQgdGhlIOKAnGF2ZXJhZ2UtaW50ZXJ2YWzigJ0gbWVjaGFuaXNtIHdp bGwgYm90aCBzcGVlZCB1cCANCmFuZCBzbG93IGRvd24gdGhlIHJhdGUsIGFzIGFwcHJvcHJpYXRl Lg0KDQpJbiBzZWN0aW9uIDMuMywgVXNlIENhc2UgZm9yIHNwZWNpZnlpbmcgdGhlIGF2ZXJhZ2Ug cmF0ZSBvZiBub3RpZmljYXRpb25zLCANCml0IGlzIGNvbnRyYWRpY3RvcnkuICBGaXJzdCBpdCBz YXlzDQrigJxkeW5hbWljYWxseSBpbmNyZWFzZXMgdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZp Y2F0aW9ucyBpZiB0aGUgdGFyZ2V0IA0KaGFzIHNlbnQgb3V0IHNldmVyYWwgbm90aWZpY2F0aW9u cyByZWNlbnRseS7igJ0gIFRoaXMgaXMgYW4gSU5DUkVBU0UgaW4gdGhlIA0KaW50ZXJ2YWwNCg0K QnV0IHRoZW4gaXQgc2F5cw0K4oCcVGhlICJhdmVyYWdlLWludGVydmFsIiBwYXJhbWV0ZXIgdmFs dWUgaXMgdXNlZCBieSB0aGUgbm90aWZpZXIgdG8gDQpkeW5hbWljYWxseSBjYWxjdWxhdGUgdGhl IG1heGltdW0gdGltZSBhbGxvd2VkIGJldHdlZW4gdHdvIHN1YnNjcmlwdGlvbnMgDQooc2ljKS7i gJ0NCkZpcnN0LCBJIGFzc3VtZSB5b3UgbWVhbiDigJxiZXR3ZWVuIHR3byBub3RpZmljYXRpb25z 4oCdLiBOb3Qg4oCcYmV0d2VlbiB0d28gDQpzdWJzY3JpcHRpb25z4oCdLiAgQnV0IG1vcmUgaW1w b3J0YW50bHksIGR5bmFtaWNhbGx5IGNhbGN1bGF0aW5nIOKAnHRoZSANCm1heGltdW0gdGltZSBh bGxvd2VkIGJldHdlZW4gbm90aWZpY2F0aW9uc+KAnSBtZWFucyB0aGF0IHlvdSB3aWxsIERFQ1JF QVNFIA0KdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucywgaWYgdGhlIHRhcmdldCBo YXMgbm90IHNlbnQgb3V0IGFueSANCm5vdGlmaWNhdGlvbnMgcmVjZW50bHkuDQoNCkFuZCBmdXJ0 aGVyDQrigJxUaGlzIHR5cGUgb2YgcmF0ZSBjb250cm9sIGFsbG93cyB0aGUgbm90aWZpZXIgdG8g ZHluYW1pY2FsbHkgaW5jcmVhc2Ugb3IgDQpkZWNyZWFzZSB0aGUgTm90aWZpY2F0aW9uIGZyZXF1 ZW5jeS7igJ0NCg0KV2hlbiB3ZSBnZXQgdG8gc2VjdGlvbiA2IChPcGVyYXRpb24gb2YgdGhlIGF2 ZXJhZ2UgcmF0ZSBtZWNoYW5pc20pLCBpdCANCnN0YXJ0cyBvZmYgYnkgc2F5aW5nIA0K4oCcVGhl IG1haW4gY29uc2VxdWVuY2UgZm9yIHRoZSBzdWJzY3JpYmVyIHdoZW4gYXBwbHlpbmcgdGhlIGF2 ZXJhZ2UgcmF0ZSANCm1lY2hhbmlzbSBpcyB0aGF0IGl0IGNhbiByZWNlaXZlIGEgbm90aWZpY2F0 aW9uIGV2ZW4gaWYgbm90aGluZyBoYXMgDQpjaGFuZ2VkIGluIHRoZSBjdXJyZW50IHN0YXRlIG9m IHRoZSBub3RpZmllci7igJ0NClRoaXMgaW52b2x2ZXMgIGEgREVDUkVBU0UgaW4gdGhlIGludGVy dmFsLg0KDQpJIGZvdW5kIHRoZSAgdXNlIG9mIHRoZSB0ZXJtIOKAnHRpbWVvdXTigJ0gIGNvbmZ1 c2luZyBhcyBpdCBpbXBsaWVzIChhdCBsZWFzdCANCnRvIG1lKSDigJxhIHRpbWUgaW4gd2hpY2gg eW91IG11c3Qgbm90IHNlbmQgYW55dGhpbmfigJ0gcmF0aGVyIHRoYW4g4oCcYSB0aW1lIA0KYWZ0 ZXIgd2hpY2ggeW91IG11c3Qgc2VuZCBzb21ldGhpbmfigJ0tIGJ1dCBtYXliZSB0aGF0IGlzIGp1 c3QgbWUuDQoNCldoZW4gd2UgZ2V0IHRvIHRoZSBmb3JtdWxhZSBhbmQgdGhlIGRldGFpbGVkIG1l Y2hhbmljcywgaXQgaXMgY2xlYXIgdGhhdCANCnRoaXMgYXBwcm9hY2ggd2lsbCBvbmx5IGV2ZXIg REVDUkVBU0UgdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucyANCihmcm9tIHdoYXQg aXQgd291bGQgYmUgd2l0aG91dCBFdmVudCBSYXRlIENvbnRyb2wpLCBpdCB3aWxsIG5ldmVyIElO Q1JFQVNFIA0KdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucyAgKGZyb20gd2hhdCBp dCB3b3VsZCBiZSB3aXRob3V0IEV2ZW50IA0KUmF0ZSBDb250cm9sKS4NCg0KU28geW91IG5lZWQg bWFrZSB0aGUgZG9jdW1lbnQgY29uc2lzdGVudC4gIEVpdGhlciByZW1vdmUgdGhlIHRleHQgdGhh dCANCnNheXMgKG9yIGltcGxpZXMpICB0aGUg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnSAgbWVjaGFu aXNtIHdpbGwgaW5jcmVhc2UsIGFzIA0Kd2VsbCBhcyBkZWNyZWFzZSwgdGhlIGludGVydmFsLCBv ciBtb2RpZnkgdGhlIG1lY2hhbmlzbSBzbyBpdCBET0VTIA0K4oCcZHluYW1pY2FsbHkgaW5jcmVh c2Ugb3IgZGVjcmVhc2UgdGhlIE5vdGlmaWNhdGlvbiBmcmVxdWVuY3nigJ0uICh0aGUgbGF0dGVy IA0Kd291bGQgYmUsIEkgdGhpbmssIHByZWZlcnJlZCkuDQoNCkZ1cnRoZXJtb3JlLCBpbiB0aGUg ZGVzY3JpcHRpb24gb2YgdGhlIOKAnGF2ZXJhZ2UtaW50ZXJ2YWzigJ0gbWVjaGFuaXNtLCB0aGVy ZSANCm5lZWRzIHRvIGJlIGVpdGhlciBhIOKAnE1VU1TigJ0gb3IgYSDigJxTSE9VTETigJ0gdG8g ZW5zdXJlIHRoYXQg4oCccGVyaW9k4oCdIGlzIA0KR1JFQVRFUiBUSEFOIHRoZSDigJxhdmVyYWdl LWludGVydmFs4oCdLiAgT3RoZXJ3aXNlIHRoZSBkZXNjcmliZWQgbWVjaGFuaXNtIA0Kd2lsbCBz ZW5kIG91dCBhIG5vdGlmaWNhdGlvbiBldmVyeSDigJxwZXJpb2TigJ0gc2Vjb25kcywgcmVnYXJk bGVzcyBvZiB0aGUgDQp2YWx1ZSBvZiDigJxhdmVyYWdlLWludGVydmFs4oCdLg0KDQoNCkphbmV0 DQoNClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSANCmRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBh ZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIA0KZGVsaXZlcnkuIA0KTk9URTog UmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBi aW5kIENTQyB0byANCmFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQg dG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgDQpvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUg ZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggDQpwdXJwb3Nl Lg0KDQpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMDYvMTAvMjAxMCAwNDoxNDoy OSBQTToNCg0KPiBbaW1hZ2UgcmVtb3ZlZF0gDQo+IA0KPiBbc2lwY29yZV0gQUQgcmV2aWV3OiBk cmFmdC1pZXRmLXNpcGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLTAzDQo+IA0KPiBSb2JlcnQgU3Bh cmtzIA0KPiANCj4gdG86DQo+IA0KPiBTSVBDT1JFDQo+IA0KPiAwNi8xMC8yMDEwIDA0OjE0IFBN DQo+IA0KPiBTZW50IGJ5Og0KPiANCj4gc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQo+IA0KPiBT dW1tYXJ5OiBUaGlzIGRyYWZ0IGhhcyBhIGZldyBhZGp1c3RtZW50cyB0aGF0IGFyZSBuZWVkZWQg YmVmb3JlIA0KPiBtb3ZpbmcgaXQgaW50byBJRVRGIExhc3QgQ2FsbC4NCj4gDQo+IE1ham9yIHF1 ZXN0aW9uOg0KPiANCj4gV2h5IGlzbid0IHRoaXMgYW4gVXBkYXRlIHRvIDMyNjU/IElzIHRoZXJl IHRleHQgaGVyZSB0aGF0IHByZXZlbnRzIA0KYXN1YnNjcmliZXINCj4gZnJvbSBnZW5lcmF0aW5n IEV2ZW50IGhlYWRlcnMgaW4gMjAwIE9LcyB0byBOT1RJRllzIG1pZC1zdWJzY3JpcHRpb24gDQoo d2hlbiBoZQ0KPiBkaWRuJ3QgcHJvYmUgZm9yIHN1cHBvcnQgdXNpbmcgdGhlIFNVQlNDUklCRT8p IEhvdyB3b3VsZCB0aGV5IGtub3cgdGhlIA0KcmVxdWVzdA0KPiBnb3QgaG9ub3JlZD8gIFRoZSBw b3NzaWJpbGl0eSBvZiBydW5uaW5nIGludG8gaW1wbGVtZW50YXRpb25zIHRoYXQgDQo+IGJyZWFr IHNob3VsZA0KPiBiZSBjYWxsZWQgb3V0LiAgNC4yIGluZGljYXRlcyB0aGUgc3Vic2NyaWJlciBv bmx5IGdldHMgYSAiaGludCIgYWJvdXQgDQpzdXBwb3J0DQo+IGZvciByYXRlLWNvbnRyb2wgaW4g dGhlIG5vdGlmaWVyIC0gaXMgdGhlIGNvbmRpdGlvbiBpdCBkZXNjcmliZXMgcmVhbGx5IA0Kb25s eSBhDQo+IGhpbnQ/DQo+IA0KPiBJbiBzZXZlcmFsIHBsYWNlcywgdGhlIG5vdGlmaWVyIGlzIGdp dmVuIHBlcm1pc3Npb24gdG8gYWRqdXN0IGFuIA0KPiBpbnRlcnZhbCBiYXNlZA0KPiBvbiBsb2Nh bCBwb2xpY3kuICBUaGUgZG9jdW1lbnQgc2hvdWxkIGJlIGV4cGxpY2l0IGFib3V0IGFsbG93aW5n IA0KdGhlYWRqdXN0bWVudA0KPiBpbiBhbnkgZGlyZWN0aW9uIChpbmNyZWFzaW5nIG9yIGRlY3Jl YXNpbmcpIHNpbmNlIHRoZXJlIGFyZSBzbyBtYW55IA0Kb3RoZXIgdXNlcw0KPiBvZiBpbnRlcnZh bHMgaW4gU0lQIGFuZCBTSVAgRXZlbnRzIHRoYXQgYWxsb3cgYWRqdXN0bWVudCBvbmx5IGluIA0K b25lZGlyZWN0aW9uLg0KPiBBIGZldyBwbGFjZXMgSSBub3RlZCB3aGVuIHJlYWRpbmcgdGhlIGRv Y3VtZW50IHdlcmUgdGhlIE5vdGUgaW4gUkVRNywgDQo0LjMgNHRoDQo+IHBhcmFncmFwaCwgNS4y IHBhcmFncmFwaCAzLCA2LjIgcGFyYWdyYXBoIDMuDQo+IA0KPiBUaGUgbGFzdCBwYXJhZ3JhcGgg b2Ygc2VjdGlvbiAzLjYgY2xhaW1zICJleGFjdGx5IHRoZSBzYW1lIHByb3BlcnRpZXMiIA0KZXhj ZXB0DQo+IGZvciBiZWluZyBnZW5lcmF0ZWQgY29uc3RyYWluZWQgdG8gYSBzY2hlZHVsZS4gQ2Fu IHlvdSBjbGFyaWZ5IA0Kd2hpY2hwcm9wZXJ0aWVzDQo+IHlvdSBtZWFuPyBNYW55IHByb3BlcnRp ZXMgb2YgdGhlIG5vdGlmaWNhdGlvbnMgYmVzaWRlIHRoZWlyIHRpbWluZyBhcmUgDQpjbGVhcmx5 DQo+IGRpZmZlcmVudCAoZm9yIGluc3RhbmNlLCB5b3UgbWF5IG1pc3Mgc3RhdGUgdHJhbnNpdGlv bnMpLg0KPiANCj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gZGVzZXJ2ZXMg bW9yZSB0ZXh0OiANCj4gKiBXaGF0IGlzIHRoZSBmb3J3YXJkIHJlZmVyZW5jZSBmcm9tIHNlY3Rp b24gMy40IHN1cHBvc2VkIHRvIGJlIHBvaW50aW5nIA0KdG8/DQo+ICogQ2FsbCBvdXQgdGhlIGlt cGxpY2F0aW9ucyBvbiBhIE5vdGlmaWVyIGhhdmluZyB0byBzdG9yZS9hZ2dyZWdhdGUgDQo+IHBh cnRpYWwgc3RhdGUNCj4gKiBOb3RlIHRoYXQgdGhlIEV2ZW50IGhlYWRlciAocGFydGljdWxhcmx5 IGluIDIwMCBPS3MpIGlzIG5vdCANCj4gaW50ZWdyaXR5IHByb3RlY3RlZC4gDQo+ICAgVGhpcyB3 b3VsZCBhbGxvdyBhbnl0aGluZyB0aGF0IGNvdWxkIG1vZGlmeSB0aGUgbWVzc2FnZSBpbiBmbGln aHQgKG9yIA0KYW4gDQo+ICAgZWF2ZXNkcm9wcGVyIHRoYXQgY291bGQgcmFjZSBhIDIwMCBPSyBp bikgdG8gc3VwcHJlc3MgKG9yIGZsb29kKSANCj4gbm90aWZpY2F0aW9ucyANCj4gICB3aXRob3V0 IHRoZSBzdWJzY3JpYmVyIHNlZWluZyB3aGF0IGNhdXNlZCBpdC4NCj4gDQo+IFRoZSBhc3NlcnRp b24gdGhhdCBhcHBseWluZyByYXRlIGxpbWl0aW5nIGFuZCBjb21wcmVzc2lvbiB0b2dldGhlciAN CnJlc3VsdHMgaW4NCj4gc2F2aW5ncyBhcyBnb29kIGFzIHRoZSBzdW0gb2YgYXBwbHlpbmcgdGhl bSBpbmRlcGVuZGVudGx5IHNob3VsZCBiZSANCnN1cHBvcnRlZA0KPiBvciBhZGp1c3RlZC4gSSB0 aGluayBpdCdzIHN1ZmZpY2llbnQgdG8gc2F5IHRoZXkgY2FuIGJlIGFwcGxpZWQgDQp0b2dldGhl ci4NCj4gDQo+IEJlbG93IGFyZSBzZXZlcmFsIHN1Z2dlc3Rpb25zIGZvciB0ZXh0IHR3ZWFrcy4g VGhlIGZpcnN0IGZldyAoc3RhcmluZyANCndpdGggKikNCj4gYXJlIHRoZSBtb3N0IGltcG9ydGFu dC4gDQo+IA0KPiAqIFNlY3Rpb24gMy4yIHBhcmFncmFwaCA0OiBzdWdnZXN0IHJlcGxhY2luZyAi ZG9lcyBub3QgdHlwaWNhbGx5IiANCj4gd2l0aCAibWF5IG5vdCINCj4gDQo+ICogU2VjdGlvbiAz LjIgbGFzdCBwYXJhZ3JhcGg6IFRoZSBzZW50ZW5jZSAnVGhlICJtYXgtaW50ZXJ2YWwiIHBhcmFt ZXRlciANCg0KPiAgICAgICBpbmRpY2F0ZXMgLi4uIGNvbXBsZXRlIHN0YXRlIGluZm9ybWF0aW9u JyBpcyBkaWZmaWN1bHQgdG8gDQo+IHBhcnNlLiBDb3VsZCBpdA0KPiAgICAgICBiZSBzaW1wbGlm aWVkPw0KPiANCj4gKiBTZWN0aW9uIDQuMyBmaXJzdCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6 ICJGb3Igc3VjaCBjYXNlcyIgaXMgDQphbWJpZ3VvdXMuDQo+ICAgU3VnZ2VzdCAiSWYgdGhlIG1p bi1pbnRlcnZhbCB2YWx1ZSBpcyBncmVhdGVyIHRoYW4gdGhlIHN1YnNjcmlwdGlvbiANCmV4cGly eSIuDQo+IA0KPiAqIFNlY3Rpb24gNi4yIGxhc3QgcGFyYWdyYXBoOiBUaGlzIGN1cnJlbnRseSBz YXlzIHRoZSB0aW1lb3V0IG1lY2hhbmlzbSANCmRvZXMNCj4gICBub3QgYWZmZWN0IHdoZW4gMzI2 MSB0cmFuc2FjdGlvbiByZXRyYW5zbWlzc2lvbnMgYXJlIGdlbmVyYXRlZC4gSXQgDQpzaG91bGQN Cj4gICBhbHNvIGV4cGxpY2l0bHkgbm90ZSB0aGF0IHJldHJhbnNtaXNzaW9ucyBkbyBub3QgYWZm ZWN0IHRoZSANCmNhbGN1bGF0aW9uIG9mDQo+ICAgdGhlIG5leHQgdGltZW91dC4NCj4gDQo+IElu dHJvZHVjdGlvbiwgcGFyYWdyYXBoIDI6IHN1Z2dlc3QgcmVwbGFjaW5nICJjb25nZXN0aW9uIiB3 aXRoICJsb2FkIg0KPiANCj4gU2VjdGlvbiAzLjEgIHBhcmFncmFwaCAzOiBzdWdnZXN0IHJlcGxh Y2luZyAiYW1vdW50IG9mIHRyYWZmaWMiIHdpdGggDQo+ICJudW1iZXIgb2Ygbm90aWZpY2F0aW9u cyINCj4gDQo+IFNlY3Rpb24gMy41IHBhcmFncmFwaCAxOiBTdWdnZXN0IGEgcmVmZXJlbmNlIGZv ciBSTFMgYWZ0ZXIgImxpc3QgDQo+IHN1YnNjcmlwdGlvbiIuDQo+IFRoZSBzZW50ZW5jZSAiTW9y ZW92ZXIsIHRoZSBsaXN0IGV2ZW50IG5vdGlmaWVyLi4uIiBzaG91bGQgYmUgbW9yZSANCmV4cGxp Y2l0DQo+IGFib3V0IHVzaW5nIHRoZSByYXRlIG1lY2hhbmlzbSBmb3IgYW55IGJhY2stZW5kIHN1 YnNjcmlwdGlvbnMgaXQgbWlnaHQgDQpoYXZlLg0KPiANCj4gU3VnZ2VzdCByZWZlcmVuY2luZyAz MjYxIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiA0LjINCj4gDQo+IFNlY3Rpb24gNC4zLCAzcmQg cGFyYWdyYXBoIGxhc3Qgc2VudGVuY2UuIFRoZSBvbmx5IHdheSB0aGUgc3Vic2NyaWJlciANCl9j YW5fDQo+IHJlc3VtZSBub3RpZmljYXRpb25zIGlzIHRvIHJlbmV3IHRoZSBzdWJzY3JpcHRpb24g d2l0aCBhIHJlc3Vic2NyaWJlIA0KcmVxdWVzdC4NCj4gV291bGQgdGhpcyB0ZXh0IHdvcms/ICJU aGlzIHJlc3VsdHMgaW4gcmVjZWl2aW5nIG5vIGZ1cnRoZXIgDQo+IG5vdGlmaWNhdGlvbnMgdW50 aWwNCj4gdGhlIHN1YnNjcmlwdGlvbiBleHBpcmVzIG9yIHRoZSBzdWJzY3JpYmVyIHNlbmRzIGEg U1VCU0NSSUJFIA0KcmVxdWVzdHJlZnJlc2hpbmcNCj4gdGhlIHN1YnNjcmlwdGlvbiAocGVyaGFw cyByZXN1bWluZyBub3RpZmljYXRpb25zKSIuDQo+IA0KPiBUaGUgdGV4dCBuZWVkcyB0byBiZSBh ZGp1c3RlZCB0byByZWZsZWN0IHN1Ym5vdC1ldGFncyBiZWluZyBpc3N1ZWQgYXMgYW4gDQpSRkMN Cj4gDQo+IEFkYW0gc3VnZ2VzdGVkIHNvbWUgUkZDLUVkaXRvciBub3RlcyBpbiB0aGUgcHJvdG8g d3JpdGV1cCAod2hpY2ggbWF5IA0KYWRkcmVzcw0KPiBzb21lIG9mIHRoZSBhYm92ZSBjb21tZW50 cykuIFBsZWFzZSBiZSBzdXJlIHRvIGluY29ycG9yYXRlIHRob3NlIHdoZW4gDQpyZXZpc2luZw0K PiB0aGUgZHJhZnQuDQo+IA0KPiBPbmUgbGFzdCBxdWVzdGlvbjoNCj4gDQo+IElmIHRoZSBjb21i aW5hdGlvbiBvZiBtaW4taW50ZXJ2YWwsIG1heC1pbnRlcnZhbCwgYW5kIGF2ZXJhZ2UtaW50ZXJ2 YWwgDQptYWtlDQo+IGxpdHRsZSBzZW5zZSwgd2h5IGRvZXMgdGhlIGRvY3VtZW50IGFsbG93IHRo ZW0gdG8gYmUgY29tYmluZWQ/IEkgDQo+IHRoaW5rIHdoYXQgdGhlDQo+IGdyb3VwIHdhcyB0cnlp bmcgdG8gc2F5IGlzIHRoYXQgd2UgY3VycmVudGx5IGRvbid0IGZvcnNlZSBhIHVzZSBmb3IgDQpj b21iaW5pbmcNCj4gdGhvc2Ugb3B0aW9ucywgYnV0IGRvIG5vdCB3aXNoIHRvIGZvcmJpZCB0aGVp ciBjb21iaW5hdGlvbi4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg== --=_alternative 0056612F8525773F_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBzb21lIGZ1cnRoZXIg Y29tbWVudHMsIG1vc3RseQ0KYWJvdXQgdGhlICZxdW90O2F2ZXJhZ2UmcXVvdDsgbWVjaGFuaXNt LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2hpbGUg 4oCcbWF4LWludGVydmFs4oCdIGlzIHN5bm9ueW1vdXMNCndpdGgg4oCcbWluaW11bSByYXRl4oCd LCBhbmQg4oCcbWluLWludGVydmFs4oCdIGlzIHN5bm9ueW1vdXMgd2l0aCDigJxtYXhpbXVtDQpy YXRl4oCdLCB0aGUgY29uc3RhbnQgc3dpdGNoaW5nIGJhY2sgYW5kIGZvcnRoIGJldHdlZW4gdGhl IHR3byBzZXRzIG9mIHRlcm1pbm9sb2d5DQptYWtlcyBpdCB2ZXJ5IGRpZmZpY3VsdCB0byBmb2xs b3cuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QaWNr IG9uZSBzZXQsIGFuZCB1c2UgdGhhdCBhcyB0aGUgZG9taW5hbnQNCnRlcm0uICZuYnNwO0F0IGEg bWluaW11bSwgdGhlIHNlY3Rpb24gaGVhZGluZyBzaG91bGQgYmUgY29uc2lzdGVudC48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBkZXNjcmlwdGlv biBvZiB0aGUgaW50ZW5kZWQgZWZmZWN0DQpvZiB0aGUg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnSBp cyB1bmNsZWFyIGFuZCBpbmNvbnNpc3RlbnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5JbiB0aGUgaW50cm9kdWN0aW9uLCBpdCBzYXlzIDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+4oCcICZuYnNwOyBhdmVyYWdlLWlu dGVydmFsOiAmbmJzcDtzcGVjaWZpZXMNCmFuIGF2ZXJhZ2UgY2FkZW5jZSBhdCB3aGljaCBub3Rp ZmljYXRpb25zIGFyZSBkZXNpcmVkLCBpbiBzZWNvbmRzLuKAnTwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhpcyBpbXBsaWVzIHRoYXQgaXQgd2lsbCBz cGVlZCB1cCB0aGUNCnJhdGUgb2Ygbm90aWZpY2F0aW9ucyB3aGVuIHRoZXkgd291bGQgb3RoZXJ3 aXNlIGJlIHRvbyBzbG93LCBhbmQgc2xvdyB0aGVtDQpkb3duIHdoZW4gdGhleSB3b3VsZCBvdGhl cndpc2UgYmUgdG9vIHF1aWNrLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+TGF0ZXIgaW4gdGhlIGludHJvIGl0IHNheXMgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj7igJxBbGwgdGhvc2UgbWVjaGFuaXNtcyBhcmUgc2lt cGx5IHRpbWVyDQp2YWx1ZXMgdGhhdCBpbmRpY2F0ZXMgKHNpYykgdGhlIG1pbmltdW0sIG1heGlt dW0gYW5kIGF2ZXJhZ2UgdGltZSBwZXJpb2QNCmFsbG93ZWQgYmV0d2VlbiB0d28gbm90aWZpY2F0 aW9ucy4gQXMgYSByZXN1bHQgb2YgdGhvc2UgbWVjaGFuaXNtLCBhIGNvbXBsaWFudA0Kbm90aWZp ZXIgd2lsbCBhZGp1c3QgdGhlIHJhdGUgYXQgd2hpY2ggaXQgZ2VuZXJhdGVzIG5vdGlmaWNhdGlv bnMu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5U aGlzIGFsc28gaW1wbGllcyB0aGF0IHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCdDQptZWNoYW5p c20gd2lsbCBib3RoIHNwZWVkIHVwIGFuZCBzbG93IGRvd24gdGhlIHJhdGUsIGFzIGFwcHJvcHJp YXRlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW4g c2VjdGlvbiAzLjMsIFVzZSBDYXNlIGZvciBzcGVjaWZ5aW5nDQp0aGUgYXZlcmFnZSByYXRlIG9m IG5vdGlmaWNhdGlvbnMsIGl0IGlzIGNvbnRyYWRpY3RvcnkuICZuYnNwO0ZpcnN0IGl0DQpzYXlz PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj7igJxkeW5hbWljYWxs eSBpbmNyZWFzZXMgdGhlIGludGVydmFsDQpiZXR3ZWVuIG5vdGlmaWNhdGlvbnMgaWYgdGhlIHRh cmdldCBoYXMgc2VudCBvdXQgc2V2ZXJhbCBub3RpZmljYXRpb25zDQpyZWNlbnRseS7igJ0gJm5i c3A7VGhpcyBpcyBhbiBJTkNSRUFTRSBpbiB0aGUgaW50ZXJ2YWw8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCB0aGVuIGl0IHNheXM8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPuKAnFRoZSAmcXVvdDthdmVyYWdlLWlu dGVydmFsJnF1b3Q7IHBhcmFtZXRlcg0KdmFsdWUgaXMgdXNlZCBieSB0aGUgbm90aWZpZXIgdG8g ZHluYW1pY2FsbHkgY2FsY3VsYXRlIHRoZSBtYXhpbXVtIHRpbWUNCmFsbG93ZWQgYmV0d2VlbiB0 d28gc3Vic2NyaXB0aW9ucyAoc2ljKS7igJ08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkZpcnN0LCBJIGFzc3VtZSB5b3UgbWVhbiDigJxiZXR3ZWVuIHR3bw0Kbm90 aWZpY2F0aW9uc+KAnS4gTm90IOKAnGJldHdlZW4gdHdvIHN1YnNjcmlwdGlvbnPigJ0uICZuYnNw O0J1dCBtb3JlIGltcG9ydGFudGx5LA0KZHluYW1pY2FsbHkgY2FsY3VsYXRpbmcg4oCcdGhlIG1h eGltdW0gdGltZSBhbGxvd2VkIGJldHdlZW4gbm90aWZpY2F0aW9uc+KAnQ0KbWVhbnMgdGhhdCB5 b3Ugd2lsbCBERUNSRUFTRSB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBub3RpZmljYXRpb25zLCBpZiB0 aGUNCnRhcmdldCBoYXMgbm90IHNlbnQgb3V0IGFueSBub3RpZmljYXRpb25zIHJlY2VudGx5Ljwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIGZ1cnRo ZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPuKAnFRoaXMgdHlw ZSBvZiByYXRlIGNvbnRyb2wgYWxsb3dzIHRoZQ0Kbm90aWZpZXIgdG8gZHluYW1pY2FsbHkgaW5j cmVhc2Ugb3IgZGVjcmVhc2UgdGhlIE5vdGlmaWNhdGlvbiBmcmVxdWVuY3ku4oCdPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XaGVuIHdlIGdldCB0byBz ZWN0aW9uIDYgKE9wZXJhdGlvbg0Kb2YgdGhlIGF2ZXJhZ2UgcmF0ZSBtZWNoYW5pc20pLCBpdCBz dGFydHMgb2ZmIGJ5IHNheWluZyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPuKAnFRoZSBtYWluIGNvbnNlcXVlbmNlIGZvciB0aGUgc3Vic2NyaWJlcg0Kd2hlbiBh cHBseWluZyB0aGUgYXZlcmFnZSByYXRlIG1lY2hhbmlzbSBpcyB0aGF0IGl0IGNhbiByZWNlaXZl IGEgbm90aWZpY2F0aW9uDQpldmVuIGlmIG5vdGhpbmcgaGFzIGNoYW5nZWQgaW4gdGhlIGN1cnJl bnQgc3RhdGUgb2YgdGhlIG5vdGlmaWVyLuKAnTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+VGhpcyBpbnZvbHZlcyAmbmJzcDthIERFQ1JFQVNFIGluIHRoZQ0KaW50 ZXJ2YWwuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5J IGZvdW5kIHRoZSAmbmJzcDt1c2Ugb2YgdGhlIHRlcm0g4oCcdGltZW91dOKAnQ0KJm5ic3A7Y29u ZnVzaW5nIGFzIGl0IGltcGxpZXMgKGF0IGxlYXN0IHRvIG1lKSDigJxhIHRpbWUgaW4gd2hpY2gg eW91IG11c3QNCm5vdCBzZW5kIGFueXRoaW5n4oCdIHJhdGhlciB0aGFuIOKAnGEgdGltZSBhZnRl ciB3aGljaCB5b3UgbXVzdCBzZW5kIHNvbWV0aGluZ+KAnS0NCmJ1dCBtYXliZSB0aGF0IGlzIGp1 c3QgbWUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5X aGVuIHdlIGdldCB0byB0aGUgZm9ybXVsYWUgYW5kIHRoZQ0KZGV0YWlsZWQgbWVjaGFuaWNzLCBp dCBpcyBjbGVhciB0aGF0IHRoaXMgYXBwcm9hY2ggd2lsbCBvbmx5IGV2ZXIgREVDUkVBU0UNCnRo ZSBpbnRlcnZhbCBiZXR3ZWVuIG5vdGlmaWNhdGlvbnMgJm5ic3A7KGZyb20gd2hhdCBpdCB3b3Vs ZCBiZSB3aXRob3V0DQpFdmVudCBSYXRlIENvbnRyb2wpLCBpdCB3aWxsIG5ldmVyIElOQ1JFQVNF IHRoZSBpbnRlcnZhbCBiZXR3ZWVuIG5vdGlmaWNhdGlvbnMNCiZuYnNwOyhmcm9tIHdoYXQgaXQg d291bGQgYmUgd2l0aG91dCBFdmVudCBSYXRlIENvbnRyb2wpLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28geW91IG5lZWQgbWFrZSB0aGUgZG9jdW1l bnQgY29uc2lzdGVudC4NCiZuYnNwO0VpdGhlciByZW1vdmUgdGhlIHRleHQgdGhhdCBzYXlzIChv ciBpbXBsaWVzKSAmbmJzcDt0aGUg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnQ0KJm5ic3A7bWVjaGFu aXNtIHdpbGwgaW5jcmVhc2UsIGFzIHdlbGwgYXMgZGVjcmVhc2UsIHRoZSBpbnRlcnZhbCwgb3Ig bW9kaWZ5DQp0aGUgbWVjaGFuaXNtIHNvIGl0IERPRVMg4oCcZHluYW1pY2FsbHkgaW5jcmVhc2Ug b3IgZGVjcmVhc2UgdGhlIE5vdGlmaWNhdGlvbg0KZnJlcXVlbmN54oCdLiAodGhlIGxhdHRlciB3 b3VsZCBiZSwgSSB0aGluaywgcHJlZmVycmVkKS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZ1cnRoZXJtb3JlLCBpbiB0aGUgZGVzY3JpcHRpb24gb2Yg dGhlDQrigJxhdmVyYWdlLWludGVydmFs4oCdIG1lY2hhbmlzbSwgdGhlcmUgbmVlZHMgdG8gYmUg ZWl0aGVyIGEg4oCcTVVTVOKAnSBvcg0KYSDigJxTSE9VTETigJ0gdG8gZW5zdXJlIHRoYXQg4oCc cGVyaW9k4oCdIGlzIEdSRUFURVIgVEhBTiB0aGUg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnS4NCiZu YnNwO090aGVyd2lzZSB0aGUgZGVzY3JpYmVkIG1lY2hhbmlzbSB3aWxsIHNlbmQgb3V0IGEgbm90 aWZpY2F0aW9uIGV2ZXJ5DQrigJxwZXJpb2TigJ0gc2Vjb25kcywgcmVnYXJkbGVzcyBvZiB0aGUg dmFsdWUgb2Yg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnS48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkphbmV0PGJyPg0KPGJyPg0KVGhpcyBpcyBh IFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlDQpkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUt bWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KZGVsaXZlcnkuIDxicj4NCk5PVEU6IFJlZ2FyZGxlc3Mg b2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MNCnRv IGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQg d3JpdHRlbiBhZ3JlZW1lbnQNCm9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVy bWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaA0KcHVycG9zZS48L2ZvbnQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5zaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24g MDYvMTAvMjAxMCAwNDoxNDoyOQ0KUE06PGJyPg0KPGJyPg0KJmd0OyBbaW1hZ2UgcmVtb3ZlZF0g PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgW3NpcGNv cmVdIEFEIHJldmlldzogZHJhZnQtaWV0Zi1zaXBjb3JlLWV2ZW50LXJhdGUtY29udHJvbC0wMzwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJvYmVydCBT cGFya3MgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg dG86PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgU0lQ Q09SRTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDA2 LzEwLzIwMTAgMDQ6MTQgUE08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyBTZW50IGJ5OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyA8YnI+DQomZ3Q7IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFN1bW1hcnk6IFRoaXMgZHJhZnQgaGFzIGEg ZmV3IGFkanVzdG1lbnRzIHRoYXQgYXJlIG5lZWRlZCBiZWZvcmUgPGJyPg0KJmd0OyBtb3Zpbmcg aXQgaW50byBJRVRGIExhc3QgQ2FsbC48YnI+DQomZ3Q7IDxicj4NCiZndDsgTWFqb3IgcXVlc3Rp b246PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoeSBpc24ndCB0aGlzIGFuIFVwZGF0ZSB0byAzMjY1 PyBJcyB0aGVyZSB0ZXh0IGhlcmUgdGhhdCBwcmV2ZW50cw0KYXN1YnNjcmliZXI8YnI+DQomZ3Q7 IGZyb20gZ2VuZXJhdGluZyBFdmVudCBoZWFkZXJzIGluIDIwMCBPS3MgdG8gTk9USUZZcyBtaWQt c3Vic2NyaXB0aW9uDQood2hlbiBoZTxicj4NCiZndDsgZGlkbid0IHByb2JlIGZvciBzdXBwb3J0 IHVzaW5nIHRoZSBTVUJTQ1JJQkU/KSBIb3cgd291bGQgdGhleSBrbm93DQp0aGUgcmVxdWVzdDxi cj4NCiZndDsgZ290IGhvbm9yZWQ/ICZuYnNwO1RoZSBwb3NzaWJpbGl0eSBvZiBydW5uaW5nIGlu dG8gaW1wbGVtZW50YXRpb25zDQp0aGF0IDxicj4NCiZndDsgYnJlYWsgc2hvdWxkPGJyPg0KJmd0 OyBiZSBjYWxsZWQgb3V0LiAmbmJzcDs0LjIgaW5kaWNhdGVzIHRoZSBzdWJzY3JpYmVyIG9ubHkg Z2V0cyBhICZxdW90O2hpbnQmcXVvdDsNCmFib3V0IHN1cHBvcnQ8YnI+DQomZ3Q7IGZvciByYXRl LWNvbnRyb2wgaW4gdGhlIG5vdGlmaWVyIC0gaXMgdGhlIGNvbmRpdGlvbiBpdCBkZXNjcmliZXMg cmVhbGx5DQpvbmx5IGE8YnI+DQomZ3Q7IGhpbnQ/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHNl dmVyYWwgcGxhY2VzLCB0aGUgbm90aWZpZXIgaXMgZ2l2ZW4gcGVybWlzc2lvbiB0byBhZGp1c3Qg YW4gPGJyPg0KJmd0OyBpbnRlcnZhbCBiYXNlZDxicj4NCiZndDsgb24gbG9jYWwgcG9saWN5LiAm bmJzcDtUaGUgZG9jdW1lbnQgc2hvdWxkIGJlIGV4cGxpY2l0IGFib3V0IGFsbG93aW5nDQp0aGVh ZGp1c3RtZW50PGJyPg0KJmd0OyBpbiBhbnkgZGlyZWN0aW9uIChpbmNyZWFzaW5nIG9yIGRlY3Jl YXNpbmcpIHNpbmNlIHRoZXJlIGFyZSBzbyBtYW55DQpvdGhlciB1c2VzPGJyPg0KJmd0OyBvZiBp bnRlcnZhbHMgaW4gU0lQIGFuZCBTSVAgRXZlbnRzIHRoYXQgYWxsb3cgYWRqdXN0bWVudCBvbmx5 IGluIG9uZWRpcmVjdGlvbi48YnI+DQomZ3Q7IEEgZmV3IHBsYWNlcyBJIG5vdGVkIHdoZW4gcmVh ZGluZyB0aGUgZG9jdW1lbnQgd2VyZSB0aGUgTm90ZSBpbiBSRVE3LA0KNC4zIDR0aDxicj4NCiZn dDsgcGFyYWdyYXBoLCA1LjIgcGFyYWdyYXBoIDMsIDYuMiBwYXJhZ3JhcGggMy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGhlIGxhc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gMy42IGNsYWltcyAmcXVv dDtleGFjdGx5IHRoZSBzYW1lIHByb3BlcnRpZXMmcXVvdDsNCmV4Y2VwdDxicj4NCiZndDsgZm9y IGJlaW5nIGdlbmVyYXRlZCBjb25zdHJhaW5lZCB0byBhIHNjaGVkdWxlLiBDYW4geW91IGNsYXJp Znkgd2hpY2hwcm9wZXJ0aWVzPGJyPg0KJmd0OyB5b3UgbWVhbj8gTWFueSBwcm9wZXJ0aWVzIG9m IHRoZSBub3RpZmljYXRpb25zIGJlc2lkZSB0aGVpciB0aW1pbmcNCmFyZSBjbGVhcmx5PGJyPg0K Jmd0OyBkaWZmZXJlbnQgKGZvciBpbnN0YW5jZSwgeW91IG1heSBtaXNzIHN0YXRlIHRyYW5zaXRp b25zKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gZGVzZXJ2ZXMgbW9yZSB0ZXh0OiA8YnI+DQomZ3Q7ICogV2hhdCBpcyB0aGUgZm9yd2Fy ZCByZWZlcmVuY2UgZnJvbSBzZWN0aW9uIDMuNCBzdXBwb3NlZCB0byBiZSBwb2ludGluZw0KdG8/ PGJyPg0KJmd0OyAqIENhbGwgb3V0IHRoZSBpbXBsaWNhdGlvbnMgb24gYSBOb3RpZmllciBoYXZp bmcgdG8gc3RvcmUvYWdncmVnYXRlDQo8YnI+DQomZ3Q7IHBhcnRpYWwgc3RhdGU8YnI+DQomZ3Q7 ICogTm90ZSB0aGF0IHRoZSBFdmVudCBoZWFkZXIgKHBhcnRpY3VsYXJseSBpbiAyMDAgT0tzKSBp cyBub3QgPGJyPg0KJmd0OyBpbnRlZ3JpdHkgcHJvdGVjdGVkLiA8YnI+DQomZ3Q7ICZuYnNwOyBU aGlzIHdvdWxkIGFsbG93IGFueXRoaW5nIHRoYXQgY291bGQgbW9kaWZ5IHRoZSBtZXNzYWdlIGlu DQpmbGlnaHQgKG9yIGFuIDxicj4NCiZndDsgJm5ic3A7IGVhdmVzZHJvcHBlciB0aGF0IGNvdWxk IHJhY2UgYSAyMDAgT0sgaW4pIHRvIHN1cHByZXNzIChvciBmbG9vZCkNCjxicj4NCiZndDsgbm90 aWZpY2F0aW9ucyA8YnI+DQomZ3Q7ICZuYnNwOyB3aXRob3V0IHRoZSBzdWJzY3JpYmVyIHNlZWlu ZyB3aGF0IGNhdXNlZCBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGFzc2VydGlvbiB0aGF0 IGFwcGx5aW5nIHJhdGUgbGltaXRpbmcgYW5kIGNvbXByZXNzaW9uIHRvZ2V0aGVyDQpyZXN1bHRz IGluPGJyPg0KJmd0OyBzYXZpbmdzIGFzIGdvb2QgYXMgdGhlIHN1bSBvZiBhcHBseWluZyB0aGVt IGluZGVwZW5kZW50bHkgc2hvdWxkIGJlDQpzdXBwb3J0ZWQ8YnI+DQomZ3Q7IG9yIGFkanVzdGVk LiBJIHRoaW5rIGl0J3Mgc3VmZmljaWVudCB0byBzYXkgdGhleSBjYW4gYmUgYXBwbGllZCB0b2dl dGhlci48YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVsb3cgYXJlIHNldmVyYWwgc3VnZ2VzdGlvbnMg Zm9yIHRleHQgdHdlYWtzLiBUaGUgZmlyc3QgZmV3IChzdGFyaW5nDQp3aXRoICopPGJyPg0KJmd0 OyBhcmUgdGhlIG1vc3QgaW1wb3J0YW50LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKiBTZWN0aW9u IDMuMiBwYXJhZ3JhcGggNDogc3VnZ2VzdCByZXBsYWNpbmcgJnF1b3Q7ZG9lcyBub3QgdHlwaWNh bGx5JnF1b3Q7DQo8YnI+DQomZ3Q7IHdpdGggJnF1b3Q7bWF5IG5vdCZxdW90Ozxicj4NCiZndDsg PGJyPg0KJmd0OyAqIFNlY3Rpb24gMy4yIGxhc3QgcGFyYWdyYXBoOiBUaGUgc2VudGVuY2UgJ1Ro ZSAmcXVvdDttYXgtaW50ZXJ2YWwmcXVvdDsNCnBhcmFtZXRlciA8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGluZGljYXRlcyAuLi4gY29tcGxldGUgc3RhdGUgaW5mb3JtYXRpb24nIGlz DQpkaWZmaWN1bHQgdG8gPGJyPg0KJmd0OyBwYXJzZS4gQ291bGQgaXQ8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGJlIHNpbXBsaWZpZWQ/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICogU2Vj dGlvbiA0LjMgZmlyc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlOiAmcXVvdDtGb3Igc3VjaCBj YXNlcyZxdW90Ow0KaXMgYW1iaWd1b3VzLjxicj4NCiZndDsgJm5ic3A7IFN1Z2dlc3QgJnF1b3Q7 SWYgdGhlIG1pbi1pbnRlcnZhbCB2YWx1ZSBpcyBncmVhdGVyIHRoYW4gdGhlDQpzdWJzY3JpcHRp b24gZXhwaXJ5JnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAqIFNlY3Rpb24gNi4yIGxhc3Qg cGFyYWdyYXBoOiBUaGlzIGN1cnJlbnRseSBzYXlzIHRoZSB0aW1lb3V0IG1lY2hhbmlzbQ0KZG9l czxicj4NCiZndDsgJm5ic3A7IG5vdCBhZmZlY3Qgd2hlbiAzMjYxIHRyYW5zYWN0aW9uIHJldHJh bnNtaXNzaW9ucyBhcmUgZ2VuZXJhdGVkLg0KSXQgc2hvdWxkPGJyPg0KJmd0OyAmbmJzcDsgYWxz byBleHBsaWNpdGx5IG5vdGUgdGhhdCByZXRyYW5zbWlzc2lvbnMgZG8gbm90IGFmZmVjdCB0aGUN CmNhbGN1bGF0aW9uIG9mPGJyPg0KJmd0OyAmbmJzcDsgdGhlIG5leHQgdGltZW91dC48YnI+DQom Z3Q7IDxicj4NCiZndDsgSW50cm9kdWN0aW9uLCBwYXJhZ3JhcGggMjogc3VnZ2VzdCByZXBsYWNp bmcgJnF1b3Q7Y29uZ2VzdGlvbiZxdW90Ow0Kd2l0aCAmcXVvdDtsb2FkJnF1b3Q7PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFNlY3Rpb24gMy4xICZuYnNwO3BhcmFncmFwaCAzOiBzdWdnZXN0IHJlcGxh Y2luZyAmcXVvdDthbW91bnQgb2YgdHJhZmZpYyZxdW90Ow0Kd2l0aCA8YnI+DQomZ3Q7ICZxdW90 O251bWJlciBvZiBub3RpZmljYXRpb25zJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNlY3Rp b24gMy41IHBhcmFncmFwaCAxOiBTdWdnZXN0IGEgcmVmZXJlbmNlIGZvciBSTFMgYWZ0ZXIgJnF1 b3Q7bGlzdA0KPGJyPg0KJmd0OyBzdWJzY3JpcHRpb24mcXVvdDsuPGJyPg0KJmd0OyBUaGUgc2Vu dGVuY2UgJnF1b3Q7TW9yZW92ZXIsIHRoZSBsaXN0IGV2ZW50IG5vdGlmaWVyLi4uJnF1b3Q7IHNo b3VsZA0KYmUgbW9yZSBleHBsaWNpdDxicj4NCiZndDsgYWJvdXQgdXNpbmcgdGhlIHJhdGUgbWVj aGFuaXNtIGZvciBhbnkgYmFjay1lbmQgc3Vic2NyaXB0aW9ucyBpdCBtaWdodA0KaGF2ZS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgU3VnZ2VzdCByZWZlcmVuY2luZyAzMjYxIGluIHRoZSBsYXN0IHBh cmFncmFwaCBvZiA0LjI8YnI+DQomZ3Q7IDxicj4NCiZndDsgU2VjdGlvbiA0LjMsIDNyZCBwYXJh Z3JhcGggbGFzdCBzZW50ZW5jZS4gVGhlIG9ubHkgd2F5IHRoZSBzdWJzY3JpYmVyDQpfY2FuXzxi cj4NCiZndDsgcmVzdW1lIG5vdGlmaWNhdGlvbnMgaXMgdG8gcmVuZXcgdGhlIHN1YnNjcmlwdGlv biB3aXRoIGEgcmVzdWJzY3JpYmUNCnJlcXVlc3QuPGJyPg0KJmd0OyBXb3VsZCB0aGlzIHRleHQg d29yaz8gJnF1b3Q7VGhpcyByZXN1bHRzIGluIHJlY2VpdmluZyBubyBmdXJ0aGVyIDxicj4NCiZn dDsgbm90aWZpY2F0aW9ucyB1bnRpbDxicj4NCiZndDsgdGhlIHN1YnNjcmlwdGlvbiBleHBpcmVz IG9yIHRoZSBzdWJzY3JpYmVyIHNlbmRzIGEgU1VCU0NSSUJFIHJlcXVlc3RyZWZyZXNoaW5nPGJy Pg0KJmd0OyB0aGUgc3Vic2NyaXB0aW9uIChwZXJoYXBzIHJlc3VtaW5nIG5vdGlmaWNhdGlvbnMp JnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgdGV4dCBuZWVkcyB0byBiZSBhZGp1c3Rl ZCB0byByZWZsZWN0IHN1Ym5vdC1ldGFncyBiZWluZyBpc3N1ZWQNCmFzIGFuIFJGQzxicj4NCiZn dDsgPGJyPg0KJmd0OyBBZGFtIHN1Z2dlc3RlZCBzb21lIFJGQy1FZGl0b3Igbm90ZXMgaW4gdGhl IHByb3RvIHdyaXRldXAgKHdoaWNoIG1heQ0KYWRkcmVzczxicj4NCiZndDsgc29tZSBvZiB0aGUg YWJvdmUgY29tbWVudHMpLiBQbGVhc2UgYmUgc3VyZSB0byBpbmNvcnBvcmF0ZSB0aG9zZSB3aGVu DQpyZXZpc2luZzxicj4NCiZndDsgdGhlIGRyYWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBPbmUg bGFzdCBxdWVzdGlvbjo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgdGhlIGNvbWJpbmF0aW9uIG9m IG1pbi1pbnRlcnZhbCwgbWF4LWludGVydmFsLCBhbmQgYXZlcmFnZS1pbnRlcnZhbA0KbWFrZTxi cj4NCiZndDsgbGl0dGxlIHNlbnNlLCB3aHkgZG9lcyB0aGUgZG9jdW1lbnQgYWxsb3cgdGhlbSB0 byBiZSBjb21iaW5lZD8gSSA8YnI+DQomZ3Q7IHRoaW5rIHdoYXQgdGhlPGJyPg0KJmd0OyBncm91 cCB3YXMgdHJ5aW5nIHRvIHNheSBpcyB0aGF0IHdlIGN1cnJlbnRseSBkb24ndCBmb3JzZWUgYSB1 c2UgZm9yDQpjb21iaW5pbmc8YnI+DQomZ3Q7IHRob3NlIG9wdGlvbnMsIGJ1dCBkbyBub3Qgd2lz aCB0byBmb3JiaWQgdGhlaXIgY29tYmluYXRpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzaXBj b3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgc2lwY29yZUBpZXRmLm9yZzxicj4NCiZndDsgPC9m b250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmU+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmU8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+ PC90dD4NCg== --=_alternative 0056612F8525773F_=-- From root@core3.amsl.com Mon Jun 14 13:30:21 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 618FB3A691D; Mon, 14 Jun 2010 13:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100614203020.618FB3A691D@core3.amsl.com> Date: Mon, 14 Jun 2010 13:30:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 20:30:21 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-03.txt Pages : 67 Date : 2010-06-14 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-sec-flows-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-14131938.I-D@ietf.org> --NextPart-- From brian@estacado.net Mon Jun 14 13:35:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F963A6925 for ; Mon, 14 Jun 2010 13:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ6zCF2EdoX6 for ; Mon, 14 Jun 2010 13:35:14 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 986F03A691D for ; Mon, 14 Jun 2010 13:35:13 -0700 (PDT) Received: from dn3-238.estacado.net (dn3-238.estacado.net [172.16.3.238]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o5EKZFs6090759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 14 Jun 2010 15:35:15 -0500 (CDT) (envelope-from brian@estacado.net) From: Brian Hibbard Content-Type: multipart/alternative; boundary=Apple-Mail-1--259716440 Date: Mon, 14 Jun 2010 15:35:10 -0500 Message-Id: <7B51EAC9-8517-431B-B0A0-1A942FB1E6E4@estacado.net> To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [sipcore] New draft-ietf-sipcore-sec-flows-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 20:35:15 -0000 --Apple-Mail-1--259716440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings All, There is a new version of draft-ietf-sipcore-sec-flows at http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-03.txt Here is a brief summary of the changes in this version: 1) Example certificates have corrected serial numbers and = expiration dates that expire in 100 years. =20 2) Example flows have Contact header fields removed. They = now use the allOneLine convention that was put forth in RFC 4475. 3) Section 5 ("Observed Interoperability Issues") and = Section 6 ("Additional Test Scenarios") had a good deal of minor = editing, mostly to the effect of including relevant references and not = trying to introduce new normative-sounding language. 4) There is a new section that presents an example of a = certificate chain that includes a non-root CA (the cert chain is longer = than two). I specifically want to call attention to changes I made to a bullet item = in section 6. The old text said: "For S/MIME, the peer's URI must appear in the subjectAltName=20 of the peer's certifcate as a uniformResourceIdentifier field." The question came up "which URI?" With regard to S/MIME, RFC 3261 = section 23.3 mentions specifies the URI from AOR. =20 The text now reads: "For S/MIME secured bodies, assure that the peer's URI=20 (address-of-record, as per RFC 3261 [3] section 23.3) appears in = the=20 subjectAltName of the peer's certifcate as a = uniformResourceIdentifier field." Regards, Brian Hibbard Tekelec= --Apple-Mail-1--259716440 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-03= .txt

Here is a brief summary of the changes = in this version:

1) Example certificates have = corrected serial numbers and expiration dates that expire in 100 years. =  

2) Example flows have Contact header = fields removed.  They now use the allOneLine convention that was = put forth in RFC 4475.

3) Section 5 = ("Observed Interoperability Issues") and Section 6 ("Additional Test = Scenarios") had a good deal of minor editing, mostly to the effect of = including relevant references and not trying to introduce new = normative-sounding language.

4) There is = a new section that presents an example of a certificate chain that = includes a non-root CA (the cert chain is longer than = two).

I specifically want to call attention to = changes I made to a bullet item in section 6.  The old text = said:

"For S/MIME, the peer's URI must = appear in the subjectAltName 
of the = peer's certifcate as a uniformResourceIdentifier = field."

The question came up "which URI?" =  With regard to S/MIME, RFC 3261 section 23.3 mentions specifies = the URI from AOR.  

The text now = reads:
  "For S/MIME secured bodies, = assure that the peer's URI 
(address-of-record, as per RFC = 3261 [3] section 23.3) appears in the 
= subjectAltName of the peer's certifcate as a = uniformResourceIdentifier = field."


Regards,

Brian Hibbard
Tekelec
= --Apple-Mail-1--259716440-- From fluffy@cisco.com Tue Jun 15 18:26:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1723A696F for ; Tue, 15 Jun 2010 18:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.757 X-Spam-Level: X-Spam-Status: No, score=-108.757 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZJOhvv4pyny for ; Tue, 15 Jun 2010 18:26:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D3DD63A659A for ; Tue, 15 Jun 2010 18:26:28 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQFAAbFF0yrRN+J/2dsb2JhbACSXIwdcaZCmi6CWoJABINQ X-IronPort-AV: E=Sophos;i="4.53,423,1272844800"; d="scan'208";a="545509736" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2010 01:26:15 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o5G1QEqx017072 for ; Wed, 16 Jun 2010 01:26:14 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Tue, 15 Jun 2010 19:26:13 -0600 Message-Id: <27AA7C87-8C2D-417A-88BA-CB90D2DB64D0@cisco.com> To: sipcore@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [sipcore] Proposed change to draft-ietf-sip-certs to allow SHA256 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 01:26:30 -0000 The draft-ietf-sip-certs has been sitting around for a long time in IESG = review stage for a variety of reasons. In the time since the working = group requested publication of this, it has become clear that SHA1 is = not as strong a cryptographic hash as was believed when the WGLC was = done. There is a desire to have new protocols support SHA256 in case = even more attacks on SHA1 are found.=20 The draft currently has a "discuss" from the IESG asking us to move from = SHA1 to SHA256. I think this is the right thing to do. This would = involved defining a new algorithm for the SIP Identity signature and = updating the crypto profiles in sip-certs to support SHA256 instead of = SHA1. This is all trivial to do in the draft but is a technical change = to the draft that I think folks need to be aware of the change in case = there is some serious problem with this. In similar vain we would change = the crypto from DES to AES. I talked to a few implementers to see if = this posed problem but none of them saw this as an issues as the crypto = libraries they were using already had SHA256 and AES for other reasons. = The sizes of data that are being signed or encrypted are small so the = RSA operations dominate the CPU processing and this change makes no = significant change on performance of size.=20 Every security person I have talked to thinks we need to move to = something better than SHA1 so I don't see this as being very = contentious. I plan to update the draft with this sometime soon. If you = have objections to this plan, please let me know in the next week.=20 Thanks, Cullen From adam@nostrum.com Tue Jun 15 18:55:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A4D3A6A0C for ; Tue, 15 Jun 2010 18:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xoeuQOMCmSY for ; Tue, 15 Jun 2010 18:55:48 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8561B3A67AF for ; Tue, 15 Jun 2010 18:55:48 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5G1tn9X044105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jun 2010 20:55:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C182F25.5090006@nostrum.com> Date: Tue, 15 Jun 2010 20:55:49 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Cullen Jennings References: <27AA7C87-8C2D-417A-88BA-CB90D2DB64D0@cisco.com> In-Reply-To: <27AA7C87-8C2D-417A-88BA-CB90D2DB64D0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposed change to draft-ietf-sip-certs to allow SHA256 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 01:55:49 -0000 On 6/15/10 20:26, Jun 15, Cullen Jennings wrote: > Every security person I have talked to thinks we need to move to something better than SHA1 so I don't see this as being very contentious. I plan to update the draft with this sometime soon. If you have objections to this plan, please let me know in the next week. > [as a participant] I support a move to SHA256 for sip-certs. /a From brian@estacado.net Wed Jun 16 10:45:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3A23A6B70 for ; Wed, 16 Jun 2010 10:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGiOGyjCxNum for ; Wed, 16 Jun 2010 10:45:40 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 35D1A3A6B71 for ; Wed, 16 Jun 2010 10:45:39 -0700 (PDT) Received: from dn3-238.estacado.net (dn3-238.estacado.net [172.16.3.238]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o5GHjfXB003536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Jun 2010 12:45:42 -0500 (CDT) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Brian Hibbard In-Reply-To: <4C182F25.5090006@nostrum.com> Date: Wed, 16 Jun 2010 12:45:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <00E690D8-FE7C-4A51-90F6-44788DDE43E5@estacado.net> References: <27AA7C87-8C2D-417A-88BA-CB90D2DB64D0@cisco.com> <4C182F25.5090006@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1078) Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposed change to draft-ietf-sip-certs to allow SHA256 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 17:45:41 -0000 I think it's a good idea. Various experts have been grumbling about = SHA-1 inadequacies for years.=20 On Jun 15, 2010, at 8:55 PM, Adam Roach wrote: > On 6/15/10 20:26, Jun 15, Cullen Jennings wrote: >> Every security person I have talked to thinks we need to move to = something better than SHA1 so I don't see this as being very = contentious. I plan to update the draft with this sometime soon. If you = have objections to this plan, please let me know in the next week. >> =20 >=20 > [as a participant] >=20 > I support a move to SHA256 for sip-certs. >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From rjsparks@nostrum.com Thu Jun 17 12:47:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771C628C104 for ; Thu, 17 Jun 2010 12:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIETsRpOni-l for ; Thu, 17 Jun 2010 12:47:32 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9D14928C0FF for ; Thu, 17 Jun 2010 12:47:31 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5HJkpO8021734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 Jun 2010 14:47:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jun 2010 14:47:35 -0500 Message-Id: To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 19:47:34 -0000 Gonzalo asked me to put sipcore-reinvite in revised-id needed while he = addresses some of the recent list comments. RjS From pkyzivat@cisco.com Thu Jun 17 13:19:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D663A68BE for ; Thu, 17 Jun 2010 13:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYv7afCCb4fS for ; Thu, 17 Jun 2010 13:19:12 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 50D0D3A6B10 for ; Thu, 17 Jun 2010 13:19:12 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFkgGkxAZnwN/2dsb2JhbACeenGnYpo3hRoE X-IronPort-AV: E=Sophos;i="4.53,433,1272844800"; d="scan'208";a="122855443" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2010 20:19:17 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5HKJHVC021888; Thu, 17 Jun 2010 20:19:17 GMT Message-ID: <4C1A8344.7050109@cisco.com> Date: Thu, 17 Jun 2010 16:19:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Robert Sparks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 20:19:13 -0000 Robert, Yes, I meant to bring that up too, but didn't get to it. :-( I think we also need to reassess where we are on offeranswer. I think the primary issues there are to do with the reinvite issues. Thanks, Paul Robert Sparks wrote: > Gonzalo asked me to put sipcore-reinvite in revised-id needed while he addresses some of the recent list comments. > > RjS > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From shida@ntt-at.com Mon Jun 21 22:10:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980A63A695F for ; Mon, 21 Jun 2010 22:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJZ+JS9LxNXz for ; Mon, 21 Jun 2010 22:10:47 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.37.25]) by core3.amsl.com (Postfix) with SMTP id 8B8523A6953 for ; Mon, 21 Jun 2010 22:10:47 -0700 (PDT) Received: (qmail 5456 invoked from network); 22 Jun 2010 05:16:04 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 22 Jun 2010 05:16:04 -0000 Received: from flh1agc175.tky.mesh.ad.jp ([60.239.252.175]:60680 helo=[192.168.1.14]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1OQvkl-00070h-0U for sipcore@ietf.org; Tue, 22 Jun 2010 00:10:36 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 22 Jun 2010 14:10:47 +0900 Message-Id: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Subject: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 05:10:49 -0000 We have a device from several vendors on our test bed (and will be deployed in near future) that goes into sleep mode (energy saving mode) when standing by. It takes about 10 seconds for these devices to wake up and although it can't process the SDP and other parameters in INVITE while resuming, it can be configured to send a response. Question is what response should be sent to indicate to the caller the following semantics. "device on the callee side is waking up to decide whether it can handle the call or if it's interested in picking up the call at all". The response code that kind of match the semantic is the 182 "Queued", based on the definition in RFC3261 or 183 "Session Progress" but we can't seem to come to agreement internally, so I was hoping to get some opinions on this.. ** 21.1.4 182 Queued The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, "5 calls queued; expected waiting time is 15 minutes". The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call. ** If none of the currently defined response code is suitable semantically, would it be viable to define a new response code for this, I personally don't think so but as we may see more and more of devices like this in the future, may be? Another option is I guess is to use current 18x + Alert-Info URN to indicate what's happening on the callee side. Regards Shida From christer.holmberg@ericsson.com Mon Jun 21 22:33:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973A23A686D for ; Mon, 21 Jun 2010 22:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61nBIT-oiFkB for ; Mon, 21 Jun 2010 22:33:16 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8A7863A6950 for ; Mon, 21 Jun 2010 22:33:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-49-4c204b2096e1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B3.6C.29106.02B402C4; Tue, 22 Jun 2010 07:33:20 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 22 Jun 2010 07:33:19 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.18]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 22 Jun 2010 07:33:19 +0200 From: Christer Holmberg To: Shida Schubert , SIPCORE Date: Tue, 22 Jun 2010 07:33:18 +0200 Thread-Topic: [sipcore] ECO(energy-saving) device and response code Thread-Index: AcsRyVAgusRk1hDWTA+tNKDkUi6jIQAAue6w Message-ID: References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> In-Reply-To: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 05:33:28 -0000 Hi Shida, Without having an opinon which response code would be the most appropriate,= please keep in mind that a 18x response does create an early dialog, so ev= en if the terminal maybe doesn't need to process SDP at that point it may h= ave create a route set etc. Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Shida Schubert > Sent: 22. kes=E4kuuta 2010 8:11 > To: SIPCORE > Subject: [sipcore] ECO(energy-saving) device and response code >=20 >=20 > We have a device from several vendors on our test bed (and=20 > will be deployed in near future) that goes into sleep mode=20 > (energy saving mode) when standing by.=20 >=20 > It takes about 10 seconds for these devices to wake up and=20 > although it can't process the SDP and other parameters in=20 > INVITE while resuming, it can be configured to send a response.=20 >=20 > Question is what response should be sent to indicate to the=20 > caller the following semantics. >=20 > "device on the callee side is waking up to decide whether it=20 > can handle the call or if it's interested in picking up the=20 > call at all".=20 >=20 > The response code that kind of match the semantic is the 182=20 > "Queued", based on the definition in RFC3261 or 183 "Session=20 > Progress" but we can't seem to come to agreement internally,=20 > so I was hoping to get some opinions on this..=20 >=20 > ** >=20 > 21.1.4 182 Queued >=20 > The called party is temporarily unavailable, but the server has > decided to queue the call rather than reject it. When the callee > becomes available, it will return the appropriate final status > response. The reason phrase MAY give further details about the > status of the call, for example, "5 calls queued; expected waiting > time is 15 minutes". The server MAY issue several 182 (Queued) > responses to update the caller about the status of the=20 > queued call. =20 >=20 > ** >=20 > If none of the currently defined response code is suitable=20 > semantically, would it be viable to define a new response=20 > code for this, I personally don't think so but as we may see=20 > more and more of devices like this in the future, may be? > =20 > Another option is I guess is to use current 18x + Alert-Info=20 > URN to indicate what's happening on the callee side. >=20 > Regards > Shida >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Tue Jun 22 06:32:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82BB23A6802 for ; Tue, 22 Jun 2010 06:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.463 X-Spam-Level: X-Spam-Status: No, score=-9.463 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a53nTmAYX2r5 for ; Tue, 22 Jun 2010 06:31:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2E0DD3A679F for ; Tue, 22 Jun 2010 06:31:59 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPNXIExAZnwN/2dsb2JhbACfFXGmQppOglEBgkkE X-IronPort-AV: E=Sophos;i="4.53,460,1272844800"; d="scan'208";a="124282203" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2010 13:32:06 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5MDW5U6012369; Tue, 22 Jun 2010 13:32:06 GMT Message-ID: <4C20BB53.1030808@cisco.com> Date: Tue, 22 Jun 2010 09:32:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: SIPCORE Subject: Re: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 13:32:00 -0000 Maybe the safest/simplest approach would be to simply send a 100 Trying. Thanks, Paul Christer Holmberg wrote: > Hi Shida, > > Without having an opinon which response code would be the most appropriate, please keep in mind that a 18x response does create an early dialog, so even if the terminal maybe doesn't need to process SDP at that point it may have create a route set etc. > > Regards, > > Christer > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Shida Schubert >> Sent: 22. kesäkuuta 2010 8:11 >> To: SIPCORE >> Subject: [sipcore] ECO(energy-saving) device and response code >> >> >> We have a device from several vendors on our test bed (and >> will be deployed in near future) that goes into sleep mode >> (energy saving mode) when standing by. >> >> It takes about 10 seconds for these devices to wake up and >> although it can't process the SDP and other parameters in >> INVITE while resuming, it can be configured to send a response. >> >> Question is what response should be sent to indicate to the >> caller the following semantics. >> >> "device on the callee side is waking up to decide whether it >> can handle the call or if it's interested in picking up the >> call at all". >> >> The response code that kind of match the semantic is the 182 >> "Queued", based on the definition in RFC3261 or 183 "Session >> Progress" but we can't seem to come to agreement internally, >> so I was hoping to get some opinions on this.. >> >> ** >> >> 21.1.4 182 Queued >> >> The called party is temporarily unavailable, but the server has >> decided to queue the call rather than reject it. When the callee >> becomes available, it will return the appropriate final status >> response. The reason phrase MAY give further details about the >> status of the call, for example, "5 calls queued; expected waiting >> time is 15 minutes". The server MAY issue several 182 (Queued) >> responses to update the caller about the status of the >> queued call. >> >> ** >> >> If none of the currently defined response code is suitable >> semantically, would it be viable to define a new response >> code for this, I personally don't think so but as we may see >> more and more of devices like this in the future, may be? >> >> Another option is I guess is to use current 18x + Alert-Info >> URN to indicate what's happening on the callee side. >> >> Regards >> Shida >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Tue Jun 22 06:47:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108CA3A67AC for ; Tue, 22 Jun 2010 06:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEHZSXyd5FW9 for ; Tue, 22 Jun 2010 06:47:34 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 459533A6359 for ; Tue, 22 Jun 2010 06:47:34 -0700 (PDT) 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; Tue, 22 Jun 2010 06:47:41 -0700 From: Brett Tate To: SIPCORE Date: Tue, 22 Jun 2010 06:46:30 -0700 Thread-Topic: [sipcore] ECO(energy-saving) device and response code Thread-Index: AcsSD1F8SthzQb3rRc+mz4asRAR5NwAAD20w Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD52B07@EXMBXCLUS01.citservers.local> References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> <4C20BB53.1030808@cisco.com> In-Reply-To: <4C20BB53.1030808@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: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 13:47:35 -0000 I agree with Paul; however some callers might not like the delay before rec= eiving a progression notice. Thus something better (like a 183) may be nee= ded. In case you also needed something similar for non INVITE requests, RFC 4320= imposes some 1xx restrictions. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Tuesday, June 22, 2010 9:32 AM > To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] ECO(energy-saving) device and response code >=20 > Maybe the safest/simplest approach would be to simply send a 100 > Trying. >=20 > Thanks, > Paul From dworley@avaya.com Tue Jun 22 13:00:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9303A69DD for ; Tue, 22 Jun 2010 13:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvJVGiFqP9vQ for ; Tue, 22 Jun 2010 13:00:54 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id A4EF93A69E6 for ; Tue, 22 Jun 2010 13:00:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,461,1272859200"; d="scan'208";a="21867329" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Jun 2010 16:01:01 -0400 X-IronPort-AV: E=Sophos;i="4.53,461,1272859200"; d="scan'208";a="474949962" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Jun 2010 16:00:21 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 22 Jun 2010 16:00:20 -0400 From: "WORLEY, Dale R (Dale)" To: Shida Schubert , SIPCORE Date: Tue, 22 Jun 2010 15:57:10 -0400 Thread-Topic: [sipcore] ECO(energy-saving) device and response code Thread-Index: AcsRyU/B+u9HLYjBSH28VWD2wEEk1AAe8nD7 Message-ID: References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> In-Reply-To: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.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: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:00:55 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Shid= a Schubert [shida@ntt-at.com] It takes about 10 seconds for these devices to wake up and although it can't process the SDP and other parameters in INVITE while resuming, it can be configured to send a response. Question is what response should be sent to indicate to the caller the following semantics. "device on the callee side is waking up to decide whether it can handle the call or if it's interested in picking up the call at all". _______________________________________________ 100 or 183 Call Progress seems best. 182 Queued suggests that there is an= actual queue and the UA might be expected to tell something about the queu= e. (Although that could be faked easily enough.) 100 ought to be adequate= ; it would quench resends and prevent rolling over to alternative destinati= ons. Would the UAC be disturbed by the 10 sec delay between the 100 and th= e first non-trivial response? When you say the device "can't process the SDP", I assume that it can store= the INVITE for processing when the device wakes up. Indeed, your choice o= f actions might be limited by what the device is capable of while sleeping. Dale From richard@shockey.us Wed Jun 23 18:59:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366733A6911 for ; Wed, 23 Jun 2010 18:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl-7BEVILGyJ for ; Wed, 23 Jun 2010 18:59:37 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 5E9EC3A68FB for ; Wed, 23 Jun 2010 18:59:37 -0700 (PDT) Received: (qmail 9000 invoked by uid 0); 24 Jun 2010 01:59:45 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 24 Jun 2010 01:59:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=KgmjBzFCrf7adlPbFFAONdWL35svRP3MBqEeLuU5l9d9UQY6oC/veqMHTTJy700vECuhylxJ4dRMY9NElZeYVgOfpYlkcUJMbJIEkQSk5wpR8mNiQYvb5wvl6E5107xF; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1ORbjF-0001Qd-2o; Wed, 23 Jun 2010 19:59:45 -0600 From: "Richard Shockey" To: , , Date: Wed, 23 Jun 2010 21:59:35 -0400 Message-ID: <001201cb1340$e6106560$b2313020$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CB131F.5EFEC560" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsTQOT9Tjy5VyAeTMyCJ4Qb553FpQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: [sipcore] By any chance does anyone know who is the SIP guy/gal at Apple? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 01:59:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01CB131F.5EFEC560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Aka FaceTime? Some of us in the RAI directorate would like to extend a welcoming hand. J Plus see what the SDP looks like etc , interop options, naming, where is the rendezvous server, etal. Small stuff. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ------=_NextPart_000_0013_01CB131F.5EFEC560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Aka FaceTime?

 

Some of us in the RAI directorate would like to = extend a welcoming hand. J =

 

Plus see what the SDP looks like etc , interop = options, naming, where is the rendezvous server, etal.

 

Small stuff.

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype: rshockey101
LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org

 

------=_NextPart_000_0013_01CB131F.5EFEC560-- From gonzalo.camarillo@ericsson.com Thu Jun 24 00:10:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E5A3A6A41 for ; Thu, 24 Jun 2010 00:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.828 X-Spam-Level: X-Spam-Status: No, score=-103.828 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVFMi6Q4KNID for ; Thu, 24 Jun 2010 00:10:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 45F5C3A6960 for ; Thu, 24 Jun 2010 00:10:58 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-b4-4c230508917c Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 26.4E.10125.805032C4; Thu, 24 Jun 2010 09:11:04 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jun 2010 09:11:04 +0200 Received: from [131.160.126.160] ([131.160.126.160]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jun 2010 09:11:03 +0200 Message-ID: <4C230507.10105@ericsson.com> Date: Thu, 24 Jun 2010 10:11:03 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2010 07:11:04.0331 (UTC) FILETIME=[68A635B0:01CB136C] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 07:11:00 -0000 Folks, per the our mailing list discussions, I have edited Section 3.5 of the draft so that the rules to detect and address glare conditions are clearer, more explicit, and less restrictive. Let me know if the new text meets any of these three goals :o) Below you have the new Section 3.5. You can check the old version at: http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5 Once we agree on the contents of this section, Section 4.5 will not need to define further rules. Comments are welcome. Thanks, Gonzalo 3.5. Glare Situations Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user agent receiving an offer after having sent one but before having received an answer to it. That section specifies rules to avoid glare situations in most cases. When despite following those rules a glare conditions occurs (as a result of a race condition), it is handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. The UAS returns a 491 (Request Pending) response and the UAC retries the offer after a randomly-selected time, which depends on which user agent is the owner of the Call-ID of the dialog. The rules in RFC 3261 [RFC3261] not only cover collisions between re-INVITEs that contain offers; they cover collisions between two re-INVITEs in general, even if they do not contain offers. Sections 5.2 and 5.3 of RFC 3311 [RFC3311] extend those rules to also cover collisions between an UPDATE request carrying an offer and another message (UPDATE, PRACK or INVITE) also carrying an offer. Since re-INVITEs and UPDATEs can change not only the session state but also the dialog state, collisions among them need to be avoided even when they do not carry offers. Therefore, this document extends the rules just described to also cover collisions that do not involve offers. A UA that receives an UPDATE request on a dialog while an UPDATE request it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received UPDATE request. If a UA receives a re-INVITE while an UPDATE request it had sent on that dialog is in progress and after receiving the re-INVITE the UA receives a 2xx response to the UPDATE request, the UA SHOULD generate a new UPDATE request or a reliable response to the re-INVITE in order to make sure that both UAs have a common view of the state of the session, as described in Section 3.4. The rules in RFC 3261 [RFC3261] do not cover collisions between an UPDATE request and a reliable response to a re-INVITE (non-2xx final responses to the re-INVITE are also considered reliable responses). Since both the UPDATE request and the reliable response could be requesting changes to the dialog or session state, it would not be clear which changes would need to be executed first. If the UAS of a re-INVITE transaction receives and UPDATE request after having sent a reliable response to the re-INVITE but before having received the corresponding ACK or PRACK request, the UA SHOULD return a 491 (Request Pending) response to the UPDATE request. If the UAC of a re-INVITE transaction sends an UPDATE request, receives a reliable response to the re-INVITE, and then a 2xx response to the UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE request in order to make sure that both UAs have a common view of the state of the session, as described in Section 3.4. If a UA receives a 491 response to an UPDATE request, it follows the rules in Section 5.3 of RFC 3311 [RFC3311]. From shida@ntt-at.com Thu Jun 24 02:05:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C053A6979 for ; Thu, 24 Jun 2010 02:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLyuwlXhrOn4 for ; Thu, 24 Jun 2010 02:05:45 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.56.150.8]) by core3.amsl.com (Postfix) with SMTP id CB2343A680B for ; Thu, 24 Jun 2010 02:05:45 -0700 (PDT) Received: (qmail 7019 invoked from network); 24 Jun 2010 09:12:04 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway15.websitewelcome.com with SMTP; 24 Jun 2010 09:12:04 -0000 Received: from flh1agc175.tky.mesh.ad.jp ([60.239.252.175]:53381 helo=[192.168.1.14]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1ORiNa-0002SJ-TW; Thu, 24 Jun 2010 04:05:51 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Thu, 24 Jun 2010 18:05:51 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <073A787C-4204-4AF2-844C-FC3E117881FC@ntt-at.com> References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> To: "WORLEY, Dale R (Dale)" X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: SIPCORE Subject: Re: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 09:05:46 -0000 Thanks for the feedback guys.=20 As far as I know we couldn't use 100 Trying because the=20 Home-GW at our subscriber's home forks the INVITE=20 to all the registered devices and if it doesn't=20 get any 1xx(EXCEPT 100) or 2xx within 5 seconds, it=20 CANCELS all the branches and sends back an error=20 response. The reason the CANCEL procedure takes place=20 after 5 seconds is because there may be call-forward/diversion/ voicemail set up for that subscriber. Furthermore sending no=20 indication for 10 seconds seems tad bit unfriendly..=20 =20 Anyways, I guess defining a new status code is out of=20 question as people are suggesting the use of 183.=20 Thanks again. Shida On Jun 23, 2010, at 4:57 AM, WORLEY, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of = Shida Schubert [shida@ntt-at.com] >=20 > It takes about 10 seconds for these devices to wake up and > although it can't process the SDP and other parameters in > INVITE while resuming, it can be configured to send a > response. >=20 > Question is what response should be sent to > indicate to the caller the following semantics. >=20 > "device on the callee side is waking up to decide > whether it can handle the call or if it's interested in > picking up the call at all". > _______________________________________________ >=20 > 100 or 183 Call Progress seems best. 182 Queued suggests that there = is an actual queue and the UA might be expected to tell something about = the queue. (Although that could be faked easily enough.) 100 ought to = be adequate; it would quench resends and prevent rolling over to = alternative destinations. Would the UAC be disturbed by the 10 sec = delay between the 100 and the first non-trivial response? >=20 > When you say the device "can't process the SDP", I assume that it can = store the INVITE for processing when the device wakes up. Indeed, your = choice of actions might be limited by what the device is capable of = while sleeping. >=20 > Dale From James.Winterbottom@andrew.com Thu Jun 24 02:08:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ACB73A6813 for ; Thu, 24 Jun 2010 02:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lgvgp4xGlqa for ; Thu, 24 Jun 2010 02:08:01 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 8DCF03A66B4 for ; Thu, 24 Jun 2010 02:08:01 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:36522 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S24846185Ab0FXJIJ convert rfc822-to-8bit (ORCPT ); Thu, 24 Jun 2010 04:08:09 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 24 Jun 2010 04:08:09 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 24 Jun 2010 17:08:06 +0800 From: "Winterbottom, James" To: Shida Schubert , "WORLEY, Dale R (Dale)" Date: Thu, 24 Jun 2010 17:07:21 +0800 Thread-Topic: [sipcore] ECO(energy-saving) device and response code Thread-Index: AcsTfHaCMxKFeBQLS9yUzZZl53J3egAADD9L Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E7AE3DA9@SISPE7MB1.commscope.com> References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> , <073A787C-4204-4AF2-844C-FC3E117881FC@ntt-at.com> In-Reply-To: <073A787C-4204-4AF2-844C-FC3E117881FC@ntt-at.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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: SIPCORE Subject: Re: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 09:08:02 -0000 One must ask the question why a device has to be so dormant as to take 10 seconds to wake up Shida. 10 seconds is almost an eternity in the digital age. Cheers James ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Shida Schubert [shida@ntt-at.com] Sent: Thursday, June 24, 2010 4:05 AM To: WORLEY, Dale R (Dale) Cc: SIPCORE Subject: Re: [sipcore] ECO(energy-saving) device and response code Thanks for the feedback guys. As far as I know we couldn't use 100 Trying because the Home-GW at our subscriber's home forks the INVITE to all the registered devices and if it doesn't get any 1xx(EXCEPT 100) or 2xx within 5 seconds, it CANCELS all the branches and sends back an error response. The reason the CANCEL procedure takes place after 5 seconds is because there may be call-forward/diversion/ voicemail set up for that subscriber. Furthermore sending no indication for 10 seconds seems tad bit unfriendly.. Anyways, I guess defining a new status code is out of question as people are suggesting the use of 183. Thanks again. Shida On Jun 23, 2010, at 4:57 AM, WORLEY, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Shida Schubert [shida@ntt-at.com] > > It takes about 10 seconds for these devices to wake up and > although it can't process the SDP and other parameters in > INVITE while resuming, it can be configured to send a > response. > > Question is what response should be sent to > indicate to the caller the following semantics. > > "device on the callee side is waking up to decide > whether it can handle the call or if it's interested in > picking up the call at all". > _______________________________________________ > > 100 or 183 Call Progress seems best. 182 Queued suggests that there is an actual queue and the UA might be expected to tell something about the queue. (Although that could be faked easily enough.) 100 ought to be adequate; it would quench resends and prevent rolling over to alternative destinations. Would the UAC be disturbed by the 10 sec delay between the 100 and the first non-trivial response? > > When you say the device "can't process the SDP", I assume that it can store the INVITE for processing when the device wakes up. Indeed, your choice of actions might be limited by what the device is capable of while sleeping. > > Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From gao.yang2@zte.com.cn Thu Jun 24 03:53:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC5D3A63D3 for ; Thu, 24 Jun 2010 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.338 X-Spam-Level: X-Spam-Status: No, score=-98.338 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9jvID48mY-5 for ; Thu, 24 Jun 2010 03:53:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D054A3A6910 for ; Thu, 24 Jun 2010 03:53:08 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 552341727820181; Thu, 24 Jun 2010 18:52:49 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 33713.2980680612; Thu, 24 Jun 2010 18:46:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5OAqxYh045037; Thu, 24 Jun 2010 18:52:59 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C230507.10105@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 24 Jun 2010 18:48:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-24 18:52:44, Serialize complete at 2010-06-24 18:52:44 Content-Type: multipart/alternative; boundary="=_alternative 003BB3D74825774C_=" X-MAIL: mse2.zte.com.cn o5OAqxYh045037 Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 10:53:10 -0000 This is a multipart message in MIME format. --=_alternative 003BB3D74825774C_= Content-Type: text/plain; charset="US-ASCII" Hi Gonzalo, Thanks for your work at this topic. Two comments inlines. Cheers, Gao > 3.5. Glare Situations > > Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user > agent receiving an offer after having sent one but before having > received an answer to it. That section specifies rules to avoid > glare situations in most cases. When despite following those rules a > glare conditions occurs (as a result of a race condition), it is > handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. > The UAS returns a 491 (Request Pending) response and the UAC retries > the offer after a randomly-selected time, which depends on which user > agent is the owner of the Call-ID of the dialog. The rules in RFC > 3261 [RFC3261] not only cover collisions between re-INVITEs that > contain offers; they cover collisions between two re-INVITEs in > general, even if they do not contain offers. Sections 5.2 and 5.3 of > RFC 3311 [RFC3311] extend those rules to also cover collisions > between an UPDATE request carrying an offer and another message > (UPDATE, PRACK or INVITE) also carrying an offer. > > Since re-INVITEs and UPDATEs can change not only the session state > but also the dialog state, collisions among them need to be avoided > even when they do not carry offers. Therefore, this document extends > the rules just described to also cover collisions that do not involve > offers. > > A UA that receives an UPDATE request on a dialog while an UPDATE > request it had sent on that dialog is in progress MUST return a 491 > (Request Pending) response to the received UPDATE request. > > If a UA receives a re-INVITE while an UPDATE request it had sent on > that dialog is in progress and after receiving the re-INVITE the UA > receives a 2xx response to the UPDATE request, the UA SHOULD generate > a new UPDATE request or a reliable response to the re-INVITE in order > to make sure that both UAs have a common view of the state of the > session, as described in Section 3.4. > > The rules in RFC 3261 [RFC3261] do not cover collisions between an > UPDATE request and a reliable response to a re-INVITE (non-2xx final > responses to the re-INVITE are also considered reliable responses). > Since both the UPDATE request and the reliable response could be > requesting changes to the dialog or session state, it would not be > clear which changes would need to be executed first. Here, the text points out the problem, but without handling rule. I guess adding some words like "re-send a new Re-INVITE or UPDATE to synchronize state" would be better. > > If the UAS of a re-INVITE transaction receives and UPDATE request > after having sent a reliable response to the re-INVITE but before > having received the corresponding ACK or PRACK request, the UA SHOULD > return a 491 (Request Pending) response to the UPDATE request. This rule would make non-offer/answer UPDATE out side of PRACK/200OK of 100rel 18x. But I am OK with this, because I saw many UAs can not handle parallel UPDATE with PRACK/200OK. And current UAC of this parallel UPDATE might not need to change to send the UPDATE after the PRACK/200OK designedly, as the UAS(of UPDATE) would reject it by 491 and the UA can re-send it later. But I am not sure whether the Ini-INVITE should have the same rule for this case. >If the UAC of a re-INVITE transaction sends an UPDATE request, receives > a reliable response to the re-INVITE, and then a 2xx response to the > UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE > request in order to make sure that both UAs have a common view of the > state of the session, as described in Section 3.4. > > If a UA receives a 491 response to an UPDATE request, it follows the > rules in Section 5.3 of RFC 3311 [RFC3311]. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003BB3D74825774C_= Content-Type: text/html; charset="US-ASCII"
Hi Gonzalo,

Thanks for your work at this topic.

Two comments inlines.

Cheers,

Gao

> 3.5.  Glare Situations
>
>    Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user
>    agent receiving an offer after having sent one but before having
>    received an answer to it.  That section specifies rules to avoid
>    glare situations in most cases.  When despite following those rules a
>    glare conditions occurs (as a result of a race condition), it is
>    handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261].
>    The UAS returns a 491 (Request Pending) response and the UAC retries
>    the offer after a randomly-selected time, which depends on which user
>    agent is the owner of the Call-ID of the dialog.  The rules in RFC
>    3261 [RFC3261] not only cover collisions between re-INVITEs that
>    contain offers; they cover collisions between two re-INVITEs in
>    general, even if they do not contain offers.  Sections 5.2 and 5.3 of
>    RFC 3311 [RFC3311] extend those rules to also cover collisions
>    between an UPDATE request carrying an offer and another message
>    (UPDATE, PRACK or INVITE) also carrying an offer.
>
>    Since re-INVITEs and UPDATEs can change not only the session state
>    but also the dialog state, collisions among them need to be avoided
>    even when they do not carry offers.  Therefore, this document extends
>    the rules just described to also cover collisions that do not involve
>    offers.
>
>    A UA that receives an UPDATE request on a dialog while an UPDATE
>    request it had sent on that dialog is in progress MUST return a 491
>    (Request Pending) response to the received UPDATE request.
>
>    If a UA receives a re-INVITE while an UPDATE request it had sent on
>    that dialog is in progress and after receiving the re-INVITE the UA
>    receives a 2xx response to the UPDATE request, the UA SHOULD generate
>    a new UPDATE request or a reliable response to the re-INVITE in order
>    to make sure that both UAs have a common view of the state of the
>    session, as described in Section 3.4.
>
>    The rules in RFC 3261 [RFC3261] do not cover collisions between an
>    UPDATE request and a reliable response to a re-INVITE (non-2xx final
>    responses to the re-INVITE are also considered reliable responses).
>    Since both the UPDATE request and the reliable response could be
>    requesting changes to the dialog or session state, it would not be
>    clear which changes would need to be executed first.

Here, the text points out the problem, but without handling rule. I guess adding some words like "re-send a new Re-INVITE or UPDATE to synchronize state" would be better.

>
>    If the UAS of a re-INVITE transaction receives and UPDATE request
>    after having sent a reliable response to the re-INVITE but before
>    having received the corresponding ACK or PRACK request, the UA SHOULD
>    return a 491 (Request Pending) response to the UPDATE request.

This rule would make non-offer/answer UPDATE out side of PRACK/200OK of 100rel 18x. But I am OK with this, because I saw many UAs can not handle parallel UPDATE with PRACK/200OK. And current UAC of this parallel UPDATE might not need to change to send the UPDATE after the PRACK/200OK designedly, as the UAS(of UPDATE) would reject it by 491 and the UA can re-send it later.

But I am not sure whether the Ini-INVITE should have the same rule for this case.
 
>If the UAC of a re-INVITE transaction sends an UPDATE request, receives
>    a reliable response to the re-INVITE, and then a 2xx response to the
>    UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE
>    request in order to make sure that both UAs have a common view of the
>    state of the session, as described in Section 3.4.
>
>    If a UA receives a 491 response to an UPDATE request, it follows the
>    rules in Section 5.3 of RFC 3311 [RFC3311].
  

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003BB3D74825774C_=-- From shinji.okumura@softfront.jp Thu Jun 24 04:05:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1694E3A6875 for ; Thu, 24 Jun 2010 04:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.212 X-Spam-Level: X-Spam-Status: No, score=-95.212 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Gjq21isDITd for ; Thu, 24 Jun 2010 04:05:49 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id E6F113A684D for ; Thu, 24 Jun 2010 04:05:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 1F290428010; Thu, 24 Jun 2010 20:05:55 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FaUeHJa4Qlo; Thu, 24 Jun 2010 20:05:50 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 6424E42800F; Thu, 24 Jun 2010 20:05:49 +0900 (JST) From: OKUMURA Shinji To: SIPCORE Date: Thu, 24 Jun 2010 20:05:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C230507.10105@ericsson.com> References: <4C230507.10105@ericsson.com> Message-Id: Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 11:05:52 -0000 Hi Gonzalo, Gonzalo Camarillo Thu, 24 Jun 2010 10:11:03 +0300 >Folks, > >per the our mailing list discussions, I have edited Section 3.5 of the >draft so that the rules to detect and address glare conditions are >clearer, more explicit, and less restrictive. Let me know if the new >text meets any of these three goals :o) > >Below you have the new Section 3.5. You can check the old version at: > >http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5 > >Once we agree on the contents of this section, Section 4.5 will not need >to define further rules. > >Comments are welcome. > >Thanks, > >Gonzalo > > >3.5. Glare Situations > > Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user > agent receiving an offer after having sent one but before having > received an answer to it. That section specifies rules to avoid > glare situations in most cases. When despite following those rules a > glare conditions occurs (as a result of a race condition), it is > handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. > The UAS returns a 491 (Request Pending) response and the UAC retries > the offer after a randomly-selected time, which depends on which user > agent is the owner of the Call-ID of the dialog. The rules in RFC > 3261 [RFC3261] not only cover collisions between re-INVITEs that > contain offers; they cover collisions between two re-INVITEs in > general, even if they do not contain offers. Sections 5.2 and 5.3 of > RFC 3311 [RFC3311] extend those rules to also cover collisions > between an UPDATE request carrying an offer and another message > (UPDATE, PRACK or INVITE) also carrying an offer. > > Since re-INVITEs and UPDATEs can change not only the session state > but also the dialog state, collisions among them need to be avoided > even when they do not carry offers. Therefore, this document extends > the rules just described to also cover collisions that do not involve > offers. > > A UA that receives an UPDATE request on a dialog while an UPDATE > request it had sent on that dialog is in progress MUST return a 491 > (Request Pending) response to the received UPDATE request. I like this rule. > If a UA receives a re-INVITE while an UPDATE request it had sent on > that dialog is in progress and after receiving the re-INVITE the UA > receives a 2xx response to the UPDATE request, the UA SHOULD generate > a new UPDATE request or a reliable response to the re-INVITE in order > to make sure that both UAs have a common view of the state of the > session, as described in Section 3.4. Various cases are possible, A B | | |UPDATE(offer1) | |=================================>| | 2xx-UPD(answer1)| |<---------\ /====================| | \/ | | /\ re-INVITE(offer2)| |<=========/ \--------------------| |491-INV | |--------------------------------->| | | A B | | |UPDATE(offer1) re-INVITE(offer2)| |=============\ /-----------------| | \/ | | /\ | |<------------/ \================>| |491-INV | |--------------------------------->| | 491-UPD| |<=================================| | | At least, if the UPDATE has an offer, I think the UA-A SHOULD return a 491 response to the reINVITE. This is simpler and does't contradict a current rule. > The rules in RFC 3261 [RFC3261] do not cover collisions between an > UPDATE request and a reliable response to a re-INVITE (non-2xx final > responses to the re-INVITE are also considered reliable responses). > Since both the UPDATE request and the reliable response could be > requesting changes to the dialog or session state, it would not be > clear which changes would need to be executed first. > > If the UAS of a re-INVITE transaction receives and UPDATE request > after having sent a reliable response to the re-INVITE but before > having received the corresponding ACK or PRACK request, the UA SHOULD > return a 491 (Request Pending) response to the UPDATE request. I think this rule is more restrictive. IMO; In case that the reliable response is 18x, the UA SHOULD return a "500" response. In case that the reliable response is 2xx; If the 2xx carries an offer, the UA SHOULD return a "500" response. Otherwise, the UA MAY return a 2xx response. In case that the reliable response is 4xx, the UA MAY return a 2xx response. > If > the UAC of a re-INVITE transaction sends an UPDATE request, receives > a reliable response to the re-INVITE, and then a 2xx response to the > UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE > request in order to make sure that both UAs have a common view of the > state of the session, as described in Section 3.4. In case that the reliable response is 4xx, this rule is necessary from an offer-answer perspective. In case that the reliable response is 2xx or 18x, this rule seems to be also necessary from a remote-target perspective. But I'm not sure at present. > If a UA receives a 491 response to an UPDATE request, it follows the > rules in Section 5.3 of RFC 3311 [RFC3311]. And I think the rules are insufficient. In the cases below, UA-A SHOULD send new offer after sending ACK. A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| non-2xx|s1 | /--------------|<-+ |UPDATE(offer2) / |s0| |==============/===============>| | accept UPDATE | / 2xx-UPD(answer2)| | |<===========/==================| | s2| / ACK |s2| |<---------/ ----------->| | s0|ACK | | |-------------> | | |UPDATE(offer0) | | |==============================>| | | 2xx-UPD(answer0)| | |<==============================| | s0| |s0| | | v A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| non-2xx|s1 | /------------|<-+ | / ACK |s0| | / -------->| | accept UPDATE | / UPDATE(offer2)| | |<=============/================| | |2xx-UPD(answer2) | | |============/=================>| | s2| / |s2| |<---------/ | | s0|ACK | | |-----------> | | |UPDATE(offer0) | | |==============================>| | | 2xx-UPD(answer0)| | |<==============================| | s0| |s0| | | v Regards, Shinji From adam@nostrum.com Thu Jun 24 08:00:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37A228C0DC for ; Thu, 24 Jun 2010 08:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIp4YOwF43ss for ; Thu, 24 Jun 2010 08:00:59 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9621228C0ED for ; Thu, 24 Jun 2010 08:00:58 -0700 (PDT) Received: from [172.16.3.81] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5OF131M095206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jun 2010 10:01:04 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C23732F.2070709@nostrum.com> Date: Thu, 24 Jun 2010 10:01:03 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Shida Schubert References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> <073A787C-4204-4AF2-844C-FC3E117881FC@ntt-at.com> In-Reply-To: <073A787C-4204-4AF2-844C-FC3E117881FC@ntt-at.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "WORLEY, Dale R \(Dale\)" , SIPCORE Subject: Re: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 15:00:59 -0000 On 06/24/2010 04:05 AM, Shida Schubert wrote: > Anyways, I guess defining a new status code is out of > question as people are suggesting the use of 183. > [as participant] I'm not sure that's the conclusion you should draw. Sure, 183 will probably work, but it was really intended more for "we're interworking with some other network, and it's told us about some form of progress that doesn't map into any of the SIP provisional responses." It seems reasonable to define something like a "184 Waking Up" status code that informs whatever is upstream that you can't really answer right now, but should be able to in a few seconds. You might even throw in a new header field that informs the UAC how long it should take to get a better response to them; a forking proxy could take this value into account when it make decisions (regarding things like serial forking, etc). I suspect that your situation is the first of many that will involve SIP and extremely low power devices, and that handling these kinds of situations gracefully will probably be very important in the next few years. /a From root@core3.amsl.com Thu Jun 24 12:30:08 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DCC1F3A6963; Thu, 24 Jun 2010 12:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100624193002.DCC1F3A6963@core3.amsl.com> Date: Thu, 24 Jun 2010 12:30:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 19:30:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, et al. Filename : draft-ietf-sipcore-rfc4244bis-01.txt Pages : 43 Date : 2010-06-24 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines an optional SIP header, History-Info, for capturing the history information in requests. A SIP/SIPS URI parameter is defined to tag information necessary to populate the History-Info header. In addition, this document defines a value for the Privacy header specific to the History-Info header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-rfc4244bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-24122202.I-D@ietf.org> --NextPart-- From dworley@avaya.com Thu Jun 24 12:36:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48053A6855 for ; Thu, 24 Jun 2010 12:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR5ihAon2Vh3 for ; Thu, 24 Jun 2010 12:36:12 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 00E0F3A69F3 for ; Thu, 24 Jun 2010 12:36:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,475,1272859200"; d="scan'208";a="22239809" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 24 Jun 2010 15:36:19 -0400 X-IronPort-AV: E=Sophos;i="4.53,475,1272859200"; d="scan'208";a="486223909" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jun 2010 15:36:19 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 24 Jun 2010 15:36:18 -0400 From: "WORLEY, Dale R (Dale)" To: Shida Schubert Date: Thu, 24 Jun 2010 15:36:18 -0400 Thread-Topic: [sipcore] ECO(energy-saving) device and response code Thread-Index: AcsTfHQnCEvf6VK8QjSTVMd/VS0maAAVvoca Message-ID: References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> , <073A787C-4204-4AF2-844C-FC3E117881FC@ntt-at.com> In-Reply-To: <073A787C-4204-4AF2-844C-FC3E117881FC@ntt-at.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: SIPCORE Subject: Re: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 19:36:18 -0000 ________________________________________ From: Shida Schubert [shida@ntt-at.com] As far as I know we couldn't use 100 Trying because the Home-GW at our subscriber's home forks the INVITE to all the registered devices and if it doesn't get any 1xx(EXCEPT 100) or 2xx within 5 seconds, it CANCELS all the branches and sends back an error response. The reason the CANCEL procedure takes place after 5 seconds is because there may be call-forward/diversion/ voicemail set up for that subscriber. Furthermore sending no indication for 10 seconds seems tad bit unfriendly.. Anyways, I guess defining a new status code is out of question as people are suggesting the use of 183. _______________________________________ I agree with Adam that these issues are probably going to be of interest to= many implementations over the long term. I would not exclude defining a new 18x code. In theory, any non-100 1xx co= de should have the same effect as any other for this sort of purpose, and e= verybody expects that 18x codes describe call progress. So (e.g.) 184 shou= ld not confuse any existing device. The question is whether we want to dis= tinguish 183 "Call Progress" from this situation. As Adam notes, we may wa= nt to standardize an indication of how long it will be before a "real" prov= isional response comes. ("Expires" header?) I'm more curious about the behavior of your device, having worked on "fallb= ack" problems in sipXecs. In sipXecs, any destination has about 2.5 second= s to provide a 100 response (or some other response) before it is declared = nonresponding and the call rolls over to the next destination in the RFC 32= 63 set or the next fork. But once the 100 is seen, the destination is assu= med live and is given the full expiration time to provide a 2xx response. = (And if it does not, no other RFC 3263 destination is tried, but we go on t= o the next fork.) In your device, a 100 response isn't sufficient for the device to be consid= ered live, and it's not clear to me why that is. Conversely, if the device= can wake up and provide a 184 response, the user may still not answer and = the call could progress to diverted destinations. So it doesn't seem to me= that you're going to get the effect you want unless there are further comp= lications that you haven't described (such as the device won't send 100 if = it knows that the user has set call-forwarding). Dale From mary.ietf.barnes@gmail.com Thu Jun 24 13:11:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027D93A6A63 for ; Thu, 24 Jun 2010 13:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Auh6QEdw-l9M for ; Thu, 24 Jun 2010 13:11:13 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 96B9D3A6A5E for ; Thu, 24 Jun 2010 13:11:13 -0700 (PDT) Received: by pzk36 with SMTP id 36so445097pzk.31 for ; Thu, 24 Jun 2010 13:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=G/f5/FwC8vlGSe83tNgxpwe1FoUY24toPXiUpuU4Y4g=; b=r1iOOzGkTpOInb63TZo2m1DvB18Ts4cafmuePZshiwDs7P130DLBw86RQ6jaoISi7z FtW4ms8GyV1nLvUaHmmEvPncvo/e+J5Y21GbPXIkuthyES+KhkNjdMtdkO+7PtS1UdF2 d/HrSc3dsTY0NwrFOUUB0PXLhyjwVROoKhk+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=P+U1giDV08vNI+k+3QrpTNazW76xDV3RXb6FXkDAyT48EzLiee09q8iZ+zE/PkY+P1 TiuCQ+nb4VktErrEh1outgRi56nKiragYylx2WzYcoqXdi1P0c2lGu5vbQXAdYaHEG0k vtil+a+UIRDYBzjXYvAvJMm7XsapsCKUjcp9w= MIME-Version: 1.0 Received: by 10.114.237.3 with SMTP id k3mr10189429wah.219.1277410279566; Thu, 24 Jun 2010 13:11:19 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Thu, 24 Jun 2010 13:11:19 -0700 (PDT) Date: Thu, 24 Jun 2010 15:11:19 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 20:11:15 -0000 Hi folks, The 4244bis draft has been updated and a separate call flow document created per the earlier summary of proposed changes: http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.txt There are two voicemail examples in the new call flow document. The 4244bis has 3 call flows - the basic sequential forking and two privacy examples. All the rest are now in the call flow document. The other changes we made were updates to the UAC, UAS and application considerations section - adding additional text as to how the UAC and UAS process hi-entries (including related to responses). The application considerations section now describes how the tags can be used to derive specific information and the past guidelines were removed since 4244bis has much definitive guidance on the normative aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via anonymization rather than removing entries, etc.) as summarized in Section 11. Please review and provide any additional comments. We believe that 4244bis is pretty much ready to go. We can fine tune the details in the call flows and should be able to get that ready very soon, as well. Let us know if you see additional use cases you would like to add. Thanks, Mary et al From shinji.okumura@softfront.jp Thu Jun 24 23:11:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A9B3A6924 for ; Thu, 24 Jun 2010 23:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.292 X-Spam-Level: X-Spam-Status: No, score=-95.292 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDA161jyjitR for ; Thu, 24 Jun 2010 23:11:29 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 30BB73A690E for ; Thu, 24 Jun 2010 23:11:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 448DB428014; Fri, 25 Jun 2010 15:11:36 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOVT6Gq1oz+f; Fri, 25 Jun 2010 15:11:31 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id B6C21428013; Fri, 25 Jun 2010 15:11:30 +0900 (JST) From: OKUMURA Shinji To: SIPCORE Date: Fri, 25 Jun 2010 15:11:22 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C230507.10105@ericsson.com> References: <4C230507.10105@ericsson.com> Message-Id: <26CB142D3C24B0shinji.okumura@softfront.jp> Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 06:11:30 -0000 Hi, Gonzalo Camarillo Thu, 24 Jun 2010 10:11:03 +0300 >Folks, > >per the our mailing list discussions, I have edited Section 3.5 of the >draft so that the rules to detect and address glare conditions are >clearer, more explicit, and less restrictive. Let me know if the new >text meets any of these three goals :o) > >Below you have the new Section 3.5. You can check the old version at: > >http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5 > >Once we agree on the contents of this section, Section 4.5 will not need >to define further rules. > >Comments are welcome. > >Thanks, > >Gonzalo > > >3.5. Glare Situations > > Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user > agent receiving an offer after having sent one but before having > received an answer to it. That section specifies rules to avoid > glare situations in most cases. When despite following those rules a > glare conditions occurs (as a result of a race condition), it is > handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. > The UAS returns a 491 (Request Pending) response and the UAC retries > the offer after a randomly-selected time, which depends on which user > agent is the owner of the Call-ID of the dialog. The rules in RFC > 3261 [RFC3261] not only cover collisions between re-INVITEs that > contain offers; they cover collisions between two re-INVITEs in > general, even if they do not contain offers. Sections 5.2 and 5.3 of > RFC 3311 [RFC3311] extend those rules to also cover collisions > between an UPDATE request carrying an offer and another message > (UPDATE, PRACK or INVITE) also carrying an offer. > > Since re-INVITEs and UPDATEs can change not only the session state > but also the dialog state, collisions among them need to be avoided > even when they do not carry offers. Therefore, this document extends > the rules just described to also cover collisions that do not involve > offers. > > A UA that receives an UPDATE request on a dialog while an UPDATE > request it had sent on that dialog is in progress MUST return a 491 > (Request Pending) response to the received UPDATE request. > > If a UA receives a re-INVITE while an UPDATE request it had sent on > that dialog is in progress and after receiving the re-INVITE the UA > receives a 2xx response to the UPDATE request, the UA SHOULD generate > a new UPDATE request or a reliable response to the re-INVITE in order > to make sure that both UAs have a common view of the state of the > session, as described in Section 3.4. > > The rules in RFC 3261 [RFC3261] do not cover collisions between an > UPDATE request and a reliable response to a re-INVITE (non-2xx final > responses to the re-INVITE are also considered reliable responses). > Since both the UPDATE request and the reliable response could be > requesting changes to the dialog or session state, it would not be > clear which changes would need to be executed first. > > If the UAS of a re-INVITE transaction receives and UPDATE request > after having sent a reliable response to the re-INVITE but before > having received the corresponding ACK or PRACK request, the UA SHOULD > return a 491 (Request Pending) response to the UPDATE request. For reference, here are my opinion regarding an interworking of UPDATE and re-INVITE from an offer-answer perspective. Case 1: One or more O/A exchange and then 2xx to re-INVITE with an offer. A B | | |INVITE(offer) | +-----> +->|--------------------->| | | | 1xx(answer)| Don't send UPDATE | Don't send INVITE | |<---------------------| 491 to UPDATE | 491 to INVITE | |PRACK | | | |--------------------->| | | | 2xx-PRA| +-----> | |<---------------------| may send UPDATE | | | | may acceptUPDATE | | | 2xx| | +->|<---------------------| | may send INVITE | | | | may accept INVITE | |ACK | | | |--------------------->| v v | | A B | | |INVITE(offer) | |--------------------->|<-+ <-----+ | 1xx(answer)| | | |<---------------------| | Don't send INVITE | Don't send UPDATE |PRACK | | 500 to INVITE | 500 to UPDATE |--------------------->| | | | 2xx-PRA| | | |<---------------------| | <-----+ | | | | may send UPDATE | 2xx| | | may acceptUPDATE |<---------------------|<-+ | | | | may send INVITE | |ACK | | may accept INVITE | |--------------------->| | | | | v v Case 2: One or more O/A exchange and then 4xx to re-INVITE with an offer. A B [UAC behavior] | | |INVITE(offer) | +-----> +->|--------------------->| | | | 1xx(answer)| Don't send UPDATE | Don't send INVITE | |<---------------------| 491 to UPDATE | 491 to INVITE | |PRACK | | | |--------------------->| | | | 2xx-PRA| +-----> | |<---------------------| may send UPDATE | | | | may acceptUPDATE | | | non-2xx| | +->|<---------------------| | | | | |ACK ACK | | +->|---------> -------->| v v | | (4xx and ACk to it are atomic.) A B | | [UAS behavior] |INVITE(offer) | |--------------------->|<-+ <-----+ | 1xx(answer)| | | |<---------------------| | Don't send INVITE | Don't send UPDATE |PRACK | | 500 to INVITE | 500 to UPDATE |--------------------->| | | | 2xx-PRA| | | |<---------------------| | <-----+ | | | | may send UPDATE | non-2xx| | | may accept UPDATE |<---------------------|<-+ | | | | Don't send INVITE | |ACK ACK | | may accept INVITE | |---------> -------->|<-+ | | | v v Regards, Shinji > If > the UAC of a re-INVITE transaction sends an UPDATE request, receives > a reliable response to the re-INVITE, and then a 2xx response to the > UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE > request in order to make sure that both UAs have a common view of the > state of the session, as described in Section 3.4. > > If a UA receives a 491 response to an UPDATE request, it follows the > rules in Section 5.3 of RFC 3311 [RFC3311]. From gao.yang2@zte.com.cn Thu Jun 24 23:55:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CDE3A684B for ; Thu, 24 Jun 2010 23:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.686 X-Spam-Level: X-Spam-Status: No, score=-97.686 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-QiZfOZmZuT for ; Thu, 24 Jun 2010 23:55:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 489193A691D for ; Thu, 24 Jun 2010 23:55:10 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 552341727820181; Fri, 25 Jun 2010 14:54:37 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 2748.7958837698; Fri, 25 Jun 2010 14:54:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5P6TNJd038550; Fri, 25 Jun 2010 14:54:52 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <26CB142D3C24B0shinji.okumura@softfront.jp> To: Paul Kyzivat , Brett Tate , OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 25 Jun 2010 14:50:32 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-25 14:54:41, Serialize complete at 2010-06-25 14:54:41 Content-Type: multipart/alternative; boundary="=_alternative 0025E00D4825774D_=" X-MAIL: mse2.zte.com.cn o5P6TNJd038550 Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 06:55:13 -0000 This is a multipart message in MIME format. --=_alternative 0025E00D4825774D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGF1bCwgQnJldHQsIFNoaW5qaSAmIEdvbnphbG8sDQoNCkluIGZhY3QsIHdlIGFyZSB0aGUg cGVvcGxlIHJlYWxseSBjYXJlIGFib3V0IHRoZSAiR2xhcmUgY29uZGl0aW9ucyIgb2YgDQpTSVAu IFRob3VnaCBpdCBpcyBhIHJlbGF0aXZlIG5hcnJvdyB0b3BpYywgYnV0IGl0IGlzIHJlYWxseSBp bXBvcnRhbnQgZm9yIA0KZXF1aXBtZW50IGludGVyd29ya2luZyBpc3N1ZS4NCg0KSSdkIGxpa2Ug dG8gcHJvcG9zZSBhIHdvcmtpbmctcHJvY2VzcyBmb3IgdGhpcyBpc3N1ZToNCg0KT25jZSBQYXVs IHRhbGtlZCBhYm91dCB3aGljaCBwbGFjZSBpcyBtb3JlIHByb3BlciBmb3IgdGhpc2lzc3VlLCBP L0EgZHJhZnQgDQpvciBSZS1JTlZJVEUgZHJhZnQ/IA0KLy9odHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzAyODYyLmh0bWwNCg0KSXQgYWxzbyBw dXp6bGVkIG1lLiBBbmQgYWZ0ZXIgbXkgdGhvdWdodCwgbXkgc3VnZ2VzdGlvbiBpczoNCg0KRmly c3QsIHdlIHNob3VsZCBldmFsdWF0ZSB3aGV0aGVyIHdlIG5lZWQgbm9ybWF0aXZlIGRlZmludGlv biBmb3IgdGhpcyANCmlzc3VlPyAvL015IHBvaW50IGlzIFlFUy4NCg0KVGhlbiwgaWYgd2UgbmVl ZCBub3JtYXRpdmUgb25lLCB3ZSBjYW4gZG8gaXQgaW4gUmUtSU5WSVRFIGRyYWZ0LiBBbmQgYXQg DQp0aGUgc2FtZSB0aW1lLCB3ZSBuZWVkIGEgcmVsYXRpdmUgY29tcGxleCBCQ1Agc3VnZ2VzdGlv biBpbiBPL0EgZHJhZnQgDQphbG9uZyB0aGlzIG5vcm1hdGl2ZSB0cmFjayhNb3JlIGV4YW1wbGVz LCBpbGx1c3RyYXRpb24gc2hvdWxkIGJlIGluIE8vQSANCmRyYWZ0KS4gDQoNClRoYW5rcywNCg0K R2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEw MDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KDQoNCg0KT0tVTVVSQSBTaGluamkgPHNoaW5qaS5va3VtdXJhQHNvZnRmcm9udC5qcD4g DQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDYtMjUgMTQ6MTENCg0K ytW8/sjLDQpTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpSZTogW3Np cGNvcmVdIEdsYXJlIGNvbmRpdGlvbnMgaW4gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlDQoN Cg0KDQoNCg0KDQpIaSwNCg0KR29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJpbGxvQGVy aWNzc29uLmNvbT4NClRodSwgMjQgSnVuIDIwMTAgMTA6MTE6MDMgKzAzMDANCj5Gb2xrcywNCj4N Cj5wZXIgdGhlIG91ciBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbnMsIEkgaGF2ZSBlZGl0ZWQgU2Vj dGlvbiAzLjUgb2YgdGhlDQo+ZHJhZnQgc28gdGhhdCB0aGUgcnVsZXMgdG8gZGV0ZWN0IGFuZCBh ZGRyZXNzIGdsYXJlIGNvbmRpdGlvbnMgYXJlDQo+Y2xlYXJlciwgbW9yZSBleHBsaWNpdCwgYW5k IGxlc3MgcmVzdHJpY3RpdmUuIExldCBtZSBrbm93IGlmIHRoZSBuZXcNCj50ZXh0IG1lZXRzIGFu eSBvZiB0aGVzZSB0aHJlZSBnb2FscyA6bykNCj4NCj5CZWxvdyB5b3UgaGF2ZSB0aGUgbmV3IFNl Y3Rpb24gMy41LiBZb3UgY2FuIGNoZWNrIHRoZSBvbGQgdmVyc2lvbiBhdDoNCj4NCj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQjc2VjdGlv bi0zLjUNCj4NCj5PbmNlIHdlIGFncmVlIG9uIHRoZSBjb250ZW50cyBvZiB0aGlzIHNlY3Rpb24s IFNlY3Rpb24gNC41IHdpbGwgbm90IG5lZWQNCj50byBkZWZpbmUgZnVydGhlciBydWxlcy4NCj4N Cj5Db21tZW50cyBhcmUgd2VsY29tZS4NCj4NCj5UaGFua3MsDQo+DQo+R29uemFsbw0KPg0KPg0K PjMuNS4gIEdsYXJlIFNpdHVhdGlvbnMNCj4NCj4gICBTZWN0aW9uIDQgb2YgUkZDIDMyNjQgW1JG QzMyNjRdIGRlZmluZXMgZ2xhcmUgY29uZGl0aW9ucyBhcyBhIHVzZXINCj4gICBhZ2VudCByZWNl aXZpbmcgYW4gb2ZmZXIgYWZ0ZXIgaGF2aW5nIHNlbnQgb25lIGJ1dCBiZWZvcmUgaGF2aW5nDQo+ ICAgcmVjZWl2ZWQgYW4gYW5zd2VyIHRvIGl0LiAgVGhhdCBzZWN0aW9uIHNwZWNpZmllcyBydWxl cyB0byBhdm9pZA0KPiAgIGdsYXJlIHNpdHVhdGlvbnMgaW4gbW9zdCBjYXNlcy4gIFdoZW4gZGVz cGl0ZSBmb2xsb3dpbmcgdGhvc2UgcnVsZXMgYQ0KPiAgIGdsYXJlIGNvbmRpdGlvbnMgb2NjdXJz IChhcyBhIHJlc3VsdCBvZiBhIHJhY2UgY29uZGl0aW9uKSwgaXQgaXMNCj4gICBoYW5kbGVkIGFz IHNwZWNpZmllZCBpbiBTZWN0aW9ucyAxNC4xIGFuZCAxNC4yIG9mIFJGQyAzMjYxIFtSRkMzMjYx XS4NCj4gICBUaGUgVUFTIHJldHVybnMgYSA0OTEgKFJlcXVlc3QgUGVuZGluZykgcmVzcG9uc2Ug YW5kIHRoZSBVQUMgcmV0cmllcw0KPiAgIHRoZSBvZmZlciBhZnRlciBhIHJhbmRvbWx5LXNlbGVj dGVkIHRpbWUsIHdoaWNoIGRlcGVuZHMgb24gd2hpY2ggdXNlcg0KPiAgIGFnZW50IGlzIHRoZSBv d25lciBvZiB0aGUgQ2FsbC1JRCBvZiB0aGUgZGlhbG9nLiAgVGhlIHJ1bGVzIGluIFJGQw0KPiAg IDMyNjEgW1JGQzMyNjFdIG5vdCBvbmx5IGNvdmVyIGNvbGxpc2lvbnMgYmV0d2VlbiByZS1JTlZJ VEVzIHRoYXQNCj4gICBjb250YWluIG9mZmVyczsgdGhleSBjb3ZlciBjb2xsaXNpb25zIGJldHdl ZW4gdHdvIHJlLUlOVklURXMgaW4NCj4gICBnZW5lcmFsLCBldmVuIGlmIHRoZXkgZG8gbm90IGNv bnRhaW4gb2ZmZXJzLiAgU2VjdGlvbnMgNS4yIGFuZCA1LjMgb2YNCj4gICBSRkMgMzMxMSBbUkZD MzMxMV0gZXh0ZW5kIHRob3NlIHJ1bGVzIHRvIGFsc28gY292ZXIgY29sbGlzaW9ucw0KPiAgIGJl dHdlZW4gYW4gVVBEQVRFIHJlcXVlc3QgY2FycnlpbmcgYW4gb2ZmZXIgYW5kIGFub3RoZXIgbWVz c2FnZQ0KPiAgIChVUERBVEUsIFBSQUNLIG9yIElOVklURSkgYWxzbyBjYXJyeWluZyBhbiBvZmZl ci4NCj4NCj4gICBTaW5jZSByZS1JTlZJVEVzIGFuZCBVUERBVEVzIGNhbiBjaGFuZ2Ugbm90IG9u bHkgdGhlIHNlc3Npb24gc3RhdGUNCj4gICBidXQgYWxzbyB0aGUgZGlhbG9nIHN0YXRlLCBjb2xs aXNpb25zIGFtb25nIHRoZW0gbmVlZCB0byBiZSBhdm9pZGVkDQo+ICAgZXZlbiB3aGVuIHRoZXkg ZG8gbm90IGNhcnJ5IG9mZmVycy4gIFRoZXJlZm9yZSwgdGhpcyBkb2N1bWVudCBleHRlbmRzDQo+ ICAgdGhlIHJ1bGVzIGp1c3QgZGVzY3JpYmVkIHRvIGFsc28gY292ZXIgY29sbGlzaW9ucyB0aGF0 IGRvIG5vdCBpbnZvbHZlDQo+ICAgb2ZmZXJzLg0KPg0KPiAgIEEgVUEgdGhhdCByZWNlaXZlcyBh biBVUERBVEUgcmVxdWVzdCBvbiBhIGRpYWxvZyB3aGlsZSBhbiBVUERBVEUNCj4gICByZXF1ZXN0 IGl0IGhhZCBzZW50IG9uIHRoYXQgZGlhbG9nIGlzIGluIHByb2dyZXNzIE1VU1QgcmV0dXJuIGEg NDkxDQo+ICAgKFJlcXVlc3QgUGVuZGluZykgcmVzcG9uc2UgdG8gdGhlIHJlY2VpdmVkIFVQREFU RSByZXF1ZXN0Lg0KPg0KPiAgIElmIGEgVUEgcmVjZWl2ZXMgYSByZS1JTlZJVEUgd2hpbGUgYW4g VVBEQVRFIHJlcXVlc3QgaXQgaGFkIHNlbnQgb24NCj4gICB0aGF0IGRpYWxvZyBpcyBpbiBwcm9n cmVzcyBhbmQgYWZ0ZXIgcmVjZWl2aW5nIHRoZSByZS1JTlZJVEUgdGhlIFVBDQo+ICAgcmVjZWl2 ZXMgYSAyeHggcmVzcG9uc2UgdG8gdGhlIFVQREFURSByZXF1ZXN0LCB0aGUgVUEgU0hPVUxEIGdl bmVyYXRlDQo+ICAgYSBuZXcgVVBEQVRFIHJlcXVlc3Qgb3IgYSByZWxpYWJsZSByZXNwb25zZSB0 byB0aGUgcmUtSU5WSVRFIGluIG9yZGVyDQo+ICAgdG8gbWFrZSBzdXJlIHRoYXQgYm90aCBVQXMg aGF2ZSBhIGNvbW1vbiB2aWV3IG9mIHRoZSBzdGF0ZSBvZiB0aGUNCj4gICBzZXNzaW9uLCBhcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQuDQo+DQo+ICAgVGhlIHJ1bGVzIGluIFJGQyAzMjYxIFtS RkMzMjYxXSBkbyBub3QgY292ZXIgY29sbGlzaW9ucyBiZXR3ZWVuIGFuDQo+ICAgVVBEQVRFIHJl cXVlc3QgYW5kIGEgcmVsaWFibGUgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUgKG5vbi0yeHggZmlu YWwNCj4gICByZXNwb25zZXMgdG8gdGhlIHJlLUlOVklURSBhcmUgYWxzbyBjb25zaWRlcmVkIHJl bGlhYmxlIHJlc3BvbnNlcykuDQo+ICAgU2luY2UgYm90aCB0aGUgVVBEQVRFIHJlcXVlc3QgYW5k IHRoZSByZWxpYWJsZSByZXNwb25zZSBjb3VsZCBiZQ0KPiAgIHJlcXVlc3RpbmcgY2hhbmdlcyB0 byB0aGUgZGlhbG9nIG9yIHNlc3Npb24gc3RhdGUsIGl0IHdvdWxkIG5vdCBiZQ0KPiAgIGNsZWFy IHdoaWNoIGNoYW5nZXMgd291bGQgbmVlZCB0byBiZSBleGVjdXRlZCBmaXJzdC4NCj4NCj4gICBJ ZiB0aGUgVUFTIG9mIGEgcmUtSU5WSVRFIHRyYW5zYWN0aW9uIHJlY2VpdmVzIGFuZCBVUERBVEUg cmVxdWVzdA0KPiAgIGFmdGVyIGhhdmluZyBzZW50IGEgcmVsaWFibGUgcmVzcG9uc2UgdG8gdGhl IHJlLUlOVklURSBidXQgYmVmb3JlDQo+ICAgaGF2aW5nIHJlY2VpdmVkIHRoZSBjb3JyZXNwb25k aW5nIEFDSyBvciBQUkFDSyByZXF1ZXN0LCB0aGUgVUEgU0hPVUxEDQo+ICAgcmV0dXJuIGEgNDkx IChSZXF1ZXN0IFBlbmRpbmcpIHJlc3BvbnNlIHRvIHRoZSBVUERBVEUgcmVxdWVzdC4NCg0KRm9y IHJlZmVyZW5jZSwgaGVyZSBhcmUgbXkgb3BpbmlvbiByZWdhcmRpbmcgYW4gaW50ZXJ3b3JraW5n DQpvZiBVUERBVEUgYW5kIHJlLUlOVklURSBmcm9tIGFuIG9mZmVyLWFuc3dlciBwZXJzcGVjdGl2 ZS4NCg0KQ2FzZSAxOiBPbmUgb3IgbW9yZSBPL0EgZXhjaGFuZ2UgYW5kIHRoZW4gMnh4IHRvIHJl LUlOVklURSB3aXRoIGFuIG9mZmVyLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBICAgICAgICAgICAgICAgICAgICAgIEINCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxJTlZJVEUob2ZmZXIpICAgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgKy0tLS0tPiAgICAgICAgICAgICArLT58LS0tLS0t LS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgfCAgfCAgICAgICAgICAgMXh4KGFuc3dlcil8DQogICBEb24ndCBzZW5kIFVQREFURSB8IERv bid0IHNlbmQgSU5WSVRFIHwgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgNDkxIHRvIFVQ REFURSAgICAgfCA0OTEgdG8gSU5WSVRFICAgICB8ICB8UFJBQ0sgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgfC0tLS0tLS0tLS0t LS0tLS0tLS0tLT58DQogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwg IHwgICAgICAgICAgICAgICAyeHgtUFJBfA0KICAgICAgICAgICAgICAgICAgICAgKy0tLS0tPiAg ICAgICAgICAgICB8ICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCiAgIG1heSBzZW5kIFVQREFU RSAgIHwgICAgICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgICAgICB8DQogICBt YXkgYWNjZXB0VVBEQVRFICB8ICAgICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAgICAg ICAgMnh4fA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICArLT58PC0t LS0tLS0tLS0tLS0tLS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgICAgIHwgbWF5IHNlbmQgSU5W SVRFICAgfCAgfCAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICB8 IG1heSBhY2NlcHQgSU5WSVRFIHwgIHxBQ0sgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8ICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0t PnwNCiAgICAgICAgICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgICAgdiAgfCAgICAgICAg ICAgICAgICAgICAgICB8DQoNCiAgIEEgICAgICAgICAgICAgICAgICAgICAgQg0KICAgfCAgICAg ICAgICAgICAgICAgICAgICB8DQogICB8SU5WSVRFKG9mZmVyKSAgICAgICAgIHwNCiAgIHwtLS0t LS0tLS0tLS0tLS0tLS0tLS0+fDwtKyAgICAgICAgICAgICA8LS0tLS0rDQogICB8ICAgICAgICAg ICAxeHgoYW5zd2VyKXwgIHwgICAgICAgICAgICAgICAgICAgfA0KICAgfDwtLS0tLS0tLS0tLS0t LS0tLS0tLS18ICB8IERvbid0IHNlbmQgSU5WSVRFIHwgRG9uJ3Qgc2VuZCBVUERBVEUNCiAgIHxQ UkFDSyAgICAgICAgICAgICAgICAgfCAgfCA1MDAgdG8gSU5WSVRFICAgICB8IDUwMCB0byBVUERB VEUNCiAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgfCAgICAgICAgICAgICAgICAgICB8DQog ICB8ICAgICAgICAgICAgICAgMnh4LVBSQXwgIHwgICAgICAgICAgICAgICAgICAgfA0KICAgfDwt LS0tLS0tLS0tLS0tLS0tLS0tLS18ICB8ICAgICAgICAgICAgIDwtLS0tLSsNCiAgIHwgICAgICAg ICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgICB8IG1heSBzZW5kIFVQREFURQ0K ICAgfCAgICAgICAgICAgICAgICAgICAyeHh8ICB8ICAgICAgICAgICAgICAgICAgIHwgbWF5IGFj Y2VwdFVQREFURQ0KICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS18PC0rICAgICAgICAgICAgICAg ICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgfCBtYXkgc2VuZCBJTlZJVEUgICB8 DQogICB8QUNLICAgICAgICAgICAgICAgICAgIHwgIHwgbWF5IGFjY2VwdCBJTlZJVEUgfA0KICAg fC0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICB8ICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgfCAgdiAgICAgICAgICAgICAgICAgICB2DQoNCg0KQ2FzZSAyOiBP bmUgb3IgbW9yZSBPL0EgZXhjaGFuZ2UgYW5kIHRoZW4gNHh4IHRvIHJlLUlOVklURSB3aXRoIGFu IG9mZmVyLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBICAg ICAgICAgICAgICAgICAgICAgIEINCiAgIFtVQUMgYmVoYXZpb3JdICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHxJTlZJVEUob2ZmZXIpICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tPiAgICAgICAgICAgICArLT58LS0tLS0tLS0tLS0tLS0tLS0tLS0t PnwNCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgfCAgICAgICAg ICAgMXh4KGFuc3dlcil8DQogICBEb24ndCBzZW5kIFVQREFURSB8IERvbid0IHNlbmQgSU5WSVRF IHwgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgNDkxIHRvIFVQREFURSAgICAgfCA0OTEg dG8gSU5WSVRFICAgICB8ICB8UFJBQ0sgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQog ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAg ICAyeHgtUFJBfA0KICAgICAgICAgICAgICAgICAgICAgKy0tLS0tPiAgICAgICAgICAgICB8ICB8 PC0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCiAgIG1heSBzZW5kIFVQREFURSAgIHwgICAgICAgICAg ICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgICAgICB8DQogICBtYXkgYWNjZXB0VVBEQVRF ICB8ICAgICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAgICBub24tMnh4fA0KICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICArLT58PC0tLS0tLS0tLS0tLS0tLS0t LS0tLXwNCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgIHxBQ0sgICAgICAgICAgQUNLICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICArLT58LS0tLS0tLS0tPiAgIC0tLS0tLS0tPnwNCiAgICAgICAgICAg ICAgICAgICAgIHYgICAgICAgICAgICAgICAgICAgdiAgfCAgICAgICAgICAgICAgICAgICAgICB8 DQogICAgICAgICAgICAgICAgICg0eHggYW5kIEFDayB0byBpdCBhcmUgYXRvbWljLikNCg0KDQog ICBBICAgICAgICAgICAgICAgICAgICAgIEINCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAg ICBbVUFTIGJlaGF2aW9yXQ0KICAgfElOVklURShvZmZlcikgICAgICAgICB8DQogICB8LS0tLS0t LS0tLS0tLS0tLS0tLS0tPnw8LSsgICAgICAgICAgICAgPC0tLS0tKw0KICAgfCAgICAgICAgICAg MXh4KGFuc3dlcil8ICB8ICAgICAgICAgICAgICAgICAgIHwNCiAgIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tfCAgfCBEb24ndCBzZW5kIElOVklURSB8IERvbid0IHNlbmQgVVBEQVRFDQogICB8UFJB Q0sgICAgICAgICAgICAgICAgIHwgIHwgNTAwIHRvIElOVklURSAgICAgfCA1MDAgdG8gVVBEQVRF DQogICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgIHwgICAgICAgICAgICAgICAgICAgfA0KICAg fCAgICAgICAgICAgICAgIDJ4eC1QUkF8ICB8ICAgICAgICAgICAgICAgICAgIHwNCiAgIHw8LS0t LS0tLS0tLS0tLS0tLS0tLS0tfCAgfCAgICAgICAgICAgICA8LS0tLS0rDQogICB8ICAgICAgICAg ICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAgICAgICAgfCBtYXkgc2VuZCBVUERBVEUNCiAg IHwgICAgICAgICAgICAgICBub24tMnh4fCAgfCAgICAgICAgICAgICAgICAgICB8IG1heSBhY2Nl cHQgVVBEQVRFDQogICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLXw8LSsgICAgICAgICAgICAgICAg ICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICB8IERvbid0IHNlbmQgSU5WSVRFIHwN CiAgIHxBQ0sgICAgICAgICAgQUNLICAgICAgfCAgfCBtYXkgYWNjZXB0IElOVklURSB8DQogICB8 LS0tLS0tLS0tPiAgIC0tLS0tLS0tPnw8LSsgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAg ICAgICAgICAgICAgICAgICB8ICB2ICAgICAgICAgICAgICAgICAgIHYNCg0KDQpSZWdhcmRzLA0K U2hpbmppDQoNCj4gICBJZg0KPiAgIHRoZSBVQUMgb2YgYSByZS1JTlZJVEUgdHJhbnNhY3Rpb24g c2VuZHMgYW4gVVBEQVRFIHJlcXVlc3QsIHJlY2VpdmVzDQo+ICAgYSByZWxpYWJsZSByZXNwb25z ZSB0byB0aGUgcmUtSU5WSVRFLCBhbmQgdGhlbiBhIDJ4eCByZXNwb25zZSB0byB0aGUNCj4gICBV UERBVEUgcmVxdWVzdCwgdGhlIFVBIFNIT1VMRCBnZW5lcmF0ZSBhIG5ldyByZS1JTlZJVEUgb3Ig VVBEQVRFDQo+ICAgcmVxdWVzdCBpbiBvcmRlciB0byBtYWtlIHN1cmUgdGhhdCBib3RoIFVBcyBo YXZlIGEgY29tbW9uIHZpZXcgb2YgdGhlDQo+ICAgc3RhdGUgb2YgdGhlIHNlc3Npb24sIGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuNC4NCj4NCj4gICBJZiBhIFVBIHJlY2VpdmVzIGEgNDkxIHJl c3BvbnNlIHRvIGFuIFVQREFURSByZXF1ZXN0LCBpdCBmb2xsb3dzIHRoZQ0KPiAgIHJ1bGVzIGlu IFNlY3Rpb24gNS4zIG9mIFJGQyAzMzExIFtSRkMzMzExXS4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29y ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0gc3lzdGVtLg0K --=_alternative 0025E00D4825774D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBhdWwsIEJyZXR0LCBTaGlu amkgJmFtcDsgR29uemFsbyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkluIGZhY3QsIHdlIGFyZSB0aGUgcGVvcGxlIHJlYWxseSBjYXJlDQphYm91dCB0 aGUgJnF1b3Q7R2xhcmUgY29uZGl0aW9ucyZxdW90OyBvZiBTSVAuIFRob3VnaCBpdCBpcyBhIHJl bGF0aXZlDQpuYXJyb3cgdG9waWMsIGJ1dCBpdCBpcyByZWFsbHkgaW1wb3J0YW50IGZvciBlcXVp cG1lbnQgaW50ZXJ3b3JraW5nIGlzc3VlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+SSdkIGxpa2UgdG8gcHJvcG9zZSBhIHdvcmtpbmctcHJvY2Vzcw0K Zm9yIHRoaXMgaXNzdWU6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5PbmNlIFBhdWwgdGFsa2VkIGFib3V0IHdoaWNoIHBsYWNlIGlzDQptb3JlIHByb3Bl ciBmb3IgdGhpc2lzc3VlLCBPL0EgZHJhZnQgb3IgUmUtSU5WSVRFIGRyYWZ0PyAmbmJzcDsgLy9o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzAy ODYyLmh0bWw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pkl0IGFsc28gcHV6emxlZCBtZS4gQW5kIGFmdGVyIG15IHRob3VnaHQsDQpteSBzdWdnZXN0aW9u IGlzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Rmly c3QsIHdlIHNob3VsZCBldmFsdWF0ZSB3aGV0aGVyIHdlDQpuZWVkIG5vcm1hdGl2ZSBkZWZpbnRp b24gZm9yIHRoaXMgaXNzdWU/IC8vTXkgcG9pbnQgaXMgWUVTLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlbiwgaWYgd2UgbmVlZCBub3JtYXRpdmUg b25lLCB3ZSBjYW4NCmRvIGl0IGluIFJlLUlOVklURSBkcmFmdC4gQW5kIGF0IHRoZSBzYW1lIHRp bWUsIHdlIG5lZWQgYSByZWxhdGl2ZSBjb21wbGV4DQpCQ1Agc3VnZ2VzdGlvbiBpbiBPL0EgZHJh ZnQgYWxvbmcgdGhpcyBub3JtYXRpdmUgdHJhY2soTW9yZSBleGFtcGxlcywgaWxsdXN0cmF0aW9u DQpzaG91bGQgYmUgaW4gTy9BIGRyYWZ0KS4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjEx PGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2Fv LnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5P S1VNVVJBIFNoaW5qaSAmbHQ7c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwJmd0OzwvYj4NCjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+MjAxMC0wNi0yNSAxNDoxMTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0 OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UmU6IFtzaXBjb3JlXSBHbGFyZSBjb25kaXRpb25zIGluIGRyYWZ0LWlldGYtc2lwY29yZS1y ZWludml0ZTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+SGksPGJyPg0KPGJyPg0KR29uemFsbyBDYW1hcmlsbG8gJmx0O0dvbnphbG8uQ2Ft YXJpbGxvQGVyaWNzc29uLmNvbSZndDs8YnI+DQpUaHUsIDI0IEp1biAyMDEwIDEwOjExOjAzICsw MzAwPGJyPg0KJmd0O0ZvbGtzLDxicj4NCiZndDs8YnI+DQomZ3Q7cGVyIHRoZSBvdXIgbWFpbGlu ZyBsaXN0IGRpc2N1c3Npb25zLCBJIGhhdmUgZWRpdGVkIFNlY3Rpb24gMy41IG9mDQp0aGU8YnI+ DQomZ3Q7ZHJhZnQgc28gdGhhdCB0aGUgcnVsZXMgdG8gZGV0ZWN0IGFuZCBhZGRyZXNzIGdsYXJl IGNvbmRpdGlvbnMgYXJlPGJyPg0KJmd0O2NsZWFyZXIsIG1vcmUgZXhwbGljaXQsIGFuZCBsZXNz IHJlc3RyaWN0aXZlLiBMZXQgbWUga25vdyBpZiB0aGUgbmV3PGJyPg0KJmd0O3RleHQgbWVldHMg YW55IG9mIHRoZXNlIHRocmVlIGdvYWxzIDpvKTxicj4NCiZndDs8YnI+DQomZ3Q7QmVsb3cgeW91 IGhhdmUgdGhlIG5ldyBTZWN0aW9uIDMuNS4gWW91IGNhbiBjaGVjayB0aGUgb2xkIHZlcnNpb24g YXQ6PGJyPg0KJmd0Ozxicj4NCiZndDtodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQjc2VjdGlvbi0zLjU8YnI+DQomZ3Q7PGJyPg0KJmd0O09u Y2Ugd2UgYWdyZWUgb24gdGhlIGNvbnRlbnRzIG9mIHRoaXMgc2VjdGlvbiwgU2VjdGlvbiA0LjUg d2lsbCBub3QNCm5lZWQ8YnI+DQomZ3Q7dG8gZGVmaW5lIGZ1cnRoZXIgcnVsZXMuPGJyPg0KJmd0 Ozxicj4NCiZndDtDb21tZW50cyBhcmUgd2VsY29tZS48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoYW5r cyw8YnI+DQomZ3Q7PGJyPg0KJmd0O0dvbnphbG88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDszLjUuICZuYnNwO0dsYXJlIFNpdHVhdGlvbnM8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsg U2VjdGlvbiA0IG9mIFJGQyAzMjY0IFtSRkMzMjY0XSBkZWZpbmVzIGdsYXJlIGNvbmRpdGlvbnMg YXMNCmEgdXNlcjxicj4NCiZndDsgJm5ic3A7IGFnZW50IHJlY2VpdmluZyBhbiBvZmZlciBhZnRl ciBoYXZpbmcgc2VudCBvbmUgYnV0IGJlZm9yZSBoYXZpbmc8YnI+DQomZ3Q7ICZuYnNwOyByZWNl aXZlZCBhbiBhbnN3ZXIgdG8gaXQuICZuYnNwO1RoYXQgc2VjdGlvbiBzcGVjaWZpZXMgcnVsZXMN CnRvIGF2b2lkPGJyPg0KJmd0OyAmbmJzcDsgZ2xhcmUgc2l0dWF0aW9ucyBpbiBtb3N0IGNhc2Vz LiAmbmJzcDtXaGVuIGRlc3BpdGUgZm9sbG93aW5nDQp0aG9zZSBydWxlcyBhPGJyPg0KJmd0OyAm bmJzcDsgZ2xhcmUgY29uZGl0aW9ucyBvY2N1cnMgKGFzIGEgcmVzdWx0IG9mIGEgcmFjZSBjb25k aXRpb24pLA0KaXQgaXM8YnI+DQomZ3Q7ICZuYnNwOyBoYW5kbGVkIGFzIHNwZWNpZmllZCBpbiBT ZWN0aW9ucyAxNC4xIGFuZCAxNC4yIG9mIFJGQyAzMjYxDQpbUkZDMzI2MV0uPGJyPg0KJmd0OyAm bmJzcDsgVGhlIFVBUyByZXR1cm5zIGEgNDkxIChSZXF1ZXN0IFBlbmRpbmcpIHJlc3BvbnNlIGFu ZCB0aGUgVUFDDQpyZXRyaWVzPGJyPg0KJmd0OyAmbmJzcDsgdGhlIG9mZmVyIGFmdGVyIGEgcmFu ZG9tbHktc2VsZWN0ZWQgdGltZSwgd2hpY2ggZGVwZW5kcyBvbg0Kd2hpY2ggdXNlcjxicj4NCiZn dDsgJm5ic3A7IGFnZW50IGlzIHRoZSBvd25lciBvZiB0aGUgQ2FsbC1JRCBvZiB0aGUgZGlhbG9n LiAmbmJzcDtUaGUNCnJ1bGVzIGluIFJGQzxicj4NCiZndDsgJm5ic3A7IDMyNjEgW1JGQzMyNjFd IG5vdCBvbmx5IGNvdmVyIGNvbGxpc2lvbnMgYmV0d2VlbiByZS1JTlZJVEVzDQp0aGF0PGJyPg0K Jmd0OyAmbmJzcDsgY29udGFpbiBvZmZlcnM7IHRoZXkgY292ZXIgY29sbGlzaW9ucyBiZXR3ZWVu IHR3byByZS1JTlZJVEVzDQppbjxicj4NCiZndDsgJm5ic3A7IGdlbmVyYWwsIGV2ZW4gaWYgdGhl eSBkbyBub3QgY29udGFpbiBvZmZlcnMuICZuYnNwO1NlY3Rpb25zDQo1LjIgYW5kIDUuMyBvZjxi cj4NCiZndDsgJm5ic3A7IFJGQyAzMzExIFtSRkMzMzExXSBleHRlbmQgdGhvc2UgcnVsZXMgdG8g YWxzbyBjb3ZlciBjb2xsaXNpb25zPGJyPg0KJmd0OyAmbmJzcDsgYmV0d2VlbiBhbiBVUERBVEUg cmVxdWVzdCBjYXJyeWluZyBhbiBvZmZlciBhbmQgYW5vdGhlciBtZXNzYWdlPGJyPg0KJmd0OyAm bmJzcDsgKFVQREFURSwgUFJBQ0sgb3IgSU5WSVRFKSBhbHNvIGNhcnJ5aW5nIGFuIG9mZmVyLjxi cj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyBTaW5jZSByZS1JTlZJVEVzIGFuZCBVUERBVEVzIGNh biBjaGFuZ2Ugbm90IG9ubHkgdGhlIHNlc3Npb24NCnN0YXRlPGJyPg0KJmd0OyAmbmJzcDsgYnV0 IGFsc28gdGhlIGRpYWxvZyBzdGF0ZSwgY29sbGlzaW9ucyBhbW9uZyB0aGVtIG5lZWQgdG8gYmUN CmF2b2lkZWQ8YnI+DQomZ3Q7ICZuYnNwOyBldmVuIHdoZW4gdGhleSBkbyBub3QgY2Fycnkgb2Zm ZXJzLiAmbmJzcDtUaGVyZWZvcmUsIHRoaXMgZG9jdW1lbnQNCmV4dGVuZHM8YnI+DQomZ3Q7ICZu YnNwOyB0aGUgcnVsZXMganVzdCBkZXNjcmliZWQgdG8gYWxzbyBjb3ZlciBjb2xsaXNpb25zIHRo YXQgZG8gbm90DQppbnZvbHZlPGJyPg0KJmd0OyAmbmJzcDsgb2ZmZXJzLjxicj4NCiZndDs8YnI+ DQomZ3Q7ICZuYnNwOyBBIFVBIHRoYXQgcmVjZWl2ZXMgYW4gVVBEQVRFIHJlcXVlc3Qgb24gYSBk aWFsb2cgd2hpbGUgYW4gVVBEQVRFPGJyPg0KJmd0OyAmbmJzcDsgcmVxdWVzdCBpdCBoYWQgc2Vu dCBvbiB0aGF0IGRpYWxvZyBpcyBpbiBwcm9ncmVzcyBNVVNUIHJldHVybg0KYSA0OTE8YnI+DQom Z3Q7ICZuYnNwOyAoUmVxdWVzdCBQZW5kaW5nKSByZXNwb25zZSB0byB0aGUgcmVjZWl2ZWQgVVBE QVRFIHJlcXVlc3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IElmIGEgVUEgcmVjZWl2ZXMg YSByZS1JTlZJVEUgd2hpbGUgYW4gVVBEQVRFIHJlcXVlc3QgaXQgaGFkDQpzZW50IG9uPGJyPg0K Jmd0OyAmbmJzcDsgdGhhdCBkaWFsb2cgaXMgaW4gcHJvZ3Jlc3MgYW5kIGFmdGVyIHJlY2Vpdmlu ZyB0aGUgcmUtSU5WSVRFDQp0aGUgVUE8YnI+DQomZ3Q7ICZuYnNwOyByZWNlaXZlcyBhIDJ4eCBy ZXNwb25zZSB0byB0aGUgVVBEQVRFIHJlcXVlc3QsIHRoZSBVQSBTSE9VTEQNCmdlbmVyYXRlPGJy Pg0KJmd0OyAmbmJzcDsgYSBuZXcgVVBEQVRFIHJlcXVlc3Qgb3IgYSByZWxpYWJsZSByZXNwb25z ZSB0byB0aGUgcmUtSU5WSVRFDQppbiBvcmRlcjxicj4NCiZndDsgJm5ic3A7IHRvIG1ha2Ugc3Vy ZSB0aGF0IGJvdGggVUFzIGhhdmUgYSBjb21tb24gdmlldyBvZiB0aGUgc3RhdGUNCm9mIHRoZTxi cj4NCiZndDsgJm5ic3A7IHNlc3Npb24sIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgVGhlIHJ1bGVzIGluIFJGQyAzMjYxIFtSRkMzMjYxXSBk byBub3QgY292ZXIgY29sbGlzaW9ucyBiZXR3ZWVuDQphbjxicj4NCiZndDsgJm5ic3A7IFVQREFU RSByZXF1ZXN0IGFuZCBhIHJlbGlhYmxlIHJlc3BvbnNlIHRvIGEgcmUtSU5WSVRFIChub24tMnh4 DQpmaW5hbDxicj4NCiZndDsgJm5ic3A7IHJlc3BvbnNlcyB0byB0aGUgcmUtSU5WSVRFIGFyZSBh bHNvIGNvbnNpZGVyZWQgcmVsaWFibGUgcmVzcG9uc2VzKS48YnI+DQomZ3Q7ICZuYnNwOyBTaW5j ZSBib3RoIHRoZSBVUERBVEUgcmVxdWVzdCBhbmQgdGhlIHJlbGlhYmxlIHJlc3BvbnNlIGNvdWxk DQpiZTxicj4NCiZndDsgJm5ic3A7IHJlcXVlc3RpbmcgY2hhbmdlcyB0byB0aGUgZGlhbG9nIG9y IHNlc3Npb24gc3RhdGUsIGl0IHdvdWxkDQpub3QgYmU8YnI+DQomZ3Q7ICZuYnNwOyBjbGVhciB3 aGljaCBjaGFuZ2VzIHdvdWxkIG5lZWQgdG8gYmUgZXhlY3V0ZWQgZmlyc3QuPGJyPg0KJmd0Ozxi cj4NCiZndDsgJm5ic3A7IElmIHRoZSBVQVMgb2YgYSByZS1JTlZJVEUgdHJhbnNhY3Rpb24gcmVj ZWl2ZXMgYW5kIFVQREFURSByZXF1ZXN0PGJyPg0KJmd0OyAmbmJzcDsgYWZ0ZXIgaGF2aW5nIHNl bnQgYSByZWxpYWJsZSByZXNwb25zZSB0byB0aGUgcmUtSU5WSVRFIGJ1dA0KYmVmb3JlPGJyPg0K Jmd0OyAmbmJzcDsgaGF2aW5nIHJlY2VpdmVkIHRoZSBjb3JyZXNwb25kaW5nIEFDSyBvciBQUkFD SyByZXF1ZXN0LCB0aGUNClVBIFNIT1VMRDxicj4NCiZndDsgJm5ic3A7IHJldHVybiBhIDQ5MSAo UmVxdWVzdCBQZW5kaW5nKSByZXNwb25zZSB0byB0aGUgVVBEQVRFIHJlcXVlc3QuPGJyPg0KPGJy Pg0KRm9yIHJlZmVyZW5jZSwgaGVyZSBhcmUgbXkgb3BpbmlvbiByZWdhcmRpbmcgYW4gaW50ZXJ3 b3JraW5nPGJyPg0Kb2YgVVBEQVRFIGFuZCByZS1JTlZJVEUgZnJvbSBhbiBvZmZlci1hbnN3ZXIg cGVyc3BlY3RpdmUuPGJyPg0KPGJyPg0KQ2FzZSAxOiBPbmUgb3IgbW9yZSBPL0EgZXhjaGFuZ2Ug YW5kIHRoZW4gMnh4IHRvIHJlLUlOVklURSB3aXRoIGFuIG9mZmVyLjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0EgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtCPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7fCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDt8SU5WSVRFKG9mZmVyKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCistLS0tLSZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgKy0mZ3Q7fC0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwO3wNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg MXh4KGFuc3dlcil8PGJyPg0KICZuYnNwOyBEb24ndCBzZW5kIFVQREFURSB8IERvbid0IHNlbmQg SU5WSVRFIHwgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPg0KICZuYnNwOyA0 OTEgdG8gVVBEQVRFICZuYnNwOyAmbmJzcDsgfCA0OTEgdG8gSU5WSVRFICZuYnNwOyAmbmJzcDsg fCAmbmJzcDt8UFJBQ0sNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnwgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8LS0t LS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQp8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5i c3A7fA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDJ4 eC1QUkF8PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KKy0tLS0tJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0t fDxicj4NCiAmbmJzcDsgbWF5IHNlbmQgVVBEQVRFICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KICZuYnNwOyBtYXkgYWNjZXB0VVBEQVRFICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgMnh4fDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnwgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgKy0mZ3Q7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K fCBtYXkgc2VuZCBJTlZJVEUgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQp8IG1heSBhY2NlcHQgSU5WSVRFIHwgJm5ic3A7fEFDSyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgfDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8LS0tLS0tLS0tLS0tLS0t LS0tLS0tJmd0O3w8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQp2ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHYgJm5ic3A7fA0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3w8YnI+DQo8YnI+DQogJm5ic3A7IEEgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtC PGJyPg0KICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7fDxicj4NCiAmbmJzcDsgfElOVklU RShvZmZlcikgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQogJm5ic3A7IHwtLS0t LS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fCZsdDstKyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJmx0Oy0tLS0tKzxicj4NCiAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDF4eChhbnN3ZXIpfCAmbmJzcDt8ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KICZu YnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgJm5ic3A7fCBEb24ndCBzZW5kIElOVklU RSB8IERvbid0IHNlbmQNClVQREFURTxicj4NCiAmbmJzcDsgfFBSQUNLICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnwgJm5ic3A7fCA1MDAg dG8gSU5WSVRFICZuYnNwOyAmbmJzcDsgfCA1MDAgdG8gVVBEQVRFPGJyPg0KICZuYnNwOyB8LS0t LS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMnh4LVBSQXwg Jm5ic3A7fA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfDxicj4NCiAmbmJzcDsgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS18 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZsdDst LS0tLSs8YnI+DQogJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 IHwgbWF5IHNlbmQgVVBEQVRFPGJyPg0KICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQoyeHh8ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCnwgbWF5IGFjY2VwdFVQREFURTxicj4NCiAmbmJzcDsgfCZsdDstLS0tLS0tLS0tLS0tLS0t LS0tLS18Jmx0Oy0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 fCAmbmJzcDt8IG1heSBzZW5kIElOVklURSAmbmJzcDsgfDxicj4NCiAmbmJzcDsgfEFDSyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KfCAmbmJzcDt8IG1heSBhY2NlcHQgSU5WSVRFIHw8YnI+DQogJm5ic3A7IHwtLS0tLS0tLS0t LS0tLS0tLS0tLS0mZ3Q7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7fCAmbmJzcDt2ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB2PGJyPg0KPGJyPg0KPGJyPg0KQ2FzZSAyOiBP bmUgb3IgbW9yZSBPL0EgZXhjaGFuZ2UgYW5kIHRoZW4gNHh4IHRvIHJlLUlOVklURSB3aXRoIGFu IG9mZmVyLjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0Eg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDtCPGJyPg0KICZuYnNwOyBbVUFDIGJlaGF2aW9yXSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7fElOVklURShvZmZlcikg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQorLS0tLS0m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstJmd0O3wtLS0t LS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnwgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDt8DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDF4eChhbnN3ZXIpfDxicj4N CiAmbmJzcDsgRG9uJ3Qgc2VuZCBVUERBVEUgfCBEb24ndCBzZW5kIElOVklURSB8ICZuYnNwO3wm bHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4NCiAmbmJzcDsgNDkxIHRvIFVQREFURSAmbmJz cDsgJm5ic3A7IHwgNDkxIHRvIElOVklURSAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fFBSQUNLDQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQp8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fC0tLS0tLS0tLS0tLS0tLS0tLS0t LSZndDt8PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyeHgtUFJBfDxicj4NCiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCistLS0tLSZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDt8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+DQogJm5ic3A7IG1h eSBzZW5kIFVQREFURSAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fDxicj4NCiAmbmJzcDsgbWF5IGFjY2VwdFVQREFURSAmbmJzcDt8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBub24t Mnh4fDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0mZ3Q7fCZsdDstLS0tLS0tLS0tLS0t LS0tLS0tLS18PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDt8PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KfCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwO3xBQ0sgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FDSyAmbmJzcDsgJm5i c3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQp8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstJmd0O3wtLS0tLS0tLS0m Z3Q7DQombmJzcDsgLS0tLS0tLS0mZ3Q7fDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnYgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdiAm bmJzcDt8DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICg0eHggYW5kIEFDayB0bw0KaXQgYXJl IGF0b21pYy4pPGJyPg0KPGJyPg0KPGJyPg0KICZuYnNwOyBBICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 Qjxicj4NCiAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwO1tVQVMg YmVoYXZpb3JdPGJyPg0KICZuYnNwOyB8SU5WSVRFKG9mZmVyKSAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfDxicj4NCiAmbmJzcDsgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8Jmx0Oy0r ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbHQ7LS0tLS0rPGJy Pg0KICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMXh4KGFuc3dl cil8ICZuYnNwO3wgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQogJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0t LS0tfCAmbmJzcDt8IERvbid0IHNlbmQgSU5WSVRFIHwgRG9uJ3Qgc2VuZA0KVVBEQVRFPGJyPg0K ICZuYnNwOyB8UFJBQ0sgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KfCAmbmJzcDt8IDUwMCB0byBJTlZJVEUgJm5ic3A7ICZuYnNwOyB8IDUw MCB0byBVUERBVEU8YnI+DQogJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fCAmbmJz cDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8PGJyPg0KICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAyeHgtUFJBfCAmbmJzcDt8DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KICZuYnNw OyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJmx0Oy0tLS0tKzxicj4NCiAmbmJzcDsgfCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCBtYXkgc2VuZCBVUERBVEU8YnI+DQogJm5i c3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5v bi0yeHh8ICZuYnNwO3wNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgbWF5IGFjY2VwdA0KVVBEQVRFPGJyPg0KICZuYnNwOyB8 Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLXwmbHQ7LSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQogJm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDt8ICZuYnNwO3wgRG9uJ3Qgc2VuZCBJTlZJVEUgfDxicj4NCiAm bmJzcDsgfEFDSyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QUNLICZuYnNwOyAm bmJzcDsgJm5ic3A7fA0KJm5ic3A7fCBtYXkgYWNjZXB0IElOVklURSB8PGJyPg0KICZuYnNwOyB8 LS0tLS0tLS0tJmd0OyAmbmJzcDsgLS0tLS0tLS0mZ3Q7fCZsdDstKyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiAm bmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO3wgJm5ic3A7diAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgdjxicj4NCjxicj4N Cjxicj4NClJlZ2FyZHMsPGJyPg0KU2hpbmppPGJyPg0KPGJyPg0KJmd0OyAmbmJzcDsgSWY8YnI+ DQomZ3Q7ICZuYnNwOyB0aGUgVUFDIG9mIGEgcmUtSU5WSVRFIHRyYW5zYWN0aW9uIHNlbmRzIGFu IFVQREFURSByZXF1ZXN0LA0KcmVjZWl2ZXM8YnI+DQomZ3Q7ICZuYnNwOyBhIHJlbGlhYmxlIHJl c3BvbnNlIHRvIHRoZSByZS1JTlZJVEUsIGFuZCB0aGVuIGEgMnh4IHJlc3BvbnNlDQp0byB0aGU8 YnI+DQomZ3Q7ICZuYnNwOyBVUERBVEUgcmVxdWVzdCwgdGhlIFVBIFNIT1VMRCBnZW5lcmF0ZSBh IG5ldyByZS1JTlZJVEUgb3IgVVBEQVRFPGJyPg0KJmd0OyAmbmJzcDsgcmVxdWVzdCBpbiBvcmRl ciB0byBtYWtlIHN1cmUgdGhhdCBib3RoIFVBcyBoYXZlIGEgY29tbW9uIHZpZXcNCm9mIHRoZTxi cj4NCiZndDsgJm5ic3A7IHN0YXRlIG9mIHRoZSBzZXNzaW9uLCBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiAzLjQuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IElmIGEgVUEgcmVjZWl2ZXMgYSA0 OTEgcmVzcG9uc2UgdG8gYW4gVVBEQVRFIHJlcXVlc3QsIGl0IGZvbGxvd3MNCnRoZTxicj4NCiZn dDsgJm5ic3A7IHJ1bGVzIGluIFNlY3Rpb24gNS4zIG9mIFJGQyAzMzExIFtSRkMzMzExXS48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNp cGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjxicj4NCjwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZu YnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5 Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtU aGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlh bC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29i bGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7 YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3Ro ZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7 ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2Nv bmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5i c3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3Im bmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRk cmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhp cyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZu YnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5i c3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJz cDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDti eSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0025E00D4825774D_=-- From gonzalo.camarillo@ericsson.com Tue Jun 29 04:58:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9830F3A6AE2 for ; Tue, 29 Jun 2010 04:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=-1.393, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpVOe18q2fik for ; Tue, 29 Jun 2010 04:58:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A8A6E3A6ACB for ; Tue, 29 Jun 2010 04:58:54 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-0b-4c29e0083ad6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.47.19600.800E92C4; Tue, 29 Jun 2010 13:59:04 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 13:59:04 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 13:59:04 +0200 Message-ID: <4C29E007.60501@ericsson.com> Date: Tue, 29 Jun 2010 14:59:03 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2010 11:59:04.0195 (UTC) FILETIME=[7850F530:01CB1782] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 11:58:58 -0000 Hi Gao, thanks for your comments. My answer inline: >> The rules in RFC 3261 [RFC3261] do not cover collisions between an >> UPDATE request and a reliable response to a re-INVITE (non-2xx final >> responses to the re-INVITE are also considered reliable responses). >> Since both the UPDATE request and the reliable response could be >> requesting changes to the dialog or session state, it would not be >> clear which changes would need to be executed first. > > Here, the text points out the problem, but without handling rule. I > guess adding some words like "re-send a new Re-INVITE or UPDATE to > synchronize state" would be better. the text follows the same structure in all the section. First the issue at hand is explained and then normative language to resolve the issue is given. The normative rules to address the issue described in this paragraph are in the next paragraph. Thanks, Gonzalo From harbhanu@huawei.com Tue Jun 29 05:07:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513743A680B for ; Tue, 29 Jun 2010 05:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0SV28zX21my for ; Tue, 29 Jun 2010 05:07:05 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BAD3D3A6869 for ; Tue, 29 Jun 2010 05:07:04 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4R00602YZSEM@szxga05-in.huawei.com> for sipcore@ietf.org; Tue, 29 Jun 2010 20:07:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4R00KN4YZSKW@szxga05-in.huawei.com> for sipcore@ietf.org; Tue, 29 Jun 2010 20:07:04 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4R00BVOYZQZA@szxml06-in.huawei.com> for sipcore@ietf.org; Tue, 29 Jun 2010 20:07:04 +0800 (CST) Date: Tue, 29 Jun 2010 17:37:02 +0530 From: Harbhanu In-reply-to: <4C230507.10105@ericsson.com> To: 'Gonzalo Camarillo' , 'SIPCORE' Message-id: <8BBB572CAD3B4211A121FF277BD98EF6@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcsTbHkkVbhQQ0IHQPyFbMvAIc9n7AEFqCDg References: <4C230507.10105@ericsson.com> Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:07:06 -0000 Typo highlighted below:- If the UAS of a re-INVITE transaction receives **and UPDATE** (Should be 'an' UPDATE.. right??) request after having sent a reliable response to the re-INVITE but before having received the corresponding ACK or PRACK request, the UA SHOULD return a 491 (Request Pending) response to the UPDATE request. Regards, Harbhanu **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo Sent: Thursday, June 24, 2010 12:41 PM To: SIPCORE Subject: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite Folks, per the our mailing list discussions, I have edited Section 3.5 of the draft so that the rules to detect and address glare conditions are clearer, more explicit, and less restrictive. Let me know if the new text meets any of these three goals :o) Below you have the new Section 3.5. You can check the old version at: http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5 Once we agree on the contents of this section, Section 4.5 will not need to define further rules. Comments are welcome. Thanks, Gonzalo 3.5. Glare Situations Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user agent receiving an offer after having sent one but before having received an answer to it. That section specifies rules to avoid glare situations in most cases. When despite following those rules a glare conditions occurs (as a result of a race condition), it is handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. The UAS returns a 491 (Request Pending) response and the UAC retries the offer after a randomly-selected time, which depends on which user agent is the owner of the Call-ID of the dialog. The rules in RFC 3261 [RFC3261] not only cover collisions between re-INVITEs that contain offers; they cover collisions between two re-INVITEs in general, even if they do not contain offers. Sections 5.2 and 5.3 of RFC 3311 [RFC3311] extend those rules to also cover collisions between an UPDATE request carrying an offer and another message (UPDATE, PRACK or INVITE) also carrying an offer. Since re-INVITEs and UPDATEs can change not only the session state but also the dialog state, collisions among them need to be avoided even when they do not carry offers. Therefore, this document extends the rules just described to also cover collisions that do not involve offers. A UA that receives an UPDATE request on a dialog while an UPDATE request it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received UPDATE request. If a UA receives a re-INVITE while an UPDATE request it had sent on that dialog is in progress and after receiving the re-INVITE the UA receives a 2xx response to the UPDATE request, the UA SHOULD generate a new UPDATE request or a reliable response to the re-INVITE in order to make sure that both UAs have a common view of the state of the session, as described in Section 3.4. The rules in RFC 3261 [RFC3261] do not cover collisions between an UPDATE request and a reliable response to a re-INVITE (non-2xx final responses to the re-INVITE are also considered reliable responses). Since both the UPDATE request and the reliable response could be requesting changes to the dialog or session state, it would not be clear which changes would need to be executed first. If the UAS of a re-INVITE transaction receives and UPDATE request after having sent a reliable response to the re-INVITE but before having received the corresponding ACK or PRACK request, the UA SHOULD return a 491 (Request Pending) response to the UPDATE request. If the UAC of a re-INVITE transaction sends an UPDATE request, receives a reliable response to the re-INVITE, and then a 2xx response to the UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE request in order to make sure that both UAs have a common view of the state of the session, as described in Section 3.4. If a UA receives a 491 response to an UPDATE request, it follows the rules in Section 5.3 of RFC 3311 [RFC3311]. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From gao.yang2@zte.com.cn Tue Jun 29 05:11:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729793A6869 for ; Tue, 29 Jun 2010 05:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.469 X-Spam-Level: X-Spam-Status: No, score=-96.469 tagged_above=-999 required=5 tests=[AWL=-1.434, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSfyGLgtt0H0 for ; Tue, 29 Jun 2010 05:11:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E10093A67FC for ; Tue, 29 Jun 2010 05:11:08 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 552341727820181; Tue, 29 Jun 2010 20:10:46 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 2748.2980680612; Tue, 29 Jun 2010 20:11:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5TCBJoS023796; Tue, 29 Jun 2010 20:11:19 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C29E007.60501@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 29 Jun 2010 20:08:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-29 20:11:04, Serialize complete at 2010-06-29 20:11:04 Content-Type: multipart/alternative; boundary="=_alternative 0042DE4B48257751_=" X-MAIL: mse2.zte.com.cn o5TCBJoS023796 Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:11:10 -0000 This is a multipart message in MIME format. --=_alternative 0042DE4B48257751_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KT0suIFRoZW4gdGhlIGhhbmRsaW5nIHdheSB3b3VsZCBiZSByZWplY3Rp bmcgdGhlIFVQREFURSBieSA0OTEsIGluIHRoZSANCm5leHQgcGFyYWdyYXBoLg0KDQpBbmQgSSBh bSBPSyB3aXRoIGl0Lg0KDQpUaGFua3MsDQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAg IDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCkdvbnphbG8gQ2FtYXJpbGxv IDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+IA0KMjAxMC0wNi0yOSAxOTo1OQ0KDQrK 1bz+yMsNCiJnYW8ueWFuZzJAenRlLmNvbS5jbiIgPGdhby55YW5nMkB6dGUuY29tLmNuPg0Ks63L zQ0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCtb3zOINClJlOiBbc2lwY29yZV0gR2xhcmUg Y29uZGl0aW9ucyBpbiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUNCg0KDQoNCg0KDQoNCkhp IEdhbywNCg0KdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBNeSBhbnN3ZXIgaW5saW5lOg0KDQo+ PiAgICBUaGUgcnVsZXMgaW4gUkZDIDMyNjEgW1JGQzMyNjFdIGRvIG5vdCBjb3ZlciBjb2xsaXNp b25zIGJldHdlZW4gYW4NCj4+ICAgIFVQREFURSByZXF1ZXN0IGFuZCBhIHJlbGlhYmxlIHJlc3Bv bnNlIHRvIGEgcmUtSU5WSVRFIChub24tMnh4IGZpbmFsDQo+PiAgICByZXNwb25zZXMgdG8gdGhl IHJlLUlOVklURSBhcmUgYWxzbyBjb25zaWRlcmVkIHJlbGlhYmxlIHJlc3BvbnNlcykuDQo+PiAg ICBTaW5jZSBib3RoIHRoZSBVUERBVEUgcmVxdWVzdCBhbmQgdGhlIHJlbGlhYmxlIHJlc3BvbnNl IGNvdWxkIGJlDQo+PiAgICByZXF1ZXN0aW5nIGNoYW5nZXMgdG8gdGhlIGRpYWxvZyBvciBzZXNz aW9uIHN0YXRlLCBpdCB3b3VsZCBub3QgYmUNCj4+ICAgIGNsZWFyIHdoaWNoIGNoYW5nZXMgd291 bGQgbmVlZCB0byBiZSBleGVjdXRlZCBmaXJzdC4NCj4gDQo+IEhlcmUsIHRoZSB0ZXh0IHBvaW50 cyBvdXQgdGhlIHByb2JsZW0sIGJ1dCB3aXRob3V0IGhhbmRsaW5nIHJ1bGUuIEkNCj4gZ3Vlc3Mg YWRkaW5nIHNvbWUgd29yZHMgbGlrZSAicmUtc2VuZCBhIG5ldyBSZS1JTlZJVEUgb3IgVVBEQVRF IHRvDQo+IHN5bmNocm9uaXplIHN0YXRlIiB3b3VsZCBiZSBiZXR0ZXIuDQoNCnRoZSB0ZXh0IGZv bGxvd3MgdGhlIHNhbWUgc3RydWN0dXJlIGluIGFsbCB0aGUgc2VjdGlvbi4gRmlyc3QgdGhlIGlz c3VlDQphdCBoYW5kIGlzIGV4cGxhaW5lZCBhbmQgdGhlbiBub3JtYXRpdmUgbGFuZ3VhZ2UgdG8g cmVzb2x2ZSB0aGUgaXNzdWUgaXMNCmdpdmVuLiBUaGUgbm9ybWF0aXZlIHJ1bGVzIHRvIGFkZHJl c3MgdGhlIGlzc3VlIGRlc2NyaWJlZCBpbiB0aGlzDQpwYXJhZ3JhcGggYXJlIGluIHRoZSBuZXh0 IHBhcmFncmFwaC4NCg0KVGhhbmtzLA0KDQpHb256YWxvDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0 dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3Ro ZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0042DE4B48257751_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdvbnphbG8sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5PSy4gVGhlbiB0aGUgaGFu ZGxpbmcgd2F5IHdvdWxkIGJlIHJlamVjdGluZw0KdGhlIFVQREFURSBieSA0OTEsIGluIHRoZSBu ZXh0IDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPnBhcmFncmFwaC48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkFuZCBJIGFtIE9LIHdpdGggaXQuPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGFua3MsPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5HYW88L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+ DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcy MTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBn YW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PkdvbnphbG8gQ2FtYXJpbGxvICZsdDtHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7 PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDYt MjkgMTk6NTk8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+JnF1b3Q7Z2FvLnlhbmcyQHp0ZS5jb20uY24mcXVvdDsgJmx0O2dhby55YW5nMkB6 dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U0lQQ09SRSAmbHQ7c2lwY29yZUBpZXRm Lm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gR2xhcmUgY29uZGl0aW9u cyBpbiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGU8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0 YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4N Cjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhpIEdhbyw8YnI+DQo8YnI+DQp0aGFu a3MgZm9yIHlvdXIgY29tbWVudHMuIE15IGFuc3dlciBpbmxpbmU6PGJyPg0KPGJyPg0KJmd0OyZn dDsgJm5ic3A7ICZuYnNwO1RoZSBydWxlcyBpbiBSRkMgMzI2MSBbUkZDMzI2MV0gZG8gbm90IGNv dmVyIGNvbGxpc2lvbnMNCmJldHdlZW4gYW48YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VVBE QVRFIHJlcXVlc3QgYW5kIGEgcmVsaWFibGUgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUNCihub24t Mnh4IGZpbmFsPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3Jlc3BvbnNlcyB0byB0aGUgcmUt SU5WSVRFIGFyZSBhbHNvIGNvbnNpZGVyZWQgcmVsaWFibGUNCnJlc3BvbnNlcykuPGJyPg0KJmd0 OyZndDsgJm5ic3A7ICZuYnNwO1NpbmNlIGJvdGggdGhlIFVQREFURSByZXF1ZXN0IGFuZCB0aGUg cmVsaWFibGUgcmVzcG9uc2UNCmNvdWxkIGJlPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3Jl cXVlc3RpbmcgY2hhbmdlcyB0byB0aGUgZGlhbG9nIG9yIHNlc3Npb24gc3RhdGUsDQppdCB3b3Vs ZCBub3QgYmU8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7Y2xlYXIgd2hpY2ggY2hhbmdlcyB3 b3VsZCBuZWVkIHRvIGJlIGV4ZWN1dGVkIGZpcnN0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBIZXJl LCB0aGUgdGV4dCBwb2ludHMgb3V0IHRoZSBwcm9ibGVtLCBidXQgd2l0aG91dCBoYW5kbGluZyBy dWxlLg0KSTxicj4NCiZndDsgZ3Vlc3MgYWRkaW5nIHNvbWUgd29yZHMgbGlrZSAmcXVvdDtyZS1z ZW5kIGEgbmV3IFJlLUlOVklURSBvciBVUERBVEUNCnRvPGJyPg0KJmd0OyBzeW5jaHJvbml6ZSBz dGF0ZSZxdW90OyB3b3VsZCBiZSBiZXR0ZXIuPGJyPg0KPGJyPg0KdGhlIHRleHQgZm9sbG93cyB0 aGUgc2FtZSBzdHJ1Y3R1cmUgaW4gYWxsIHRoZSBzZWN0aW9uLiBGaXJzdCB0aGUgaXNzdWU8YnI+ DQphdCBoYW5kIGlzIGV4cGxhaW5lZCBhbmQgdGhlbiBub3JtYXRpdmUgbGFuZ3VhZ2UgdG8gcmVz b2x2ZSB0aGUgaXNzdWUgaXM8YnI+DQpnaXZlbi4gVGhlIG5vcm1hdGl2ZSBydWxlcyB0byBhZGRy ZXNzIHRoZSBpc3N1ZSBkZXNjcmliZWQgaW4gdGhpczxicj4NCnBhcmFncmFwaCBhcmUgaW4gdGhl IG5leHQgcGFyYWdyYXBoLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpHb256YWxvPGJy Pg0KPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 0042DE4B48257751_=-- From gonzalo.camarillo@ericsson.com Tue Jun 29 05:22:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2882E3A6964 for ; Tue, 29 Jun 2010 05:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.23 X-Spam-Level: X-Spam-Status: No, score=-103.23 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iELHbJzo5QId for ; Tue, 29 Jun 2010 05:22:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6F9663A68FB for ; Tue, 29 Jun 2010 05:22:23 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-7d-4c29e5897f57 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F7.EA.19600.985E92C4; Tue, 29 Jun 2010 14:22:33 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:22:32 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:21:21 +0200 Message-ID: <4C29E540.4050402@ericsson.com> Date: Tue, 29 Jun 2010 15:21:20 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: OKUMURA Shinji References: <4C230507.10105@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2010 12:21:22.0029 (UTC) FILETIME=[95BA39D0:01CB1785] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:22:25 -0000 Hi Shinji, thanks for your comments. My answers inline: On 24/06/2010 2:05 PM, OKUMURA Shinji wrote: > Hi Gonzalo, > > Gonzalo Camarillo > Thu, 24 Jun 2010 10:11:03 +0300 >> Folks, >> >> per the our mailing list discussions, I have edited Section 3.5 of the >> draft so that the rules to detect and address glare conditions are >> clearer, more explicit, and less restrictive. Let me know if the new >> text meets any of these three goals :o) >> >> Below you have the new Section 3.5. You can check the old version at: >> >> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5 >> >> Once we agree on the contents of this section, Section 4.5 will not need >> to define further rules. >> >> Comments are welcome. >> >> Thanks, >> >> Gonzalo >> >> >> 3.5. Glare Situations >> >> Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user >> agent receiving an offer after having sent one but before having >> received an answer to it. That section specifies rules to avoid >> glare situations in most cases. When despite following those rules a >> glare conditions occurs (as a result of a race condition), it is >> handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. >> The UAS returns a 491 (Request Pending) response and the UAC retries >> the offer after a randomly-selected time, which depends on which user >> agent is the owner of the Call-ID of the dialog. The rules in RFC >> 3261 [RFC3261] not only cover collisions between re-INVITEs that >> contain offers; they cover collisions between two re-INVITEs in >> general, even if they do not contain offers. Sections 5.2 and 5.3 of >> RFC 3311 [RFC3311] extend those rules to also cover collisions >> between an UPDATE request carrying an offer and another message >> (UPDATE, PRACK or INVITE) also carrying an offer. >> >> Since re-INVITEs and UPDATEs can change not only the session state >> but also the dialog state, collisions among them need to be avoided >> even when they do not carry offers. Therefore, this document extends >> the rules just described to also cover collisions that do not involve >> offers. >> >> A UA that receives an UPDATE request on a dialog while an UPDATE >> request it had sent on that dialog is in progress MUST return a 491 >> (Request Pending) response to the received UPDATE request. > > I like this rule. > >> If a UA receives a re-INVITE while an UPDATE request it had sent on >> that dialog is in progress and after receiving the re-INVITE the UA >> receives a 2xx response to the UPDATE request, the UA SHOULD generate >> a new UPDATE request or a reliable response to the re-INVITE in order >> to make sure that both UAs have a common view of the state of the >> session, as described in Section 3.4. > > Various cases are possible, > > A B > | | > |UPDATE(offer1) | > |=================================>| > | 2xx-UPD(answer1)| > |<---------\ /====================| > | \/ | > | /\ re-INVITE(offer2)| > |<=========/ \--------------------| > |491-INV | > |--------------------------------->| > | | > > A B > | | > |UPDATE(offer1) re-INVITE(offer2)| > |=============\ /-----------------| > | \/ | > | /\ | > |<------------/ \================>| > |491-INV | > |--------------------------------->| > | 491-UPD| > |<=================================| > | | > > > At least, if the UPDATE has an offer, I think the UA-A SHOULD > return a 491 response to the reINVITE. > This is simpler and does't contradict a current rule. I will add the following rule: A UA that receives a re-INVITE on a dialog while an UPDATE request it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the re-INVITE. >> The rules in RFC 3261 [RFC3261] do not cover collisions between an >> UPDATE request and a reliable response to a re-INVITE (non-2xx final >> responses to the re-INVITE are also considered reliable responses). >> Since both the UPDATE request and the reliable response could be >> requesting changes to the dialog or session state, it would not be >> clear which changes would need to be executed first. >> >> If the UAS of a re-INVITE transaction receives and UPDATE request >> after having sent a reliable response to the re-INVITE but before >> having received the corresponding ACK or PRACK request, the UA SHOULD >> return a 491 (Request Pending) response to the UPDATE request. > > I think this rule is more restrictive. > IMO; > In case that the reliable response is 18x, the UA SHOULD return a "500" response. > In case that the reliable response is 2xx; > If the 2xx carries an offer, the UA SHOULD return a "500" response. > Otherwise, the UA MAY return a 2xx response. > In case that the reliable response is 4xx, the UA MAY return a 2xx response. No, these rules would not address the glare situation. > >> If >> the UAC of a re-INVITE transaction sends an UPDATE request, receives >> a reliable response to the re-INVITE, and then a 2xx response to the >> UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE >> request in order to make sure that both UAs have a common view of the >> state of the session, as described in Section 3.4. > > In case that the reliable response is 4xx, this rule is necessary > from an offer-answer perspective. Exactly. > In case that the reliable response is 2xx or 18x, this rule seems > to be also necessary from a remote-target perspective. Exactly. > But I'm not sure at present. Your understanding is correct. > >> If a UA receives a 491 response to an UPDATE request, it follows the >> rules in Section 5.3 of RFC 3311 [RFC3311]. > > And I think the rules are insufficient. > In the cases below, UA-A SHOULD send new offer after sending ACK. > > A B > | | > s0|re-INVITE (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1| non-2xx|s1 > | /--------------|<-+ > |UPDATE(offer2) / |s0| > |==============/===============>| | accept UPDATE > | / 2xx-UPD(answer2)| | > |<===========/==================| | > s2| / ACK |s2| > |<---------/ ----------->| | > s0|ACK | | > |-------------> | | > |UPDATE(offer0) | | > |==============================>| | > | 2xx-UPD(answer0)| | > |<==============================| | > s0| |s0| > | | v > > > A B > | | > s0|re-INVITE (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1| non-2xx|s1 > | /------------|<-+ > | / ACK |s0| > | / -------->| | accept UPDATE > | / UPDATE(offer2)| | > |<=============/================| | > |2xx-UPD(answer2) | | > |============/=================>| | > s2| / |s2| > |<---------/ | | > s0|ACK | | > |-----------> | | > |UPDATE(offer0) | | > |==============================>| | > | 2xx-UPD(answer0)| | > |<==============================| | > s0| |s0| > | | v Yes, that rule is already specified in Section 3.4 of the draft. http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.4 Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Tue Jun 29 05:37:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8D53A6900 for ; Tue, 29 Jun 2010 05:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=-1.848, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBM69oIqasm3 for ; Tue, 29 Jun 2010 05:37:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A4DFC3A698D for ; Tue, 29 Jun 2010 05:37:47 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-f5-4c29e9259f0f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0C.5D.19600.529E92C4; Tue, 29 Jun 2010 14:37:57 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:36:34 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:36:34 +0200 Message-ID: <4C29E8D2.8000806@ericsson.com> Date: Tue, 29 Jun 2010 15:36:34 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Jun 2010 12:36:34.0719 (UTC) FILETIME=[B5BBAAF0:01CB1787] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:37:49 -0000 Yes, Gao. Thanks! Gonzalo On 29/06/2010 3:08 PM, gao.yang2@zte.com.cn wrote: > > Hi Gonzalo, > > OK. Then the handling way would be rejecting the UPDATE by 491, in the > next paragraph. > > And I am OK with it. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Gonzalo Camarillo * > > 2010-06-29 19:59 > > > ÊÕ¼þÈË > "gao.yang2@zte.com.cn" > ³­ËÍ > SIPCORE > Ö÷Ìâ > Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite > > > > > > > > > Hi Gao, > > thanks for your comments. My answer inline: > >>> The rules in RFC 3261 [RFC3261] do not cover collisions between an >>> UPDATE request and a reliable response to a re-INVITE (non-2xx final >>> responses to the re-INVITE are also considered reliable responses). >>> Since both the UPDATE request and the reliable response could be >>> requesting changes to the dialog or session state, it would not be >>> clear which changes would need to be executed first. >> >> Here, the text points out the problem, but without handling rule. I >> guess adding some words like "re-send a new Re-INVITE or UPDATE to >> synchronize state" would be better. > > the text follows the same structure in all the section. First the issue > at hand is explained and then normative language to resolve the issue is > given. The normative rules to address the issue described in this > paragraph are in the next paragraph. > > Thanks, > > Gonzalo > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From gonzalo.camarillo@ericsson.com Tue Jun 29 05:40:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2973A6893 for ; Tue, 29 Jun 2010 05:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.2 X-Spam-Level: X-Spam-Status: No, score=-105.2 tagged_above=-999 required=5 tests=[AWL=1.399, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4tTUS+d3CFb for ; Tue, 29 Jun 2010 05:40:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 685D03A6452 for ; Tue, 29 Jun 2010 05:40:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-07-4c29e9d9f1f4 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 03.18.10125.9D9E92C4; Tue, 29 Jun 2010 14:40:57 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:40:56 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:40:56 +0200 Message-ID: <4C29E9D8.4050500@ericsson.com> Date: Tue, 29 Jun 2010 15:40:56 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Harbhanu References: <4C230507.10105@ericsson.com> <8BBB572CAD3B4211A121FF277BD98EF6@china.huawei.com> In-Reply-To: <8BBB572CAD3B4211A121FF277BD98EF6@china.huawei.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2010 12:40:56.0834 (UTC) FILETIME=[51F73E20:01CB1788] X-Brightmail-Tracker: AAAAAA== Cc: 'SIPCORE' Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:40:50 -0000 Hi Harbhanu, I have just fixed this typo in my working copy of the draft. Thanks! Gonzalo On 29/06/2010 3:07 PM, Harbhanu wrote: > Typo highlighted below:- > > If the UAS of a re-INVITE transaction receives **and UPDATE** (Should be > 'an' UPDATE.. right??) request after having sent a reliable response to the > re-INVITE but before having received the corresponding ACK or PRACK request, > the UA SHOULD return a 491 (Request Pending) response to the UPDATE request. > > Regards, > Harbhanu > > **************************************************************************** > *********** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Gonzalo Camarillo > Sent: Thursday, June 24, 2010 12:41 PM > To: SIPCORE > Subject: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite > > Folks, > > per the our mailing list discussions, I have edited Section 3.5 of the > draft so that the rules to detect and address glare conditions are > clearer, more explicit, and less restrictive. Let me know if the new > text meets any of these three goals :o) > > Below you have the new Section 3.5. You can check the old version at: > > http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5 > > Once we agree on the contents of this section, Section 4.5 will not need > to define further rules. > > Comments are welcome. > > Thanks, > > Gonzalo > > > 3.5. Glare Situations > > Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user > agent receiving an offer after having sent one but before having > received an answer to it. That section specifies rules to avoid > glare situations in most cases. When despite following those rules a > glare conditions occurs (as a result of a race condition), it is > handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. > The UAS returns a 491 (Request Pending) response and the UAC retries > the offer after a randomly-selected time, which depends on which user > agent is the owner of the Call-ID of the dialog. The rules in RFC > 3261 [RFC3261] not only cover collisions between re-INVITEs that > contain offers; they cover collisions between two re-INVITEs in > general, even if they do not contain offers. Sections 5.2 and 5.3 of > RFC 3311 [RFC3311] extend those rules to also cover collisions > between an UPDATE request carrying an offer and another message > (UPDATE, PRACK or INVITE) also carrying an offer. > > Since re-INVITEs and UPDATEs can change not only the session state > but also the dialog state, collisions among them need to be avoided > even when they do not carry offers. Therefore, this document extends > the rules just described to also cover collisions that do not involve > offers. > > A UA that receives an UPDATE request on a dialog while an UPDATE > request it had sent on that dialog is in progress MUST return a 491 > (Request Pending) response to the received UPDATE request. > > If a UA receives a re-INVITE while an UPDATE request it had sent on > that dialog is in progress and after receiving the re-INVITE the UA > receives a 2xx response to the UPDATE request, the UA SHOULD generate > a new UPDATE request or a reliable response to the re-INVITE in order > to make sure that both UAs have a common view of the state of the > session, as described in Section 3.4. > > The rules in RFC 3261 [RFC3261] do not cover collisions between an > UPDATE request and a reliable response to a re-INVITE (non-2xx final > responses to the re-INVITE are also considered reliable responses). > Since both the UPDATE request and the reliable response could be > requesting changes to the dialog or session state, it would not be > clear which changes would need to be executed first. > > If the UAS of a re-INVITE transaction receives and UPDATE request > after having sent a reliable response to the re-INVITE but before > having received the corresponding ACK or PRACK request, the UA SHOULD > return a 491 (Request Pending) response to the UPDATE request. If > the UAC of a re-INVITE transaction sends an UPDATE request, receives > a reliable response to the re-INVITE, and then a 2xx response to the > UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE > request in order to make sure that both UAs have a common view of the > state of the session, as described in Section 3.4. > > If a UA receives a 491 response to an UPDATE request, it follows the > rules in Section 5.3 of RFC 3311 [RFC3311]. > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Tue Jun 29 05:54:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5CE3A6AE1 for ; Tue, 29 Jun 2010 05:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.684 X-Spam-Level: X-Spam-Status: No, score=-101.684 tagged_above=-999 required=5 tests=[AWL=-2.135, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ6kVguDWveB for ; Tue, 29 Jun 2010 05:54:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id AC9373A6A2A for ; Tue, 29 Jun 2010 05:54:30 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-56-4c29ed11a5b3 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.DF.19600.11DE92C4; Tue, 29 Jun 2010 14:54:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:54:39 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:25:47 +0200 Message-ID: <4C29E64B.3090509@ericsson.com> Date: Tue, 29 Jun 2010 15:25:47 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Jun 2010 12:25:47.0795 (UTC) FILETIME=[3422E630:01CB1786] X-Brightmail-Tracker: AAAAAA== Cc: OKUMURA Shinji , SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:54:32 -0000 Hi Gao, thanks for your comments. The scope of the re-INVITE draft is not going to change at this point. We are going to clarify the glare-related rules, per our mailing list discussions, and then progress the draft as planned. In addition to the changes related to glare situations, I will also address a set of comments I received from Robert as part of his AD review of the draft. Thanks, Gonzalo On 25/06/2010 9:50 AM, gao.yang2@zte.com.cn wrote: > > Hi Paul, Brett, Shinji & Gonzalo, > > In fact, we are the people really care about the "Glare conditions" of > SIP. Though it is a relative narrow topic, but it is really important > for equipment interworking issue. > > I'd like to propose a working-process for this issue: > > Once Paul talked about which place is more proper for thisissue, O/A > draft or Re-INVITE draft? > //http://www.ietf.org/mail-archive/web/sipcore/current/msg02862.html > > It also puzzled me. And after my thought, my suggestion is: > > First, we should evaluate whether we need normative defintion for this > issue? //My point is YES. > > Then, if we need normative one, we can do it in Re-INVITE draft. And at > the same time, we need a relative complex BCP suggestion in O/A draft > along this normative track(More examples, illustration should be in O/A > draft). > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *OKUMURA Shinji * > ·¢¼þÈË: sipcore-bounces@ietf.org > > 2010-06-25 14:11 > > > ÊÕ¼þÈË > SIPCORE > ³­ËÍ > > Ö÷Ìâ > Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite > > > > > > > > > Hi, > > Gonzalo Camarillo > Thu, 24 Jun 2010 10:11:03 +0300 >>Folks, >> >>per the our mailing list discussions, I have edited Section 3.5 of the >>draft so that the rules to detect and address glare conditions are >>clearer, more explicit, and less restrictive. Let me know if the new >>text meets any of these three goals :o) >> >>Below you have the new Section 3.5. You can check the old version at: >> >>http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5 >> >>Once we agree on the contents of this section, Section 4.5 will not need >>to define further rules. >> >>Comments are welcome. >> >>Thanks, >> >>Gonzalo >> >> >>3.5. Glare Situations >> >> Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user >> agent receiving an offer after having sent one but before having >> received an answer to it. That section specifies rules to avoid >> glare situations in most cases. When despite following those rules a >> glare conditions occurs (as a result of a race condition), it is >> handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. >> The UAS returns a 491 (Request Pending) response and the UAC retries >> the offer after a randomly-selected time, which depends on which user >> agent is the owner of the Call-ID of the dialog. The rules in RFC >> 3261 [RFC3261] not only cover collisions between re-INVITEs that >> contain offers; they cover collisions between two re-INVITEs in >> general, even if they do not contain offers. Sections 5.2 and 5.3 of >> RFC 3311 [RFC3311] extend those rules to also cover collisions >> between an UPDATE request carrying an offer and another message >> (UPDATE, PRACK or INVITE) also carrying an offer. >> >> Since re-INVITEs and UPDATEs can change not only the session state >> but also the dialog state, collisions among them need to be avoided >> even when they do not carry offers. Therefore, this document extends >> the rules just described to also cover collisions that do not involve >> offers. >> >> A UA that receives an UPDATE request on a dialog while an UPDATE >> request it had sent on that dialog is in progress MUST return a 491 >> (Request Pending) response to the received UPDATE request. >> >> If a UA receives a re-INVITE while an UPDATE request it had sent on >> that dialog is in progress and after receiving the re-INVITE the UA >> receives a 2xx response to the UPDATE request, the UA SHOULD generate >> a new UPDATE request or a reliable response to the re-INVITE in order >> to make sure that both UAs have a common view of the state of the >> session, as described in Section 3.4. >> >> The rules in RFC 3261 [RFC3261] do not cover collisions between an >> UPDATE request and a reliable response to a re-INVITE (non-2xx final >> responses to the re-INVITE are also considered reliable responses). >> Since both the UPDATE request and the reliable response could be >> requesting changes to the dialog or session state, it would not be >> clear which changes would need to be executed first. >> >> If the UAS of a re-INVITE transaction receives and UPDATE request >> after having sent a reliable response to the re-INVITE but before >> having received the corresponding ACK or PRACK request, the UA SHOULD >> return a 491 (Request Pending) response to the UPDATE request. > > For reference, here are my opinion regarding an interworking > of UPDATE and re-INVITE from an offer-answer perspective. > > Case 1: One or more O/A exchange and then 2xx to re-INVITE with an offer. > A B > | | > |INVITE(offer) | > +-----> +->|--------------------->| > | | | 1xx(answer)| > Don't send UPDATE | Don't send INVITE | |<---------------------| > 491 to UPDATE | 491 to INVITE | |PRACK | > | | |--------------------->| > | | | 2xx-PRA| > +-----> | |<---------------------| > may send UPDATE | | | | > may acceptUPDATE | | | 2xx| > | +->|<---------------------| > | may send INVITE | | | > | may accept INVITE | |ACK | > | | |--------------------->| > v v | | > > A B > | | > |INVITE(offer) | > |--------------------->|<-+ <-----+ > | 1xx(answer)| | | > |<---------------------| | Don't send INVITE | Don't send UPDATE > |PRACK | | 500 to INVITE | 500 to UPDATE > |--------------------->| | | > | 2xx-PRA| | | > |<---------------------| | <-----+ > | | | | may send UPDATE > | 2xx| | | may acceptUPDATE > |<---------------------|<-+ | > | | | may send INVITE | > |ACK | | may accept INVITE | > |--------------------->| | | > | | v v > > > Case 2: One or more O/A exchange and then 4xx to re-INVITE with an offer. > A B > [UAC behavior] | | > |INVITE(offer) | > +-----> +->|--------------------->| > | | | 1xx(answer)| > Don't send UPDATE | Don't send INVITE | |<---------------------| > 491 to UPDATE | 491 to INVITE | |PRACK | > | | |--------------------->| > | | | 2xx-PRA| > +-----> | |<---------------------| > may send UPDATE | | | | > may acceptUPDATE | | | non-2xx| > | +->|<---------------------| > | | | > | |ACK ACK | > | +->|---------> -------->| > v v | | > (4xx and ACk to it are atomic.) > > > A B > | | [UAS behavior] > |INVITE(offer) | > |--------------------->|<-+ <-----+ > | 1xx(answer)| | | > |<---------------------| | Don't send INVITE | Don't send UPDATE > |PRACK | | 500 to INVITE | 500 to UPDATE > |--------------------->| | | > | 2xx-PRA| | | > |<---------------------| | <-----+ > | | | | may send UPDATE > | non-2xx| | | may accept UPDATE > |<---------------------|<-+ | > | | | Don't send INVITE | > |ACK ACK | | may accept INVITE | > |---------> -------->|<-+ | > | | v v > > > Regards, > Shinji > >> If >> the UAC of a re-INVITE transaction sends an UPDATE request, receives >> a reliable response to the re-INVITE, and then a 2xx response to the >> UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE >> request in order to make sure that both UAs have a common view of the >> state of the session, as described in Section 3.4. >> >> If a UA receives a 491 response to an UPDATE request, it follows the >> rules in Section 5.3 of RFC 3311 [RFC3311]. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From brett@broadsoft.com Tue Jun 29 06:10:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC8C3A676A for ; Tue, 29 Jun 2010 06:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 552MCVfr4jNF for ; Tue, 29 Jun 2010 06:09:59 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 70B5F3A6BDA for ; Tue, 29 Jun 2010 06:09:59 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Tue, 29 Jun 2010 06:10:09 -0700 From: Brett Tate To: Gonzalo Camarillo , SIPCORE Date: Tue, 29 Jun 2010 06:08:54 -0700 Thread-Topic: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite Thread-Index: AcsTbHR6Hzbtaf8nRYq/VczJe+wfYwEFiFUA Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> References: <4C230507.10105@ericsson.com> In-Reply-To: <4C230507.10105@ericsson.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: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 13:10:00 -0000 Hi Gonzalo, Thanks for addressing most of my concerns. Comments are inline. > per the our mailing list discussions, I have edited Section 3.5 of the > draft so that the rules to detect and address glare conditions are > clearer, more explicit, and less restrictive. Let me know if the new > text meets any of these three goals :o) Yes; the text addresses my concerns about being too restricted on an early = dialog. If it isn't too late, I would still like the draft to clarify rfc3261 conce= rning updating dialog's route set and remote target per INVITE 101-299 resp= onse's Contact and Record-Route during call setup. It was requested within= the following thread. http://www.ietf.org/mail-archive/web/sipcore/current/msg01472.html=20 > Once we agree on the contents of this section, Section 4.5=20 > will not need to define further rules. Do you plan to remove or reword section 4.5? > Since re-INVITEs and UPDATEs can change not only the session state > but also the dialog state, collisions among them need to be avoided > even when they do not carry offers. Therefore, this document=20 > extends the rules just described to also cover collisions that do=20 > not involve offers. The last sentence is likely good enough; however to help avoid some from in= terpreting the non-normative text normatively, I recommend changing "cover = collisions" to "cover some collisions". From shinji.okumura@softfront.jp Tue Jun 29 23:27:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712343A6955 for ; Tue, 29 Jun 2010 23:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.795 X-Spam-Level: X-Spam-Status: No, score=-95.795 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+WUGf2N9CU5 for ; Tue, 29 Jun 2010 23:27:10 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 595983A6847 for ; Tue, 29 Jun 2010 23:27:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 1510A42800E; Wed, 30 Jun 2010 15:27:15 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CatO8FwouAnl; Wed, 30 Jun 2010 15:27:10 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id DF4EC42800D; Wed, 30 Jun 2010 15:27:09 +0900 (JST) From: OKUMURA Shinji To: SIPCORE Date: Wed, 30 Jun 2010 15:27:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C29E540.4050402@ericsson.com> References: <4C230507.10105@ericsson.com> <4C29E540.4050402@ericsson.com> Message-Id: Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 06:27:11 -0000 Hi Gonzalo, Thanks for your reply. My comments inline. Gonzalo Camarillo Tue, 29 Jun 2010 15:21:20 +0300 >Hi Shinji, > >thanks for your comments. My answers inline: (snip) >>> The rules in RFC 3261 [RFC3261] do not cover collisions between an >>> UPDATE request and a reliable response to a re-INVITE (non-2xx final >>> responses to the re-INVITE are also considered reliable responses). >>> Since both the UPDATE request and the reliable response could be >>> requesting changes to the dialog or session state, it would not be >>> clear which changes would need to be executed first. >>> >>> If the UAS of a re-INVITE transaction receives and UPDATE request >>> after having sent a reliable response to the re-INVITE but before >>> having received the corresponding ACK or PRACK request, the UA SHOULD >>> return a 491 (Request Pending) response to the UPDATE request. >> >> I think this rule is more restrictive. >> IMO; >> In case that the reliable response is 18x, the UA SHOULD return a "500" response. >> In case that the reliable response is 2xx; >> If the 2xx carries an offer, the UA SHOULD return a "500" response. >> Otherwise, the UA MAY return a 2xx response. >> In case that the reliable response is 4xx, the UA MAY return a 2xx response. > >No, these rules would not address the glare situation. I am very interested in this topic. Laying aside the response code, I don't understand the reason why these rules would not address the glare situation. Please explain the reason. In below cases, if a UAS returns a 2xx to the UPDATE, IMO no ploblem would be occured. A B | | s0|re-INVITE(offer1) |s0 |------------------------------>| | 2xx(answer1)| |<------------------------------|<-+ s1|ACK |s1| |--------------\ | | |UPDATE(offer2) \ | | |================\=============>| | accept PDATE | 2xx-UPD(answer2)| | |<=================\============| | s2| \ |s2| | \--------->| | | | v A B | | s0|re-INVITE(offer1) |s0 |------------------------------>| | non-2xx| |<------------------------------|<-+ s0|ACK |s0| |--------------> | | |UPDATE(offer2) | | |==============================>| | accept PDATE | 2xx-UPD(answer2)| | |<==============================| | s2| ACK |s2| | ---------->| | | | v A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------| | 2xx| | /--------------|<-+ |UPDATE(offer2) / | | |==============/===============>| | accept PDATE | / 2xx-UPD(answer2)| | |<===========/==================| | s2| / |s2| |<---------/ | | |ACK | | |------------------------------>| | | | v A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------| | non-2xx| | /--------------|<-+ |UPDATE(offer2) / |s0| |==============/===============>| | accept PDATE | / 2xx-UPD(answer2)| | |<===========/==================| | s2| / ACK |s2| |<---------/ ----------->| | s0|ACK | | |-------------> | | |UPDATE(offer0) | | |==============================>| | | 2xx-UPD(answer0)| | |<==============================| | s0| |s0| | | v >>> If >>> the UAC of a re-INVITE transaction sends an UPDATE request, receives >>> a reliable response to the re-INVITE, and then a 2xx response to the >>> UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE >>> request in order to make sure that both UAs have a common view of the >>> state of the session, as described in Section 3.4. >> >> In case that the reliable response is 4xx, this rule is necessary >> from an offer-answer perspective. > >Exactly. > >> In case that the reliable response is 2xx or 18x, this rule seems >> to be also necessary from a remote-target perspective. > >Exactly. > >> But I'm not sure at present. > >Your understanding is correct. > >> >>> If a UA receives a 491 response to an UPDATE request, it follows the >>> rules in Section 5.3 of RFC 3311 [RFC3311]. >> >> And I think the rules are insufficient. >> In the cases below, UA-A SHOULD send new offer after sending ACK. >> >> A B >> | | >> s0|re-INVITE (offer1) |s0 >> |------------------------------>| >> | 18x-rel(answer1)| >> |<------------------------------| >> s1| non-2xx|s1 >> | /--------------|<-+ >> |UPDATE(offer2) / |s0| >> |==============/===============>| | accept UPDATE >> | / 2xx-UPD(answer2)| | >> |<===========/==================| | >> s2| / ACK |s2| >> |<---------/ ----------->| | >> s0|ACK | | >> |-------------> | | >> |UPDATE(offer0) | | >> |==============================>| | >> | 2xx-UPD(answer0)| | >> |<==============================| | >> s0| |s0| >> | | v >> >> >> A B >> | | >> s0|re-INVITE (offer1) |s0 >> |------------------------------>| >> | 18x-rel(answer1)| >> |<------------------------------| >> s1| non-2xx|s1 >> | /------------|<-+ >> | / ACK |s0| >> | / -------->| | accept UPDATE >> | / UPDATE(offer2)| | >> |<=============/================| | >> |2xx-UPD(answer2) | | >> |============/=================>| | >> s2| / |s2| >> |<---------/ | | >> s0|ACK | | >> |-----------> | | >> |UPDATE(offer0) | | >> |==============================>| | >> | 2xx-UPD(answer0)| | >> |<==============================| | >> s0| |s0| >> | | v > >Yes, that rule is already specified in Section 3.4 of the draft. > >http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.4 You are right. I delude myself. Apart from that, The behavior of UAC seems to be separated in Section 3.4 and 3.5. I think it would be better to describe the whole behavior of UAC (including a glare situation) in Section 3.4. Regards, Shinji From gonzalo.camarillo@ericsson.com Wed Jun 30 00:25:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8353A693C for ; Wed, 30 Jun 2010 00:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.194 X-Spam-Level: X-Spam-Status: No, score=-105.194 tagged_above=-999 required=5 tests=[AWL=1.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLr7S8fnyYsw for ; Wed, 30 Jun 2010 00:24:59 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 01A773A691C for ; Wed, 30 Jun 2010 00:24:58 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-e9-4c2af155913e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.95.10125.551FA2C4; Wed, 30 Jun 2010 09:25:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 09:25:08 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 09:25:08 +0200 Message-ID: <4C2AF154.9040905@ericsson.com> Date: Wed, 30 Jun 2010 10:25:08 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: OKUMURA Shinji References: <4C230507.10105@ericsson.com> <4C29E540.4050402@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2010 07:25:08.0582 (UTC) FILETIME=[5E573060:01CB1825] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:25:00 -0000 Hi Shinji, thanks for your comments. My answers inline: > I am very interested in this topic. Laying aside the > response code, I don't understand the reason why these rules > would not address the glare situation. > Please explain the reason. > > In below cases, if a UAS returns a 2xx to the UPDATE, IMO > no ploblem would be occured. as we discussed in the past, the collision of two given messages may or may not be a problem. For example, two UPDATEs colliding each of them updating a different parameter would not be a problem... but if they update the same parameter the collision would get both UAs out of synch. For the sake of simplicity, instead of having UAs implement complex rules to figure out if a particular collision would cause problems, we specify general rules that are (relatively) easy to implement by user agents. So, let's take your example below > A B > | | > s0|re-INVITE (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1|PRACK |s1 > |------------------------------>| > | 2xx-PRA| > |<------------------------------| > | 2xx| > | /--------------|<-+ > |UPDATE(offer2) / | | > |==============/===============>| | accept PDATE > | / 2xx-UPD(answer2)| | > |<===========/==================| | > s2| / |s2| > |<---------/ | | > |ACK | | > |------------------------------>| | > | | v both the 2xx to the INVITE and the 2xx to the UPDATE can update the dialog's target. As you see, the UAC receives them in a different order than they were sent. So, for the UAC the latest target refresh was the 2xx to the INVITE but for the UAS the latest target refresh was the 2xx to the UPDATE. > You are right. I delude myself. > Apart from that, The behavior of UAC seems to be separated > in Section 3.4 and 3.5. I think it would be better to > describe the whole behavior of UAC (including a glare situation) > in Section 3.4. I will look into this while making the remaining changes I have to introduce. Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Wed Jun 30 00:31:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7603A67EE for ; Wed, 30 Jun 2010 00:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AlKRyjDzjHQ for ; Wed, 30 Jun 2010 00:31:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2B0AE3A6A1E for ; Wed, 30 Jun 2010 00:30:57 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-d4-4c2af2bbca57 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 81.6A.19600.BB2FA2C4; Wed, 30 Jun 2010 09:31:07 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 09:31:07 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 09:31:06 +0200 Message-ID: <4C2AF2BA.1070602@ericsson.com> Date: Wed, 30 Jun 2010 10:31:06 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brett Tate References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2010 07:31:06.0937 (UTC) FILETIME=[33EFD290:01CB1826] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:31:02 -0000 Hi Brett, thanks for your comments. Answers inline: > Yes; the text addresses my concerns about being too restricted on an > early dialog. perfect. > If it isn't too late, I would still like the draft to clarify > rfc3261 concerning updating dialog's route set and remote target per > INVITE 101-299 response's Contact and Record-Route during call setup. > It was requested within the following thread. > > http://www.ietf.org/mail-archive/web/sipcore/current/msg01472.html yes, I remember your request and I remember addressing it. For example, Section 4 of the draft explicitly states: "Section 4.2 specifies new rules for the handing of target- refresh requests. Note that the new rules apply to any target- refresh request, not only to re-INVITEs." Let me know if there is something in particular you want me to change in the draft regarding this issue. >> Once we agree on the contents of this section, Section 4.5 will >> not need to define further rules. > > Do you plan to remove or reword section 4.5? I will look into the structure of te draft once I have addressed all remaining comments. > The last sentence is likely good enough; however to help avoid some > from interpreting the non-normative text normatively, I recommend > changing "cover collisions" to "cover some collisions". Fixed. Thanks, Gonzalo From shinji.okumura@softfront.jp Wed Jun 30 04:11:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F733A67D9 for ; Wed, 30 Jun 2010 04:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.657 X-Spam-Level: X-Spam-Status: No, score=-96.657 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnvwKnIO5gpD for ; Wed, 30 Jun 2010 04:11:00 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 2DECB3A695A for ; Wed, 30 Jun 2010 04:10:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 1178242800E; Wed, 30 Jun 2010 20:11:10 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg4oDD3zWfKe; Wed, 30 Jun 2010 20:11:05 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id F228942800D; Wed, 30 Jun 2010 20:11:03 +0900 (JST) From: OKUMURA Shinji To: SIPCORE Date: Wed, 30 Jun 2010 20:10:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C2AF154.9040905@ericsson.com> References: <4C29E540.4050402@ericsson.com> <4C2AF154.9040905@ericsson.com> Message-Id: <53CB1844EA4162shinji.okumura@softfront.jp> Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 11:11:01 -0000 Hi Gonzalo, My comments inline. Gonzalo Camarillo Wed, 30 Jun 2010 10:25:08 +0300 >Hi Shinji, > >thanks for your comments. My answers inline: > >> I am very interested in this topic. Laying aside the >> response code, I don't understand the reason why these rules >> would not address the glare situation. >> Please explain the reason. >> >> In below cases, if a UAS returns a 2xx to the UPDATE, IMO >> no ploblem would be occured. > >as we discussed in the past, the collision of two given messages may or >may not be a problem. For example, two UPDATEs colliding each of them >updating a different parameter would not be a problem... but if they >update the same parameter the collision would get both UAs out of synch. >For the sake of simplicity, instead of having UAs implement complex >rules to figure out if a particular collision would cause problems, we >specify general rules that are (relatively) easy to implement by user >agents. IMO only the rule in a particular collisions is simplified, rule set is not always simplified as a whole. And I think normative restrictions can never be too small. In comparison of our proposal, [mine] A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------|<-+ | 2xx| | | /--------------| | |UPDATE(offer2) / | | |==============/===============>| | accept PDATE | / 2xx-UPD(answer2)| | |<===========/==================| | s2| / |s2| |<---------/ | | |ACK | | |------------------------------>| | | | v [yours] A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------|<-+ | 2xx| | accept PDATE | /--------------|<-+ |UPDATE(offer2) / | | |==============/===============>| | reject PDATE | / 2xx-UPD(answer2)| | |<===========/==================| | s2| / |s2| |<---------/ | | |ACK | | |------------------------------>|--+ | | v accept PDATE IMO your rules don't seem to be always easy to implement by user agents. >So, let's take your example below > >> A B >> | | >> s0|re-INVITE (offer1) |s0 >> |------------------------------>| >> | 18x-rel(answer1)| >> |<------------------------------| >> s1|PRACK |s1 >> |------------------------------>| >> | 2xx-PRA| >> |<------------------------------| >> | 2xx| >> | /--------------|<-+ >> |UPDATE(offer2) / | | >> |==============/===============>| | accept PDATE >> | / 2xx-UPD(answer2)| | >> |<===========/==================| | >> s2| / |s2| >> |<---------/ | | >> |ACK | | >> |------------------------------>| | >> | | v > > >both the 2xx to the INVITE and the 2xx to the UPDATE can update the >dialog's target. As you see, the UAC receives them in a different order >than they were sent. So, for the UAC the latest target refresh was the >2xx to the INVITE but for the UAS the latest target refresh was the 2xx >to the UPDATE. >From an offer-answer perspective, 2xx to the UPDATE doesn't occur a ploblem. >From a remote-target perspective, the consideration is more complicate. There is a variant case for a UAS. A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------|<-+ | 2xx| | |<------------------------------| | |ACK | | |-------------\ | | |UPDATE(offer2)\ | | |===============\==============>| | accept PDATE | 2xx-UPD(answer2)| | |<================\=============| | s2| \ |s2| | \---------->| | | | v In this case, 2xx to the UPDATE is no problem. And this 2xx to the UPDATE has one clear advantage. UAC(A) can refresh local target successfully. After all, UAC should send UPDATE or re-INVITE to confirm a remote target according to circumstances, even if the UPDATE doesn't carry an offer and UAS send a 2xx to a re-INVITE. At the very start I think this 2xx to UPDATE should have the same Contact whth 2xx to re-INVITE. And for reference, if this UPDATE is re-INVITE, according to current text UAS may accept the re-INVITE. Regards, Shinji >> You are right. I delude myself. >> Apart from that, The behavior of UAC seems to be separated >> in Section 3.4 and 3.5. I think it would be better to >> describe the whole behavior of UAC (including a glare situation) >> in Section 3.4. > >I will look into this while making the remaining changes I have to >introduce. > >Thanks, > >Gonzalo From gonzalo.camarillo@ericsson.com Wed Jun 30 05:03:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711813A6AA1 for ; Wed, 30 Jun 2010 05:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.196 X-Spam-Level: X-Spam-Status: No, score=-105.196 tagged_above=-999 required=5 tests=[AWL=1.403, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIi-A2f7kGsb for ; Wed, 30 Jun 2010 05:03:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 403AF3A69D2 for ; Wed, 30 Jun 2010 05:03:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-1a-4c2b3291455f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 44.6A.10125.1923B2C4; Wed, 30 Jun 2010 14:03:29 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 14:03:28 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 14:03:28 +0200 Message-ID: <4C2B328F.8050601@ericsson.com> Date: Wed, 30 Jun 2010 15:03:27 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: OKUMURA Shinji References: <4C29E540.4050402@ericsson.com> <4C2AF154.9040905@ericsson.com> <53CB1844EA4162shinji.okumura@softfront.jp> In-Reply-To: <53CB1844EA4162shinji.okumura@softfront.jp> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2010 12:03:28.0266 (UTC) FILETIME=[4020BEA0:01CB184C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 12:03:25 -0000 Hi Shinji, thanks for your comments. I already responded to your first example in my previous email. In your second example, the ACK (which does not carry an answer) is not a problem because it is not a target refresh request. Thanks, Gonzalo On 30/06/2010 2:10 PM, OKUMURA Shinji wrote: > Hi Gonzalo, > > My comments inline. > > Gonzalo Camarillo > Wed, 30 Jun 2010 10:25:08 +0300 >> Hi Shinji, >> >> thanks for your comments. My answers inline: >> >>> I am very interested in this topic. Laying aside the >>> response code, I don't understand the reason why these rules >>> would not address the glare situation. >>> Please explain the reason. >>> >>> In below cases, if a UAS returns a 2xx to the UPDATE, IMO >>> no ploblem would be occured. >> >> as we discussed in the past, the collision of two given messages may or >> may not be a problem. For example, two UPDATEs colliding each of them >> updating a different parameter would not be a problem... but if they >> update the same parameter the collision would get both UAs out of synch. >> For the sake of simplicity, instead of having UAs implement complex >> rules to figure out if a particular collision would cause problems, we >> specify general rules that are (relatively) easy to implement by user >> agents. > > IMO only the rule in a particular collisions is simplified, > rule set is not always simplified as a whole. > And I think normative restrictions can never be too small. > > In comparison of our proposal, > > [mine] > A B > | | > s0|re-INVITE (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1|PRACK |s1 > |------------------------------>| > | 2xx-PRA| > |<------------------------------|<-+ > | 2xx| | > | /--------------| | > |UPDATE(offer2) / | | > |==============/===============>| | accept PDATE > | / 2xx-UPD(answer2)| | > |<===========/==================| | > s2| / |s2| > |<---------/ | | > |ACK | | > |------------------------------>| | > | | v > > [yours] > A B > | | > s0|re-INVITE (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1|PRACK |s1 > |------------------------------>| > | 2xx-PRA| > |<------------------------------|<-+ > | 2xx| | accept PDATE > | /--------------|<-+ > |UPDATE(offer2) / | | > |==============/===============>| | reject PDATE > | / 2xx-UPD(answer2)| | > |<===========/==================| | > s2| / |s2| > |<---------/ | | > |ACK | | > |------------------------------>|--+ > | | v accept PDATE > > IMO your rules don't seem to be always easy to implement by user > agents. > >> So, let's take your example below >> >>> A B >>> | | >>> s0|re-INVITE (offer1) |s0 >>> |------------------------------>| >>> | 18x-rel(answer1)| >>> |<------------------------------| >>> s1|PRACK |s1 >>> |------------------------------>| >>> | 2xx-PRA| >>> |<------------------------------| >>> | 2xx| >>> | /--------------|<-+ >>> |UPDATE(offer2) / | | >>> |==============/===============>| | accept PDATE >>> | / 2xx-UPD(answer2)| | >>> |<===========/==================| | >>> s2| / |s2| >>> |<---------/ | | >>> |ACK | | >>> |------------------------------>| | >>> | | v >> >> >> both the 2xx to the INVITE and the 2xx to the UPDATE can update the >> dialog's target. As you see, the UAC receives them in a different order >> than they were sent. So, for the UAC the latest target refresh was the >> 2xx to the INVITE but for the UAS the latest target refresh was the 2xx >> to the UPDATE. > > From an offer-answer perspective, 2xx to the UPDATE doesn't > occur a ploblem. > > From a remote-target perspective, the consideration is > more complicate. > There is a variant case for a UAS. > > A B > | | > s0|re-INVITE (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1|PRACK |s1 > |------------------------------>| > | 2xx-PRA| > |<------------------------------|<-+ > | 2xx| | > |<------------------------------| | > |ACK | | > |-------------\ | | > |UPDATE(offer2)\ | | > |===============\==============>| | accept PDATE > | 2xx-UPD(answer2)| | > |<================\=============| | > s2| \ |s2| > | \---------->| | > | | v > > In this case, 2xx to the UPDATE is no problem. > And this 2xx to the UPDATE has one clear advantage. > UAC(A) can refresh local target successfully. > > After all, UAC should send UPDATE or re-INVITE to confirm a > remote target according to circumstances, even if the UPDATE > doesn't carry an offer and UAS send a 2xx to a re-INVITE. > > At the very start I think this 2xx to UPDATE should have the > same Contact whth 2xx to re-INVITE. > > And for reference, if this UPDATE is re-INVITE, according to > current text UAS may accept the re-INVITE. > > Regards, > Shinji > >>> You are right. I delude myself. >>> Apart from that, The behavior of UAC seems to be separated >>> in Section 3.4 and 3.5. I think it would be better to >>> describe the whole behavior of UAC (including a glare situation) >>> in Section 3.4. >> >> I will look into this while making the remaining changes I have to >> introduce. >> >> Thanks, >> >> Gonzalo From brett@broadsoft.com Wed Jun 30 05:21:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D30F3A6A61 for ; Wed, 30 Jun 2010 05:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGe1WNJ9NXq8 for ; Wed, 30 Jun 2010 05:21:47 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D45853A67B8 for ; Wed, 30 Jun 2010 05:21:46 -0700 (PDT) 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; Wed, 30 Jun 2010 05:21:57 -0700 From: Brett Tate To: Gonzalo Camarillo , SIPCORE Date: Wed, 30 Jun 2010 05:20:42 -0700 Thread-Topic: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite Thread-Index: AcsYJjXNkdd+28gFQJueQxVuh+j2xQAHz5+g Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> In-Reply-To: <4C2AF2BA.1070602@ericsson.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: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 12:21:52 -0000 > > If it isn't too late, I would still like the draft to clarify > > rfc3261 concerning updating dialog's route set and remote target=20 > > per INVITE 101-299 response's Contact and Record-Route during=20 > > call setup. It was requested within the following thread. > > > > http://www.ietf.org/mail-archive/web/sipcore/current/msg01472.html=20 >=20 > yes, I remember your request and I remember addressing it.=20 > For example, Section 4 of the draft explicitly states: >=20 > "Section 4.2 specifies new rules for the handing of target- > refresh requests. Note that the new rules apply to any target- > refresh request, not only to re-INVITEs." >=20 > Let me know if there is something in particular you want me to=20 > change in the draft regarding this issue. The quote and section 4's subsections provide no clarity concerning INVITE = 101-299 response's Contact and Record-Route during call setup (i.e. INVITE = versus re-INVITE). Concerning INVITE (not re-INVITE) 101-299 response handling on an existing = early dialog, I would like the draft to clarify the rfc3261 rules: - When MUST/SHOULD/MAY the UAC replace the dialog's remote target URI with = the URI from the Contact header field from 101-199 response? - When MUST/SHOULD/MAY the UAC update the dialog's route set using the Reco= rd-Route headers from 101-199 response? - When MUST/SHOULD/MAY the UAC replace the dialog's remote target URI with = the URI from the Contact header field from 2xx response? - When MUST/SHOULD/MAY the UAC update the dialog's route set using the Reco= rd-Route headers from 2xx response? The following rule only discusses reliable provisional responses. What are= rules for non reliable provisional responses? Draft-ietf-sipcore-reinvite section 4.3: "If the UAC receives a reliable pr= ovisional response or a 2xx response to the target-refresh request, the UAC= MUST replace the dialog's remote target URI with the URI from the Contact = header field in that response, if present." Thanks, Brett From gonzalo.camarillo@ericsson.com Wed Jun 30 05:28:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1823A686E for ; Wed, 30 Jun 2010 05:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcNV4sWE2w4c for ; Wed, 30 Jun 2010 05:28:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1171B3A679C for ; Wed, 30 Jun 2010 05:28:10 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-c8-4c2b3865dbd2 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A7.32.19600.5683B2C4; Wed, 30 Jun 2010 14:28:21 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 14:28:21 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 14:28:20 +0200 Message-ID: <4C2B3864.4050708@ericsson.com> Date: Wed, 30 Jun 2010 15:28:20 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brett Tate References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2010 12:28:20.0908 (UTC) FILETIME=[B9CFD6C0:01CB184F] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 12:28:15 -0000 Hi Brett, > The quote and section 4's subsections provide no clarity concerning > INVITE 101-299 response's Contact and Record-Route during call setup > (i.e. INVITE versus re-INVITE). > > Concerning INVITE (not re-INVITE) 101-299 response handling on an > existing early dialog, I would like the draft to clarify the rfc3261 > rules: OK, you want the text to be more explicit about what happens with early dialogs... I will look into that. > The following rule only discusses reliable provisional responses. > What are rules for non reliable provisional responses? non-reliable responses do not refresh the target because SIP does not provide any type of ordering for them. I can clarify that if you think it is unclear. Thanks, Gonzalo From brett@broadsoft.com Wed Jun 30 05:54:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8653A698D for ; Wed, 30 Jun 2010 05:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+VedGc97re9 for ; Wed, 30 Jun 2010 05:54:04 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 59EA43A68E4 for ; Wed, 30 Jun 2010 05:54:04 -0700 (PDT) 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; Wed, 30 Jun 2010 05:54:13 -0700 From: Brett Tate To: Gonzalo Camarillo Date: Wed, 30 Jun 2010 05:53:01 -0700 Thread-Topic: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite Thread-Index: AcsYT7u0l1x3tR5UT/ut00yMQaeT5gAABjsw Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC27@EXMBXCLUS01.citservers.local> References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> In-Reply-To: <4C2B3864.4050708@ericsson.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: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 12:54:05 -0000 > > The following rule only discusses reliable provisional responses. > > What are rules for non reliable provisional responses? >=20 > non-reliable responses do not refresh the target because SIP does not > provide any type of ordering for them. I can clarify that if you think > it is unclear. Yes; the rule/reason should be clearly documented since there are vendors t= hat MAY be sending such target changes and MAY be honoring such a target ch= ange because of lack of 100rel and UPDATE support (or other reasons). Thus= if the rule is that they MUST/SHOULD NOT be sending/honoring such a target= change, it should be documented. Thanks, Brett From gao.yang2@zte.com.cn Wed Jun 30 06:17:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB2628C0E5 for ; Wed, 30 Jun 2010 06:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.286 X-Spam-Level: X-Spam-Status: No, score=-98.286 tagged_above=-999 required=5 tests=[AWL=3.551, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiaGJb9gy1cm for ; Wed, 30 Jun 2010 06:17:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 96C333A6830 for ; Wed, 30 Jun 2010 06:17:09 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 383431727820181; Wed, 30 Jun 2010 21:16:49 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 2748.4865307408; Wed, 30 Jun 2010 21:17:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5UDHRta041632; Wed, 30 Jun 2010 21:17:27 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C2B3864.4050708@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 30 Jun 2010 21:14:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-30 21:17:10, Serialize complete at 2010-06-30 21:17:10 Content-Type: multipart/alternative; boundary="=_alternative 0048EB2F48257752_=" X-MAIL: mse2.zte.com.cn o5UDHRta041632 Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:17:11 -0000 This is a multipart message in MIME format. --=_alternative 0048EB2F48257752_= Content-Type: text/plain; charset="US-ASCII" Hi Gonzalo, > > The quote and section 4's subsections provide no clarity concerning > > INVITE 101-299 response's Contact and Record-Route during call setup > > (i.e. INVITE versus re-INVITE). > > > > Concerning INVITE (not re-INVITE) 101-299 response handling on an > > existing early dialog, I would like the draft to clarify the rfc3261 > > rules: > > OK, you want the text to be more explicit about what happens with early > dialogs... I will look into that. I am OK with adding text about Ini-INVITE. And I think that, it might better to add some kind of remark for the Ini-INVITE topics in the text, in the Abstract or Introduction sections, as the name of the text is for Re-INVITE :) > > The following rule only discusses reliable provisional responses. > > What are rules for non reliable provisional responses? > > non-reliable responses do not refresh the target because SIP does not > provide any type of ordering for them. I can clarify that if you think > it is unclear. +1. As explicitly text would make thing clear for interworking issue. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0048EB2F48257752_= Content-Type: text/html; charset="US-ASCII"

Hi Gonzalo,

> > The quote and section 4's subsections provide no clarity concerning
> > INVITE 101-299 response's Contact and Record-Route during call setup
> > (i.e. INVITE versus re-INVITE).
> >
> > Concerning INVITE (not re-INVITE) 101-299 response handling on an
> > existing early dialog, I would like the draft to clarify the rfc3261
> > rules:
>
> OK, you want the text to be more explicit about what happens with early
> dialogs... I will look into that.

I am OK with adding text about Ini-INVITE.
And I think that, it might better to add some kind of remark for the Ini-INVITE topics in the text, in the Abstract or Introduction sections, as the name of the text is for Re-INVITE :)

> > The following rule only discusses reliable provisional responses.
> > What are rules for non reliable provisional responses?
>
> non-reliable responses do not refresh the target because SIP does not
> provide any type of ordering for them. I can clarify that if you think
> it is unclear.
+1. As explicitly text would make thing clear for interworking issue.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0048EB2F48257752_=-- From pkyzivat@cisco.com Wed Jun 30 06:43:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0F83A6A91 for ; Wed, 30 Jun 2010 06:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.24 X-Spam-Level: X-Spam-Status: No, score=-10.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2EMas86ai02 for ; Wed, 30 Jun 2010 06:43:30 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B9AFC3A6ADB for ; Wed, 30 Jun 2010 06:43:29 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIfmKkxAZnwM/2dsb2JhbACfW3Gla5oqhSUEiCM X-IronPort-AV: E=Sophos;i="4.53,513,1272844800"; d="scan'208";a="127317016" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2010 13:43:38 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5UDhc6U003770; Wed, 30 Jun 2010 13:43:38 GMT Message-ID: <4C2B4A09.3090006@cisco.com> Date: Wed, 30 Jun 2010 09:43:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> In-Reply-To: <4C2B3864.4050708@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:43:31 -0000 Gonzalo Camarillo wrote: >> The following rule only discusses reliable provisional responses. >> What are rules for non reliable provisional responses? > > non-reliable responses do not refresh the target because SIP does not > provide any type of ordering for them. I can clarify that if you think > it is unclear. Hmm. I think that is debatable. That logic would suggest that non-reliable provisionals also could not establish an early dialog in the first place, since there might have been more than one with different targets that got reordered. My reading of 3261 and 3311 leaves me with the conclusion that I could receive a non-reliable provisional, consider that to establish an early dialog, and then send an UPDATE, without ever using 100rel. OTOH, there is logic to your argument. So maybe what you propose is the "right" solution even if it is to some extent incompatible with things as they stand. If so, then there should be an additional explicit statement that non-reliable provisionals never establish an early dialog. That would also mean that INFO could not be used before 2xx unless 100rel was used to establish the early dialog. Thanks, Paul From gonzalo.camarillo@ericsson.com Wed Jun 30 06:56:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8609D3A6833 for ; Wed, 30 Jun 2010 06:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.234 X-Spam-Level: X-Spam-Status: No, score=-105.234 tagged_above=-999 required=5 tests=[AWL=1.365, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXiam0ELbMMX for ; Wed, 30 Jun 2010 06:56:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3663C3A67F6 for ; Wed, 30 Jun 2010 06:56:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-a5-4c2b4cfb0c08 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 86.2A.10125.BFC4B2C4; Wed, 30 Jun 2010 15:56:11 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 15:56:10 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 15:56:10 +0200 Message-ID: <4C2B4CF9.9000103@ericsson.com> Date: Wed, 30 Jun 2010 16:56:09 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brett Tate References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> In-Reply-To: <4C2B3864.4050708@ericsson.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2010 13:56:10.0674 (UTC) FILETIME=[FED65120:01CB185B] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:56:02 -0000 Hi Brett, > OK, you want the text to be more explicit about what happens with early > dialogs... I will look into that. I propose to address early dialogs by adding a new section right after Section 4.5 (the new section would be 4.6) as follows: 4.6 Early Dialogs The rules given in this section about which messages can refresh the target of a dialog also apply to early dialogs created by an initial INVITE transaction. Additionally, as specified in Section 13.2.2.4 of RFC 3261 [RFC3261], on receiving a 2xx response to the initial INVITE, the UAC recomputes the whole route set of the dialog, which transitions from the "early" state to the "confirmed" state. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Wed Jun 30 06:58:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAAE3A69A0 for ; Wed, 30 Jun 2010 06:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu-zHlhGtDGw for ; Wed, 30 Jun 2010 06:58:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2B68D3A6A2F for ; Wed, 30 Jun 2010 06:58:29 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-76-4c2b4d90dc0a Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.FE.19600.09D4B2C4; Wed, 30 Jun 2010 15:58:40 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 15:58:39 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 15:58:39 +0200 Message-ID: <4C2B4D8D.70906@ericsson.com> Date: Wed, 30 Jun 2010 16:58:37 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2010 13:58:39.0233 (UTC) FILETIME=[57629F10:01CB185C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:58:31 -0000 Hi Gao, > I am OK with adding text about Ini-INVITE. > And I think that, it might better to add some kind of remark for the > Ini-INVITE topics in the text, in the Abstract or Introduction sections, > as the name of the text is for Re-INVITE :) All that text already talks about target refreshes (in addition to re-INVITEs). So, it already covers what we are talking about here. Thanks, Gonzalo From pkyzivat@cisco.com Wed Jun 30 07:07:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CE13A6A1F for ; Wed, 30 Jun 2010 07:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.247 X-Spam-Level: X-Spam-Status: No, score=-10.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmLDgi2rEzaU for ; Wed, 30 Jun 2010 07:07:12 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CACE93A6A40 for ; Wed, 30 Jun 2010 07:07:11 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALDrKkxAZnwM/2dsb2JhbACfW3GmMZonhSUEiCM X-IronPort-AV: E=Sophos;i="4.53,513,1272844800"; d="scan'208";a="127185026" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Jun 2010 14:07:22 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5UE7Mhg013508; Wed, 30 Jun 2010 14:07:22 GMT Message-ID: <4C2B4F99.9020707@cisco.com> Date: Wed, 30 Jun 2010 10:07:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> <4C2B4A09.3090006@cisco.com> In-Reply-To: <4C2B4A09.3090006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 14:07:13 -0000 Replying to myself, Perhaps the answer here is that a non-reliable response to an initial INVITE can indeed establish an early dialog. But then the contact address in all subsequent non-reliable responses must remain identical to that in the first non-reliable response. And Contacts received in non-reliable responses, except the first one received, must be ignored. That would allow use of INFO and UPDATE in an early dialog without 100rel, and even a remote target change via the UPDATE in that case. Thanks, Paul Paul Kyzivat wrote: > > > Gonzalo Camarillo wrote: > >>> The following rule only discusses reliable provisional responses. >>> What are rules for non reliable provisional responses? >> >> non-reliable responses do not refresh the target because SIP does not >> provide any type of ordering for them. I can clarify that if you think >> it is unclear. > > Hmm. I think that is debatable. > > That logic would suggest that non-reliable provisionals also could not > establish an early dialog in the first place, since there might have > been more than one with different targets that got reordered. > > My reading of 3261 and 3311 leaves me with the conclusion that I could > receive a non-reliable provisional, consider that to establish an early > dialog, and then send an UPDATE, without ever using 100rel. > > OTOH, there is logic to your argument. So maybe what you propose is the > "right" solution even if it is to some extent incompatible with things > as they stand. If so, then there should be an additional explicit > statement that non-reliable provisionals never establish an early dialog. > > That would also mean that INFO could not be used before 2xx unless > 100rel was used to establish the early dialog. > > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Wed Jun 30 07:35:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53513A6A38 for ; Wed, 30 Jun 2010 07:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoFjUX3j7K50 for ; Wed, 30 Jun 2010 07:35:46 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 3F0183A69B5 for ; Wed, 30 Jun 2010 07:35:46 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Wed, 30 Jun 2010 07:35:56 -0700 From: Brett Tate To: Gonzalo Camarillo Date: Wed, 30 Jun 2010 07:34:44 -0700 Thread-Topic: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite Thread-Index: AcsYXAFzIOye+0gGTEuN17EBhVa2OwAAjkyw Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC7A@EXMBXCLUS01.citservers.local> References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> <4C2B4CF9.9000103@ericsson.com> In-Reply-To: <4C2B4CF9.9000103@ericsson.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: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 14:35:48 -0000 Hi Gonzalo, If adjustments are added to the other sections to clearly discuss non relia= ble provisional responses, the proposal appears to adequately clarify RFC 3= 261. My understanding of the new section is that an INVITE 2xx response's update= d Contact can trigger the UAC to update the remote-target. The clarificati= on is not because of the last sentence, it is because of the first sentence= . If this is not true, please explain. Thanks, Brett > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Wednesday, June 30, 2010 9:56 AM > To: Brett Tate > Cc: SIPCORE > Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite >=20 > Hi Brett, >=20 > > OK, you want the text to be more explicit about what happens with > early > > dialogs... I will look into that. >=20 > I propose to address early dialogs by adding a new section right after > Section 4.5 (the new section would be 4.6) as follows: >=20 > 4.6 Early Dialogs >=20 > The rules given in this section about which messages can refresh the > target of a dialog also apply to early dialogs created by an initial > INVITE transaction. Additionally, as specified in Section 13.2.2.4 of > RFC 3261 [RFC3261], on receiving a 2xx response to the initial INVITE, > the UAC recomputes the whole route set of the dialog, which transitions > from the "early" state to the "confirmed" state. >=20 > Cheers, >=20 > Gonzalo From paulej@packetizer.com Wed Jun 30 21:51:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2723A67FA for ; Wed, 30 Jun 2010 21:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=1.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mj2R1+3CZ8Q for ; Wed, 30 Jun 2010 21:51:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id D32153A683E for ; Wed, 30 Jun 2010 21:51:05 -0700 (PDT) Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o614pBOe019841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Jul 2010 00:51:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1277959877; bh=owLVFq2mo8CC+pijhktQ9alKDTvrnGnUaNSbml+KfQ0=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=IfcPmjzm/yvnUF5KznsiLnN3JFBxW58rLwv7g2A/ZXT3c4GR45MuPdgXqyOa8QCFi R9cNqHo3wWiZzrdZSFCMr00va9BPyHsPQKQx4QJryWfS1o4qgs3ASqhqMLOEMRMKB+ /P6wziJkUW5EZDzxExm5Q8GpUgJz/iErIEBtYyL0= From: "Paul E. Jones" To: Date: Thu, 1 Jul 2010 00:51:03 -0400 Message-ID: <037201cb18d9$05dab420$11901c60$@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: AcsY2QJwBqYOslVTQQGnNjvAJ/BSxQ== Content-Language: en-us Subject: [sipcore] Revised draft-jones-sip-options-ping-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 04:51:11 -0000 Folks, I just wanted to bring to your attention the fact that we've submitted a new revised version of the OPTIONS "ping" draft. This document contains input from a number of folks who provided comments to me on various aspects of the draft. We had some discussion of moving this work to the SIP Overload Control (SOC) WG. Given my current understanding of the scope of the SOC WG, I do not think that OPTIONS falls within the scope of their charter. Further, this document was never produced for the purpose of providing an overload mechanism, either. I would like to have some further dialog on this document. I've received some positive feedback from several people, as this has been seen as a useful first step in trying to define use of OPTIONS as a "ping" mechanism that is interoperable. As I had mentioned before, there are several different variants of the same procedure in production networks and I think it's useful that we reach some agreement on how OPTIONS should be used as an application-level "ping", as RFC 3261 is a bit light on detail in this area. I know I might not have captured every comment, but that's because the discussions went in a variety of directions last time. :-) So, my edits were primarily editorial or to add clarity to what was already written. Comments are most certainly welcome. Paul > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Thursday, July 01, 2010 12:30 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-jones-sip-options-ping-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Using OPTIONS to Query for Operational Status in > the Session Initiation Protocol (SIP) > Author(s) : V. Bhargava, et al. > Filename : draft-jones-sip-options-ping-02.txt > Pages : 8 > Date : 2010-06-30 > > This document describes a procedure for using the Session Initiation > Protocol (SIP) OPTIONS method in order to allow one SIP entity to query > the operational status of another SIP entity. Through discovery of the > status of a SIP entity, it is possible to expedite session establishment > or provide diagnostic information to network administrators. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-sip-options-ping-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft.