From exim@www1.ietf.org Mon Mar 1 03:58:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03426 for ; Mon, 1 Mar 2004 03:58:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxjFl-00036k-Rz for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 03:58:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218wLT8011939 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 03:58:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxjFS-00034r-QN; Mon, 01 Mar 2004 03:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxjEv-00033g-Va for sip@optimus.ietf.org; Mon, 01 Mar 2004 03:57:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03367 for ; Mon, 1 Mar 2004 03:57:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxjEt-0000nM-00 for sip@ietf.org; Mon, 01 Mar 2004 03:57:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxjDv-0000ib-00 for sip@ietf.org; Mon, 01 Mar 2004 03:56:29 -0500 Received: from ns.itginc.jp ([210.166.209.138]) by ietf-mx with esmtp (Exim 4.12) id 1AxjD1-0000aL-00 for sip@ietf.org; Mon, 01 Mar 2004 03:55:31 -0500 Received: from vivian ([61.170.252.172]) by ns.itginc.jp (8.12.8/8.12.8) with SMTP id i218tLik020712 for ; Mon, 1 Mar 2004 17:55:23 +0900 Message-ID: <000901c3ff6a$941905f0$6600a8c0@vivian> From: "vivian huang" To: "sip" References: <4035F586.1000405@ericsson.com> <403A4FA6.8040407@nortelnetworks.com> <403AFE24.9020504@ericsson.com> <403CFEAD.3050300@nortelnetworks.com> <403DE5D9.3020507@ericsson.com> <403DEDD9.60704@nortelnetworks.com> Date: Mon, 1 Mar 2004 16:52:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Sip] help:can\t find ioctl function in redhat 9 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGksIGFsbA0KSSBqdXN0IHJ1biBhIHNpcHNpcHJveGQgYXQgbXkgcmVkaGF0IGxpbnV4IDkuIGJ1 dCBJIGdldCB0aGlzIGVycm9yIG1lc3NhZ2VzIGluIG15IC92YXIvbG9nL21lc3NhZ2VzIg0KDQpz ZXJ2ZXIgc2lwcm94ZDogdXRpbHMuYzozNjUgRVJST1I6RXJyb3IgaW4gaW9jdGwgU0lPQ0dJRkZM QUdTOiBObyBzdWNoIGRldmljZSANCg0KDQpEbyBhbnkgZ3V5cyBoZXJlIGtub3cgYWJvdXQgdGhp cyBpc3N1ZT8NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRvbSBU YXlsb3IiIDx0YXlsb3JAbm9ydGVsbmV0d29ya3MuY29tPg0KVG86ICJHb256YWxvIENhbWFyaWxs byIgPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT4NCkNjOiAiQ2hyaXN0ZXIgSG9sbWJl cmcgKEpPL0xNRikiIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyAic2lwIiA8c2lw QGlldGYub3JnPjsgIlJvaGFuIE1haHkiIDxyb2hhbkBjaXNjby5jb20+OyAiRGVhbiBXaWxsaXMi IDxkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2 LCAyMDA0IDk6MDAgUE0NClN1YmplY3Q6IFtTaXBdIFJlOiBJTkZPIERvY3VtZW50YXRpb24gKHdh cyBSZTogRGVmaW5pbmcgbmV3IHJlcXVlc3RzKQ0KDQoNCj4gQXMgYSBmaXJzdCBzdGVwLCBJJ2xs IHN1Ym1pdCB0aGUgUS4xOTEyLjUgYW5uZXggYXMgYW4gSS1ELiAgSSBleHBlY3Qgd2UnbGwgY29y cmVjdCANCj4gaXQgdG8gdXNlIFVQREFURSByYXRoZXIgdGhhbiBCWUUgYXMgdGhlIG1vZGVsIGlu IEdlbmV2YSBpbiB0aGUgbmV4dCBjb3VwbGUgb2YgDQo+IHdlZWtzLCBzbyB3aGF0IEkgc3VibWl0 IHdpbGwgcmVmbGVjdCB0aGF0Lg0KPiANCj4gR29uemFsbyBDYW1hcmlsbG8gd3JvdGU6DQo+IA0K PiA+IFRvbS4NCj4gPiANCj4gPiBpdCBzZWVtcyB0aGF0IHdoYXQgeW91IHdhbnQgaXMgYW4gdXBk YXRlIG9mIHRoZSBJTkZPIHNwZWMsIHJhdGhlciB0aGFuIA0KPiA+IGZpeGluZyBhIGZldyBlcnJh dGEuIEkgYmVsaWV2ZSB0aGF0IHdlIGNhbm5vdCBtZWV0IHlvdXIgdGltZWZyYW1lLiBJbiANCj4g PiBhbnkgZXZlbnQsIGl0IHdvdWxkIGJlIGdyZWF0IHdlIGNvdWxkIHN0YXJ0IHdvcmtpbmcgb24g YSBzb2x1dGlvbiBmb3IgDQo+ID4gSU5GTyBpbiBTSVBQSU5HLCBzbyB0aGF0IHRoZSBJVFUgY291 bGQgcmVmZXJlbmNlIGl0IGluIHRoZSBmdXR1cmUuDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IA0K PiA+IEdvbnphbG8NCj4gPiANCj4gPiBUb20gVGF5bG9yIHdyb3RlOg0KPiA+IA0KPiA+PiBRLjE5 MTIuNSBpcyBpbiB0aGUgcHJvY2VzcyBvZiBmaW5hbCBhcHByb3ZhbC4gIExvZ2dpbmcgZXJyYXRh IG1heSBiZSANCj4gPj4gc2F0aXNmYWN0b3J5IC0tIEknZCBoYXZlIHRvIGNoZWNrLiAgSXQgd291 bGQgY2VydGFpbmx5IGJlIG1vcmUgDQo+ID4+IGNvbWZvcnRhYmxlIHRoYW4gcmVwcm9kdWNpbmcg dGhlIFJGQyB3aXRoIG1vZGlmaWNhdGlvbnMgaW4gdGhlIElUVSANCj4gPj4gZG9jdW1lbnQuICBJ ZiB0aGUgSUVURiBhY3RzIHdpdGhpbiB0aGUgbmV4dCB0d28gd2Vla3Mgd2Ugc2hvdWxkIGJlIA0K PiA+PiBhYmxlIHRvIHJlbW92ZSB0aGUgQW5uZXggZnJvbSB0aGUgUmVjb21tZW5kYXRpb24uDQo+ ID4+DQo+ID4+IEhlcmUgaXMgdGhlIGN1cnJlbnQgbGlzdCBvZiBjaGFuZ2VzIGFzIHJlcG9ydGVk IGF0IHRoZSBiZWdpbm5pbmcgb2YgDQo+ID4+IHRoZSBBbm5leC4NCj4gPj4NCj4gPj4gIlRoZSBT SVAgSU5GTyBtZXRob2QgaXMgZG9jdW1lbnRlZCBpbiBSRkMgMjk3Ni4gSG93ZXZlciwgdGhhdCBS RkMgDQo+ID4+IHJlZmVycyB0byBSRkMgMjU0MywgdGhlIHByZXZpb3VzIHZlcnNpb24gb2YgdGhl IFNJUCBzcGVjaWZpY2F0aW9uLCANCj4gPj4gcmF0aGVyIHRoYW4gdG8gUkZDIDMyNjEuIFRoZSB0 ZXh0IG9mIHRoaXMgQW5uZXggcmVwcm9kdWNlcyBSRkMgMjk3NiANCj4gPj4gd2l0aCBjaGFuZ2Vz IHRvIHJlZmxlY3QgdGhlIHVwZGF0ZWQgcmVmZXJlbmNlLg0KPiA+Pg0KPiA+PiAiVGhlIGNoYW5n ZXMgbWFkZSBhcmUgYXMgZm9sbG93czoNCj4gPj4NCj4gPj4gIlBhcmFncmFwaCBDLjMuMi4xOiBU aGUgcmVmZXJlbmNlcyB0byB0aGUgdGFibGVzIG9mIFJGQzI1NDMgd2VyZSANCj4gPj4gY2hhbmdl ZCB0byByZWZsZWN0IHRoZSBuZXcgdGFibGUgb3JnYW5pemF0aW9uIGluIFJGQyAzMjYxLg0KPiA+ Pg0KPiA+PiAiUGFyYWdyYXBoIEMuMy4yOiBUaGUgdGFibGVzIDEgYW5kIDIgd2VyZSByZXBsYWNl ZCBieSBuZXcgdGFibGVzIHRoYXQgDQo+ID4+IHNob3cgdGhlIGhlYWRlciBmaWVsZHMgZGVmaW5l ZCBhcyBwcmVzZW50ZWQgaW4gUkZDMzI2MS4gQWxsIGFkZGl0aW9uYWwgDQo+ID4+IGhlYWRlcnMg KGFkZGl0aW9uYWwgdG8gUkZDIDI1NDMpIHVzZWQgd2l0aGluIFJGQzMyNjEgd2VyZSBoZXJlIHNl dCB0byANCj4gPj4gb3B0aW9uYWwgd2l0aCB0d28gZXhjZXB0aW9ucy4gVGhlIFJlcGx5LVRvIChv bmx5IG9wdGlvbmFsIGZvciB0aGUgDQo+ID4+IElOVklURSkgYW5kIENhbGwtSW5mbyBIZWFkZXIg KG9ubHkgdXNlZCBmb3IgSU5WSVRFLCBPUFRJT05TLCBSRUdJU1RFUiANCj4gPj4gdG8gZ2l2ZSBh ZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjYWxsZXIgb3IgY2FsbGVlKSBhcmUgbm90 IA0KPiA+PiB1c2VkIHdpdGggdGhlIElORk8gbWV0aG9kLg0KPiA+Pg0KPiA+PiAiUGFyYWdyYXBo IEMuMy42OiBUaGUgcmVmZXJlbmNlIHdhcyBjaGFuZ2VkIHRvIHRoZSBjdXJyZW50IFNJUCANCj4g Pj4gc3BlY2lmaWNhdGlvbiwgUkZDIDMyNjEuDQo+ID4+DQo+ID4+DQo+ID4+IEdvbnphbG8gQ2Ft YXJpbGxvIHdyb3RlOg0KPiA+Pg0KPiA+Pj4gVG9tLA0KPiA+Pj4NCj4gPj4+IHdoYXQgaXMgdGhl IHRpbWVmcmFtZSBoZXJlPyBBcyB5b3Uga25vdywgd2UgaGF2ZSBoYWQgZGlzY3Vzc2lvbnMgaW4g DQo+ID4+PiB0aGUgcGFzdCBhYm91dCBlaXRoZXIgcmUtZGVmaW5pbmcgSU5GTyBzbyB0aGF0IGl0 IGNhbiBvbmx5IGNhcnJ5IFBTVE4gDQo+ID4+PiB0ZWxlcGhvbnkgc2lnbmFsbGluZywgb3IgZGVm aW5pbmcgSU5GTyBwYWNrYWdlcy4gV2UgY291bGQgcmUtc3RhcnQgDQo+ID4+PiB0aG9zZSBkaXNj dXNzaW9ucywgYW5kIG9uY2Ugd2UgcmVhY2ggYSBjb25jbHVzaW9uLCBjbGFyaWZ5IHRoZSBydWxl cyANCj4gPj4+IHRvIHNlbmQgSU5GTyBmcm9tIHRoZSBVQVMgd2l0aGluIGVhcmx5IGRpYWxvZ3Mg aW4gdGhlIHNhbWUgc3BlYy4uLg0KPiA+Pj4NCj4gPj4+IElmIHRoZSBJVFUgaXMgaW4gYSBodXJy eSwgb3RoZXIgc29sdXRpb25zIG1heSBiZSBiZXR0ZXIsIGxpa2UgbG9nZ2luZyANCj4gPj4+IGFu IGVycmF0YSBhZ2FpbnN0IHRoZSBJTkZPIFJGQy4NCj4gPj4+DQo+ID4+PiBHb256YWxvDQo+ID4+ Pg0KPiA+Pj4gVG9tIFRheWxvciB3cm90ZToNCj4gPj4+DQo+ID4+Pj4gVGhlIElUVS1UIChTdHVk eSBHcm91cCAxMSwgdG8gYmUgZXhhY3QpIGhhZCBhIGRpZmZlcmVudCBpc3N1ZSB3aXRoIA0KPiA+ Pj4+IElORk86IHRoYXQgdGhlIFJGQyBkZXBlbmRzIG9uIFJGQyAyNTQzIHJhdGhlciB0aGFuIDMy NjEuICBBcyBhIA0KPiA+Pj4+IHJlc3VsdCwgdGhleSBwaWNrZWQgdXAgdGhlIGNvbnRlbnQgb2Yg UkZDIDI5NzYgYXMgQW5uZXggQy4zIG9mIHRoZSANCj4gPj4+PiBJU1VQIGludGVyd29ya2luZyBz cGVjaWZpY2F0aW9uIFEuMTkxMi41LiAgSWYgUkZDIDI5NzYgZXZlciBnZXRzIA0KPiA+Pj4+IHVw ZGF0ZWQgQW5uZXggQy4zIGNhbiBiZSBkZXByZWNhdGVkLiAgSW4gdGhlIG1lYW50aW1lLCB0aGlz IElORk8gDQo+ID4+Pj4gcXVlc3Rpb24gbWVhbnMgd2UgaGF2ZSBzb21lIG1haW50ZW5hbmNlIHRv IHBlcmZvcm0uICBJIHRoaW5rIHRoZSANCj4gPj4+PiBiZXN0IHNvbHV0aW9uIHdpbGwgYmUgdG8g dGFrZSBHb256YWxvJ3Mgc3VnZ2VzdGlvbiBhbmQgc2F5IHRoYXQgSU5GTyANCj4gPj4+PiBmb2xs b3dzIHRoZSBydWxlcyBmb3IgVVBEQVRFLiAgV2UgYWxyZWFkeSBoYXZlIGEgbm9ybWF0aXZlIA0K PiA+Pj4+IGRlcGVuZGVuY3kgb24gdGhlIFVQREFURSBSRkMuDQo+ID4+Pj4NCj4gPj4+PiBHb256 YWxvIENhbWFyaWxsbyB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+PiBDaHJpc3RlciwNCj4gPj4+Pj4N Cj4gPj4+Pj4gd291bGQgdGhlIElUVS1UIGJlIGhhcHBpZXIgaWYgd2UgbG9nIGFuIGVycmF0YSBh Z2FpbnN0IHRoZSBJTkZPIFJGQyANCj4gPj4+Pj4gc2F5aW5nIHRoYXQgVUFTcyBjYW4gc2VuZCBJ TkZPIHdpdGhpbiBlYXJseSBkaWFsb2dzPw0KPiA+Pj4+Pg0KPiA+Pj4+PiBHb256YWxvDQo+ID4+ Pj4+DQo+ID4+Pj4+IENocmlzdGVyIEhvbG1iZXJnIChKTy9MTUYpIHdyb3RlOg0KPiA+Pj4+Pg0K PiA+Pj4+Pj4gSGkgR29uemFsbywNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFua3MgZm9yIHlvdXIg cmVwbHkhDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBpdCBzZWVtcyB0aGF0IHNvbWUg cGVvcGxlIGluIHRoZSBJVFUtVCBhcmUgaGF2aW5nIHNvbWUgaXNzdWVzIA0KPiA+Pj4+Pj4+IGZp Z3VyaW5nIG91dCB3aGV0aGVyIG9yIG5vdCBjZXJ0YWluIHJlcXVlc3RzIGNhbiBiZSBzZW50IGJ5 IHRoZSBVQVMNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IHdpdGhpbiBhbg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBlYXJs eSBkaWFsb2cuIFRoZSBjb25mdXNpb24gY29tZXMgZnJvbSBzdGF0ZW1lbnRzIGxpa2UgdGhpcyBv bmUgDQo+ID4+Pj4+Pj4gKHRha2VuIGZyb20gdGhlIElORk8gc3BlYyk6DQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PiAiICAgICBVbmxlc3Mgc3RhdGVkIG90aGVyd2lzZSwgdGhlIHByb3RvY29sIHJ1bGVz IGZvciB0aGUgSU5GTyANCj4gPj4+Pj4+PiByZXF1ZXN0DQo+ID4+Pj4+Pj4gICAgICAgZ292ZXJu aW5nIHRoZSB1c2FnZSBvZiB0YWdzLCBSb3V0ZSBhbmQgUmVjb3JkLVJvdXRlLA0KPiA+Pj4+Pj4+ ICAgICAgIHJldHJhbnNtaXNzaW9uIGFuZCByZWxpYWJpbGl0eSwgQ1NlcSBpbmNyZW1lbnRpbmcg YW5kIG1lc3NhZ2UNCj4gPj4+Pj4+PiAgICAgICBmb3JtYXR0aW5nIGZvbGxvdyB0aG9zZSBpbiBb MV0gYXMgZGVmaW5lZCBmb3IgdGhlIEJZRSANCj4gPj4+Pj4+PiByZXF1ZXN0LiINCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IFNpbmNlIGEgVUFTIGRvZXMgbm90IHNlbmQgQllFcyB3aXRoaW4gYW4gZWFy bHkgZGlhbG9nLCBidXQgYSANCj4gPj4+Pj4+PiBub24tMnh4IGZpbmFsIHJlc3BvbnNlIGluc3Rl YWQsIHRvIHRlcm1pbmF0ZSB0aGUgZGlhbG9nLCBwZW9wbGUgDQo+ID4+Pj4+Pj4gYXNzdW1lIHRo YXQNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+IElORk8NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gY2Fubm90IGJlIHNlbnQg aW4gdGhpcyBzaXR1YXRpb24gZWl0aGVyLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gTGV0J3MgdHJ5 IHRvIGtlZXAgdGhpcyBpbiBtaW5kIGFuZCBjbGFyaWZ5IHRoaXMgcG9pbnQgd2hlbi9pZiB3ZSAN Cj4gPj4+Pj4+PiBkZWZpbmUgbmV3IFNJUCBtZXRob2RzLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g SW4gYW55IGV2ZW50LCB0aGUgY2xhcmlmaWNhdGlvbiB0byB0aGlzIGlzc3VlIGNhbiBiZSBmb3Vu ZCBpbiBSRkMgDQo+ID4+Pj4+Pj4gMzM5ODoNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICJGcm9tIHRo ZSBjYWxsZWUgdG8gdGhlIGNhbGxlciwgaWYgYSBtZXNzYWdlIGlzIHJlY2VpdmVkIGJ5IGEgDQo+ ID4+Pj4+Pj4gZ2F0ZXdheQ0KPiA+Pj4+Pj4+IGJlZm9yZSB0aGUgY2FsbCBoYXMgYmVlbiBhbnN3 ZXJlZCAoaS5lLiwgQU5NIGlzIHJlY2VpdmVkKSBpdCANCj4gPj4+Pj4+PiBTSE9VTEQgYmUgZW5j YXBzdWxhdGVkIGluIGFuIElORk8sIHByb3ZpZGVkIHRoYXQgdGhpcyB3aWxsIG5vdCBiZSANCj4g Pj4+Pj4+PiB0aGUgZmlyc3QgU0lQIG1lc3NhZ2Ugc2VudCBpbiB0aGUgYmFja3dhcmRzIGRpcmVj dGlvbiAoaW4gd2hpY2ggDQo+ID4+Pj4+Pj4gY2FzZSBpdCBTSE9VTEQgYmUgZW5jYXBzdWxhdGVk IGluIGEgcHJvdmlzaW9uYWwgMXh4IHJlc3BvbnNlKS4iDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g VGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgSVRVLVQgaW50ZXJ3b3JraW5nIHNwZWMgZG9lc24ndCBy ZWZlcmVuY2UNCj4gPj4+Pj4+IFJGQzMzOTguIFRoZSBzcGVjIHJlZmVyZW5jZSB0aGUgSU5GTyBS RkMsIGFuZCB0aGF0IGlzIGFsc28gd2hlcmUgSSANCj4gPj4+Pj4+IHRoaW5rDQo+ID4+Pj4+PiB0 aGUgdXNhZ2UgcnVsZXMgc2hvdWxkIGJlIGRlZmluZWQgKG5vdCBpbiBhbm90aGVyIHNwZWMsIFJG QzMzOTggaW4gDQo+ID4+Pj4+PiB0aGlzDQo+ID4+Pj4+PiBjYXNlLCBzaW1wbHkgdXNpbmcgdGhl IG1ldGhvZCkuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIElORk8gUkZDLCBhcyB5b3Ugc2FpZCwg Y3VycmVudGx5IHNheXMgdGhhdCBJTkZPICJmb2xsb3dzIHRoZSANCj4gPj4+Pj4+IHJ1bGVzDQo+ ID4+Pj4+PiBvZiBCWUUiICh3aGF0ZXZlciB0aGF0IG1lYW5zIGlzIGFub3RoZXIgcXVlc3Rpb24g OiksIGFuZCB0aGUgcnVsZXMgDQo+ID4+Pj4+PiBmb3INCj4gPj4+Pj4+IEJZRSBzcGVjaWZpY2Fs bHkgc2F5cyB0aGF0IGl0IG11c3Qgbm90IGJlIHNlbnQgYmFja3dhcmQgYmVmb3JlIHRoZQ0KPiA+ Pj4+Pj4gSU5WSVRFIGhhcyBmaW5pc2hlZC4gSWYgdGhlIElORk8gUkZDIHdvdWxkIHNheSAiZm9s bG93IHRoZSBydWxlcyBvZg0KPiA+Pj4+Pj4gVVBEQVRFIiB3ZSB3b3VsZCBub3QgaGF2ZSB0aGlz IHByb2JsZW0sIHNpbmNlIHRoZSBVUERBVEUgc3BlYw0KPiA+Pj4+Pj4gc3BlY2lmaWNhbGx5IGFs bG93cyB0aGUgdXNlIG9mIHRoZSBtZXRob2QgYmVmb3JlIHRoZSBJTlZJVEUgaGFzDQo+ID4+Pj4+ PiBmaW5pc2hlZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFua3MhDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gPj4+Pj4+IEVyaWNzc29uIEZpbmxhbmQNCj4gPj4+Pj4N Cj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gVGhpcyBjb21t dW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgDQo+ ID4+PiBhZGRyZXNzZWUocykuIEFueSB1bmF1dGhvcml6ZWQgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1 cmUgb3IgDQo+ID4+PiBkaXN0cmlidXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91IGJlbGlldmUg dGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNlbnQgDQo+ID4+PiB0byB5b3UgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseWluZyB0byB0aGlzIA0KPiA+Pj4gdHJhbnNtaXNz aW9uIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2Ugd2l0aG91dCBkaXNjbG9zaW5nIGl0LiBUaGFuayB5 b3UuDQo+ID4+Pg0KPiA+Pj4gRS1tYWlsIGluY2x1ZGluZyBhdHRhY2htZW50cyBpcyBzdXNjZXB0 aWJsZSB0byBkYXRhIGNvcnJ1cHRpb24sIA0KPiA+Pj4gaW50ZXJydXB0aW9uLCB1bmF1dGhvcml6 ZWQgYW1lbmRtZW50LCB0YW1wZXJpbmcgYW5kIHZpcnVzZXMsIGFuZCB3ZSANCj4gPj4+IG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlLW1haWxzIG9uIHRoZSBiYXNpcyB0aGF0IHdlIGFyZSBub3QgbGlh YmxlIGZvciANCj4gPj4+IGFueSBzdWNoIGNvcnJ1cHRpb24sIGludGVyY2VwdGlvbiwgYW1lbmRt ZW50LCB0YW1wZXJpbmcgb3IgdmlydXNlcyBvciANCj4gPj4+IGFueSBjb25zZXF1ZW5jZXMgdGhl cmVvZi4NCj4gPj4+DQo+ID4+Pg0KPiA+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQo+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRl dmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KPiBVc2Ugc2lwLWltcGxlbWVudG9y c0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KPiBVc2Ugc2lw cGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Yg c2lw _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 05:18:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07196 for ; Mon, 1 Mar 2004 05:18:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkUW-000172-QF for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 05:17:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21AHeJJ004204 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 05:17:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkSP-0000zg-MO; Mon, 01 Mar 2004 05:15:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkR2-0000wf-U2 for sip@optimus.ietf.org; Mon, 01 Mar 2004 05:14:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06981 for ; Mon, 1 Mar 2004 05:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxkQp-0000gw-00 for sip@ietf.org; Mon, 01 Mar 2004 05:13:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxkQ7-0000aF-00 for sip@ietf.org; Mon, 01 Mar 2004 05:13:08 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=beiderbecke.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1AxkPO-0000Pa-00 for sip@ietf.org; Mon, 01 Mar 2004 05:12:22 -0500 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 10:11:49 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8026201C8@baker.datcon.co.uk> From: "Paul D.Smith" To: "'Jonathan Rosenberg'" Cc: "Paul D.Smith" , SIP WG Date: Mon, 1 Mar 2004 10:11:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] Via maddr (again) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Jonathan, I've just been looking at the use of maddr's in Via headers and found a relevent discussion from the SIP mailing list (appended to this e-mail). If I read your final response correctly, you indicate that the maddr parameter in a Via could be a hostname. However reading RFC3261, 18.1.1 says... A client that sends a request to a multicast address MUST add the "maddr" parameter to its Via header field value containing the destination multicast address, and for IPv4, SHOULD add the "ttl" parameter with a value of 1. Usage of IPv6 multicast is not defined in this specification, and will be a subject of future standardization when the need arises. Similarly, section 18.2.2 says... o Otherwise, if the Via header field value contains a "maddr" parameter, the response MUST be forwarded to the address listed there, using the port indicated in "sent-by", or port 5060 if none is present. If the address is a multicast address, the response SHOULD be sent using the TTL indicated in the "ttl" parameter, or with a TTL of 1 if that parameter is not present. Both of these texts refer to the multicast _address_ and not a hostname which resolves to an address. Nor is there any mention of any DNS access such as an A/AAAA record look-up. So two questions. 1. Can a Via maddr really contain a hostname instead of an IP address? 2. If the answer to #1 is "yes", does RFC3261 require additional clarifying text to emphasize this and point out that a DNS look-up is required. If the answer to #1 is "yes" then I feel the answer to #2 should also be "yes" since, unless I've missed something, nothing in 18.2.2 (apart from perhaps the maddr) requires a DNS look-up. It is only when RFC3263 gets involved, on failing to send a response, that DNS is required. Regards, Paul D. Smith Paul D.Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 24 January 2003 22:02 To: Christer Holmberg Cc: brett@broadsoft.com; sip@ietf.org Subject: Re: [Sip] Via maddr The intent of 18.2.2 is indeed NOT to use the SRV processing. In fact, if you look at 18.1, the only way that the maddr gets set is through multicast, and thus the intent is that maddr is really for multicast. THis need not be an IP address, since DNS names can refer to multicast addresses (sip.mcast.net). Originally, the maddr in the URI was the same - meant just for multicast. However, in the absence of a suitable loose routing mechanism, it got continually abused until the common case was for that, and not for multicast at all. Doing that properly required SRV processing. Now, we have thankfully deprecated the usage of maddr for that purpose, but older rfc2543 elements might construct such URIs, and so RFC3263 continues to perform the SRV processing for the maddr in the request URI, when present. Thus the asymetry. -Jonathan R. Christer Holmberg wrote: > Any comments on this? > > Regards, > > Christer Holmberg > Ericsson Finland > > Brett Tate wrote: > > >>>I appologise if this has been discussed >>>before, but at least I didn't find it in >>>my mail box (I admit I didn't check the >>>archieve on the web). >> >>I posted a related question to sip-implementors; >>however I never got a reply. >> >>http://lists.cs.columbia.edu/pipermail/sip-implementors/2002-October/00405 2. >>html >> >> >>>Chapter 18.2.2 in RFC3261 talks about the >>>routing of responses, using the Via maddr, >>>received and sent-by parameters. >>> >>>My question is regarding maddr. When reading >>>the text, I get the picture that only >>>IP addresses are used in maddr. At least the >>>text doesn't mention the SRV RFC, which it does >>>for sent-by, and it says that the default port >>>is 5060. However, the ABNF defines maddr as >>>"host", which can also be a domain name. >> >>maddr can be a domain name. The text appears >>to disable the ability to perform an SRV query >>associated with the Via maddr. However I never >>got an answer concerning if this was intentional. >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 07:37:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14984 for ; Mon, 1 Mar 2004 07:37:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmf2-000660-PB for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 07:36:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21CaeHk023431 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 07:36:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxmeQ-0005ys-Bt; Mon, 01 Mar 2004 07:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axme6-0005un-Uf for sip@optimus.ietf.org; Mon, 01 Mar 2004 07:35:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14931 for ; Mon, 1 Mar 2004 07:35:40 -0500 (EST) From: Paulius.Meskauskas@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axme6-0000n2-00 for sip@ietf.org; Mon, 01 Mar 2004 07:35:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxmdI-0000hG-00 for sip@ietf.org; Mon, 01 Mar 2004 07:34:53 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AxmcW-0000b1-00 for sip@ietf.org; Mon, 01 Mar 2004 07:34:04 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21CXuL23343; Mon, 1 Mar 2004 14:33:56 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 14:33:46 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i21CXkRE022489; Mon, 1 Mar 2004 14:33:46 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QikqBp; Mon, 01 Mar 2004 14:33:44 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21CXh721197; Mon, 1 Mar 2004 14:33:43 +0200 (EET) Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 14:33:22 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-khartabil-sip-auth-analysis-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 14:33:21 +0200 Message-ID: <19E3AC24C8317C45B6F86092F087B2200260C300@esebe007.ntc.nokia.com> Thread-Topic: [Sip] draft-khartabil-sip-auth-analysis-00.txt Thread-Index: AcP+lOw1Osi1qQ47S66nNpoLWgtAVAA8uM4A To: , , Cc: X-OriginalArrivalTime: 01 Mar 2004 12:33:22.0337 (UTC) FILETIME=[626C4110:01C3FF89] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I should be an implementation specific decision to prompt the user for new credentials or not=20 if pre-configured credentials are stale. regards, paulius > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Cullen Jennings > Sent: Saturday, February 28, 2004 10:45 PM > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); slawrence@pingtel.com > Cc: sip@ietf.org > Subject: Re: [Sip] draft-khartabil-sip-auth-analysis-00.txt >=20 >=20 > On 2/19/04 2:28 AM, "hisham.khartabil@nokia.com" > wrote: >=20 > > At this stage, the user should be prompted to enter new=20 > username/password. My > > objection is to the text quoted below from RFC3261: > >=20 > > " A service provider that pre-configures UAs with=20 > credentials for its > > realm should be aware that users will not have the opportunity to > > present their own credentials for this realm when challenged at a > > pre-configured device". > >=20 > > I think the users should have the opportunity. >=20 > Just for arguments sake, let's say I agreed that users should have the > opportunity. I really don't know what needs to change in the=20 > SIP stuff. > Users are welcome to buy UA that give them this opportunity. >=20 > Cullen >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 07:46:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15598 for ; Mon, 1 Mar 2004 07:46:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxmoF-0007RM-GC for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 07:46:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21CkBKo028539 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 07:46:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmo6-0007Os-L5; Mon, 01 Mar 2004 07:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmnk-0007OH-7U for sip@optimus.ietf.org; Mon, 01 Mar 2004 07:45:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15585 for ; Mon, 1 Mar 2004 07:45:37 -0500 (EST) From: didutta@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axmnj-0001y7-00 for sip@ietf.org; Mon, 01 Mar 2004 07:45:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axmms-0001tf-00 for sip@ietf.org; Mon, 01 Mar 2004 07:44:46 -0500 Received: from [61.16.168.131] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1Axmm6-0001jX-00 for sip@ietf.org; Mon, 01 Mar 2004 07:43:59 -0500 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i21CgHD16909 for ; Mon, 1 Mar 2004 18:12:27 +0530 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Mon, 1 Mar 2004 18:13:00 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 03/01/2004 06:13:11 PM, Serialize complete at 03/01/2004 06:13:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0045FFA065256E4A_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] SIP-H.323 Interworking implementation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0045FFA065256E4A_= Content-Type: text/plain; charset="US-ASCII" Hi, Is there any SIP-H.323 IWF available as open source ? - I am particularly interested in a light-weight one which may be hand-coded message-mapping based and NOT based on any full stateful/generic call model based (as usually done in Softswitches). rgds, Dipanjan. --=_alternative 0045FFA065256E4A_= Content-Type: text/html; charset="US-ASCII"
Hi,

Is there any SIP-H.323 IWF available as open source ? - I am particularly interested in a light-weight one
which may be hand-coded message-mapping based and NOT based on any full stateful/generic call model
based (as usually done in Softswitches).

rgds,
Dipanjan. --=_alternative 0045FFA065256E4A_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 20:07:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17977 for ; Mon, 1 Mar 2004 20:07:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyNO-0003Sy-4f for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 20:07:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2217D3Y013260 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 20:07:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyNC-0003Oz-G6; Mon, 01 Mar 2004 20:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyML-0003L0-BX for sip@optimus.ietf.org; Mon, 01 Mar 2004 20:06:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17862 for ; Mon, 1 Mar 2004 20:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyMJ-0003yZ-00 for sip@ietf.org; Mon, 01 Mar 2004 20:06:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyLK-0003qz-00 for sip@ietf.org; Mon, 01 Mar 2004 20:05:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyKP-0003jG-00 for sip@ietf.org; Mon, 01 Mar 2004 20:04:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyKQ-0002va-VZ for sip@ietf.org; Mon, 01 Mar 2004 20:04:10 -0500 Received: (from nobody@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2214Afc011256 for sip@ietf.org; Mon, 1 Mar 2004 20:04:10 -0500 Date: Mon, 1 Mar 2004 20:04:10 -0500 Message-Id: <200403020104.i2214Afc011256@www1.ietf.org> X-Authentication-Warning: www1.ietf.org: nobody set sender to iesg-secretary@ietf.org using -f From: Support Online To: sip@ietf.org Reply-To: iesg-secretary@ietf.org X-Loop: WREQ 2 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] [iesg-secretary #20612] Freedom for everyone (Autoreply) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Your request of the subject Freedom for everyone has been received. If you have further email on this subject, please retain the subject: line (including the tracking number [ietf-action #xxx]) so that when you respond to ietf-action@ietf.org, the email goes in the same tracking ticket. Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 20:13:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18368 for ; Mon, 1 Mar 2004 20:13:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyT7-0004ep-Kq for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 20:13:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221D9Mv017886 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 20:13:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyT0-0004ch-IB; Mon, 01 Mar 2004 20:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyS6-0004V8-Jg for sip@optimus.ietf.org; Mon, 01 Mar 2004 20:12:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18285 for ; Mon, 1 Mar 2004 20:12:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyS4-0004jb-00 for sip@ietf.org; Mon, 01 Mar 2004 20:12:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyR7-0004bq-00 for sip@ietf.org; Mon, 01 Mar 2004 20:11:06 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AxyQA-0004OQ-00 for sip@ietf.org; Mon, 01 Mar 2004 20:10:06 -0500 Received: from softarmor.com (tx-dwillis.dhcp.ietf59.or.kr [218.37.227.108]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i2219vsb000655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2004 19:09:59 -0600 Message-ID: <4043DEBC.3090200@softarmor.com> Date: Mon, 01 Mar 2004 19:09:16 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org CC: mankin@psg.com, rohan@cisco.com Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Draft Minutes Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit
Draft minutes for the SIP meeting at IETF 59 are posted at:

http://www.softarmor.com/sipwg/meets/ietf59/notes/minutes-sip-ietf59.html


Please respond with correction. I'm not sure we have the conclusion recorded correctly on at least one of the GRUU issues.

MHTML Follows.

Draft Minutes, SIP WG,  IETF 59

Reported by Ben Campbell
Edited by Dean Willis

Opening stuff

Changes:

  • no new RFCs, 6 docs post last call, 3 in ed queue
  • Security ad-hoc to discuss discuses on auth-id
  • IETF last call 8 more, wglc on resource priority, almost closed.
To Do: Chairs: Conclude on resource priorty.

Group recognized Henry Sinnreich as the "Godfather of SIP" and applauded.

Status for app interaction:

Moved to SIP. integrated normative lang for GRUU. Need to harmonize with KPML. Nts review after KPML alignment. Call for 4-6 reviewers.

Connection Reuse:

More explanatory text. Please read to make sure it makes sense.

Identity:

Author wants to replace this with generic mech for 3rd party mods and assertions. Proposed to merge with other requirements into a generic mechanism if possible before San Diego. Ad-hoc on Tuesday.

Cullen requests reviews on draft-jennings-sip-sec-flows-01.


Mary Barnes: Request History Mechanism.

Changes

  • Editorial nits
  • Merged sipping wg reqs into solution draft.
  • Removed redirect server from ISSUER-req.
  • Addied explicit privacy requirement for proxy to maintain privacy asssociated withe captured r-uri.
  • Clarified syntax. Removed compact form.
  • Added application consideration summary section. Added more text on what to do if history is not available.

Issue: Privacy:

Proposed adding filed to tag HI entries that are added when privacy is imposed.

Issue Limitation on number of entries?

Options: Pruning mechanism, or just leave to endpoints. Needs more email discussion.
Cocnlusion: No apparent support for limit.

Next Steps:

  • More email feedback on open issues -- Text requested.
  • Update flows.
  • Dependency on the e2m security body manipulation.
  • Discussion on proxy manipulation of bodies--will be discussed in ad hoc.

Question: Any implementers want to comment on limit?

(no response.)

Cullen Jennings: Voicemail URI

Changed to use reason header, rather than separate one.

Issue: Should this be a parameter, or a header?

Conclusion: Support for parameter.

Issue: Should we do history instead?

  • Cullen proposed yes.
  • Lots of semantics discussion.
  • Mixed support for using history info.
  • Suggestion that VM service parameters are different than generic reason header.
Conclusion: Remove reason header, put explicit service invocation parameters.

Question: Anyone plan to implement?

Very few responses. (History being held on whether URI is better.) Need to design something soon.

Question: Can  history and voicemail can be complementary.

Discussion indicates yes -- they are different mechanisms that can sometimes, but not always, be used to solve similar problems.

Question: on whether voicemail URIs should be standard, informational, or abandoned.

Conclusion: No consensus on whether this should be wg item or not. Consensus not to make it an individual effort.

Culleng Jennings: Binary Encoding

Bodies use content transfer encoding. 3261 gives no guidance on what sort of encoding. Proposal to change it so say you SHOULD use binary, but need to be able to receive any.

Question: What about indirect content?

Discussion indicates that indirect content woul be contyrolled by the rules of whatever protocol and data format is being indirected to.

Question: Do we have base64 in SIP specs we need to expunge?

Robert volunteered to help editors change examples to show binary encoding, using scripts he used for the torture test draft.

Question: Why couldn't this be on the list.

No discussion, just muttering.

Conclusion: Only binary, no requirement to receive non-binary. Will go into errata in a prominent way.

Hisham: Policy URI and purpose

Issues: proposal to make purpose uri specific for conference policy, rather than policy in general. conf-policy-uri rather than policy-uri.

Conclusion: accept proposal.

Issue: Should we set up an IANA registry for purpose parameter?


Discussion on whether iana registry is just for conflict avoidance, or whether it is a central point to document things.

Conclusion: No registry.

Hisham: authentication issue skipped for time.

Jon Peterson pointed out RotK one big at the Academy award.


Robert Sparks : Non-invite Transactions

Changes:

Split in 3--analysis, agreed changes, controversial changes.

Open issue: draft says SHOULD cache unreachable destinations. Is this enough?

Failover for next attempt will not happen if not chached. propose making this MUST.

Argument on what should means.

Conclusion: none

Issue: draft says time-to-live of cache should be short. Can we specifiy a concrete duration?

We do have a concrete duration if retry-after is specified. Proposal: keep current text.

Conclusion: none.

Next Steps:

Will do the stuff on the last slide

Cullen Jennings: GRUUS and Instance Identifiers Requirements

Cullen described some use cases and requirements: client generated, stable across reboot, unique, multiple allowed per host, possible to know identifier without taking phone out of box.

Conclusions: No clear conclusions.

Jonathan Rosenberg: GRUU Mechanism and Device ID

Changes:

listed on slide.

Issue: Registration Conflict.

Crash/reboot may cause two contacts with same instance ID.

Options: requests for gruu fork (with a bad fork), registrar should reject registration (telling client to query and delete), registrar should delete old registration.

Proposal: registrar rejects, client then deletes.  New response code a good idea.

Conclusion: No consensus. Need to think about performance impact on registrar.

Issue: should this be a caller prefs param?

Currently it is a calle capability parameter.

Proposed: Keep current, add text advising against using with accept/reject contact. Use GRUU instead.

Conclusion: Accept proposal.

Issue: Format of instance ID

Is it a URN? do we specify computation?

Proposal: Do not specify computation, must be formatted as quoted string, merely require temporal and spatial uniqueness.

Comments: hard to guarantee global uniqueness in quoted strings without specifying computation. URNs may be better. Does privacy apply?

Conclusions: No consensus, need to work on this some more?

Issue: GRID usage outside of GRUU. Should this be a generic URI parameter?

GRID survives proxy translations. Is a form of sub-addressing. Should this be a generic URI parameter?

Proposal: generic URI parameter. Can be applied to other mechanisms. Only makes sense in the context of URIs that represent an instance.

Conclusions: No comments. Does this mean we accept it?

Issue: Document Other uses of GRUU here?

Proposal: No, specific problem.

Conclusion: No comments. assume accepted.

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 20:25:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19521 for ; Mon, 1 Mar 2004 20:25:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyem-0006Fd-6Q for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 20:25:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221PC3q023966 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 20:25:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyec-0006Ca-Pr; Mon, 01 Mar 2004 20:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axydk-00063n-Jb for sip@optimus.ietf.org; Mon, 01 Mar 2004 20:24:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19415 for ; Mon, 1 Mar 2004 20:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axydi-0006sH-00 for sip@ietf.org; Mon, 01 Mar 2004 20:24:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axycj-0006dc-00 for sip@ietf.org; Mon, 01 Mar 2004 20:23:06 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Axyb0-0006AL-00 for sip@ietf.org; Mon, 01 Mar 2004 20:21:18 -0500 Received: from softarmor.com (tx-dwillis.wireless.ietf59.or.kr [218.37.227.108]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i221L8sb000817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2004 19:21:10 -0600 Message-ID: <4043E15B.8040102@softarmor.com> Date: Mon, 01 Mar 2004 19:20:27 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Jonathan Rosenberg , Brian Stucker , sip@ietf.org Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > This just pushes the problem around but does not solve it. When both the > phone boot, how do they know if they registers with the exposure set to east > or west? We need something that makes one phone different from the other > phone and configuration does not really help much because when the phones > first boot they have no configuration. Personally, I solve this by giving each phone a different registration AOR, then use a time-policy routing table on dwillis@dynamicsoft.com to selectively route to the correct phone for the current time of day. Service invocation via forward knowledge at the proxy. Works like magic. It even supports voice mail. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 20:34:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20214 for ; Mon, 1 Mar 2004 20:34:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxynQ-0007QO-KU for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 20:34:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221Y833028517 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 20:34:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxynK-0007OK-5l; Mon, 01 Mar 2004 20:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxymV-0007Ll-C3 for sip@optimus.ietf.org; Mon, 01 Mar 2004 20:33:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20133 for ; Mon, 1 Mar 2004 20:33:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxymT-0000R9-00 for sip@ietf.org; Mon, 01 Mar 2004 20:33:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxylU-0000Ik-00 for sip@ietf.org; Mon, 01 Mar 2004 20:32:08 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AxykR-00003O-00 for sip@ietf.org; Mon, 01 Mar 2004 20:31:03 -0500 Received: from softarmor.com (tx-dwillis.wireless.ietf59.or.kr [218.37.227.108]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i221V0sb000876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2004 19:31:02 -0600 Message-ID: <4043E3AB.60201@softarmor.com> Date: Mon, 01 Mar 2004 19:30:19 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Rosen, Brian'" , "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: Re: [Sip] changes in session timer References: <475FF955A05DD411980D00508B6D5FB00B3EF7B5@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00B3EF7B5@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Is charging considerations within the requirements for session timer. > > There was considerable discussion of this issue a couple of years back, and I thought that the charging use case was eliminated from the requirements at that time. > I'd like to respond with a complete lack of political consdieration here, so I'm sorry if you're offended. Is billing in scope for Session Timer? In my humble opinion: "No, Hell no, and what part of no did you not understand?" I believe that billing off the SIP signaling is a profoundly bad idea. Accurate billing has to be closer to the bearer path. I think perhaps that Brian is suggesting that timeouts at the SIP layer can be used to detect failures that affect the media path, or at least failures for which there is no media path. While technically true, I don't find the mechanism appropriate. Suggestions: 1) The media path is assumed to have real time delivery requirements. Real-time is always going to be more accurate than the non-real-time signaling path. If you need real-time billing, derive it from the real-time media path. 2) If there is no real-time media path, I can't imagine what time-sensitive service is being consumed that requires real-time accuracy in accounting for. If you THINK you need real-time tracking here, then perhaps a media channel that does NOTHING but report connectivity for billing purposes is appropriate. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 20:53:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21840 for ; Mon, 1 Mar 2004 20:53:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz5p-0002xO-7z for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 20:53:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221r9dt011360 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 20:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz5i-0002vP-7P; Mon, 01 Mar 2004 20:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz54-0002tV-Nk for sip@optimus.ietf.org; Mon, 01 Mar 2004 20:52:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21701 for ; Mon, 1 Mar 2004 20:52:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axz52-000344-00 for sip@ietf.org; Mon, 01 Mar 2004 20:52:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axz40-0002sj-00 for sip@ietf.org; Mon, 01 Mar 2004 20:51:16 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1Axz31-0002ag-00 for sip@ietf.org; Mon, 01 Mar 2004 20:50:15 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i221nTr02451; Mon, 1 Mar 2004 19:49:29 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 19:49:29 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304EECEAE@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "'Dean Willis'" , Cullen Jennings Cc: Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] Re: Abstraction: SIP instance identifiers requirements Date: Mon, 1 Mar 2004 19:49:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FFF8.9884020A" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3FFF8.9884020A Content-Type: text/plain; charset="iso-8859-1" Different AORs! Heresy! =) Brian -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, March 01, 2004 7:20 PM To: Cullen Jennings Cc: Jonathan Rosenberg; Stucker, Brian [NGC:B617:EXCH]; sip@ietf.org Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers requirements Cullen Jennings wrote: > This just pushes the problem around but does not solve it. When both the > phone boot, how do they know if they registers with the exposure set to east > or west? We need something that makes one phone different from the other > phone and configuration does not really help much because when the phones > first boot they have no configuration. Personally, I solve this by giving each phone a different registration AOR, then use a time-policy routing table on dwillis@dynamicsoft.com to selectively route to the correct phone for the current time of day. Service invocation via forward knowledge at the proxy. Works like magic. It even supports voice mail. -- Dean ------_=_NextPart_001_01C3FFF8.9884020A Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Re: Abstraction: SIP instance identifiers requirements

Different AORs! Heresy! =)

Brian

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Monday, March 01, 2004 7:20 PM
To: Cullen Jennings
Cc: Jonathan Rosenberg; Stucker, Brian [NGC:B617:EXCH]; sip@ietf.org
Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers
requirements


Cullen Jennings wrote:
> This just pushes the problem around but does not solve it. When both the
> phone boot, how do they know if they registers with the exposure set to east
> or west? We need something that makes one phone different from the other
> phone and configuration does not really help much because when the phones
> first boot they have no configuration.

Personally, I solve this by giving each phone a different registration
AOR, then use a time-policy routing table on dwillis@dynamicsoft.com to
selectively route to the correct phone for the current time of day.

Service invocation via forward knowledge at the proxy. Works like magic.
It even supports voice mail.

--
Dean

------_=_NextPart_001_01C3FFF8.9884020A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 21:08:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22715 for ; Mon, 1 Mar 2004 21:08:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzKP-0004cv-O4 for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 21:08:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2228DFA017720 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 21:08:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzKF-0004Wt-7T; Mon, 01 Mar 2004 21:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzJV-0004Md-2x for sip@optimus.ietf.org; Mon, 01 Mar 2004 21:07:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22645 for ; Mon, 1 Mar 2004 21:07:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzJS-00053k-00 for sip@ietf.org; Mon, 01 Mar 2004 21:07:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzIZ-0004wz-00 for sip@ietf.org; Mon, 01 Mar 2004 21:06:20 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AxzI2-0004nB-00 for sip@ietf.org; Mon, 01 Mar 2004 21:05:46 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i2225AaZ027763; Mon, 1 Mar 2004 21:05:11 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA23814; Mon, 1 Mar 2004 21:05:10 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 21:05:09 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6485@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" , "Drage, Keith (Keith)" Cc: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] changes in session timer Date: Mon, 1 Mar 2004 21:05:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I was not suggesting that timeouts in the SIP layer had anything to do with what may, or may not be going on in the media layer. I was suggesting that if a session (at the SIP layer) went awry, then it would eventually be torn down. The speed at which you can detect the problem, and how long it takes before you do tear it down AFFECTS billing. Keith may be correct; it may be out of scope to discuss how the timeouts affect billing. It's a reality however. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, March 01, 2004 8:30 PM > To: Drage, Keith (Keith) > Cc: 'Rosen, Brian'; 'Jonathan Rosenberg'; 'sip@ietf.org' > Subject: Re: [Sip] changes in session timer > > > Drage, Keith (Keith) wrote: > > > Is charging considerations within the requirements for > session timer. > > > > There was considerable discussion of this issue a couple of > years back, and I thought that the charging use case was > eliminated from the requirements at that time. > > > > I'd like to respond with a complete lack of political consdieration > here, so I'm sorry if you're offended. > > Is billing in scope for Session Timer? In my humble opinion: > "No, Hell > no, and what part of no did you not understand?" > > I believe that billing off the SIP signaling is a profoundly > bad idea. > Accurate billing has to be closer to the bearer path. > > I think perhaps that Brian is suggesting that timeouts at the > SIP layer > can be used to detect failures that affect the media path, or > at least > failures for which there is no media path. While technically true, I > don't find the mechanism appropriate. > > Suggestions: > > 1) The media path is assumed to have real time delivery requirements. > Real-time is always going to be more accurate than the non-real-time > signaling path. If you need real-time billing, derive it from the > real-time media path. > > 2) If there is no real-time media path, I can't imagine what > time-sensitive service is being consumed that requires real-time > accuracy in accounting for. If you THINK you need real-time tracking > here, then perhaps a media channel that does NOTHING but report > connectivity for billing purposes is appropriate. > > -- > Dean > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 1 23:34:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29812 for ; Mon, 1 Mar 2004 23:34:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1be-000746-1z for sip-archive@odin.ietf.org; Mon, 01 Mar 2004 23:34:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i224Y9rM027095 for sip-archive@odin.ietf.org; Mon, 1 Mar 2004 23:34:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1bV-00071j-4F; Mon, 01 Mar 2004 23:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1ak-00070N-Rj for sip@optimus.ietf.org; Mon, 01 Mar 2004 23:33:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29767 for ; Mon, 1 Mar 2004 23:33:12 -0500 (EST) From: wolfgang.beck01@t-online.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1ai-0007LO-00 for sip@ietf.org; Mon, 01 Mar 2004 23:33:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1Zt-0007Fo-00 for sip@ietf.org; Mon, 01 Mar 2004 23:32:22 -0500 Received: from mailout05.sul.t-online.com ([194.25.134.82]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1ZF-00079Q-00 for sip@ietf.org; Mon, 01 Mar 2004 23:31:41 -0500 Received: from fwd01.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1Ay1ZB-00036Q-00; Tue, 02 Mar 2004 05:31:37 +0100 Received: from localhost (Tl03iBZbZeKmtdxOeDYZ5riHvtaYI5s++7wty97tr7sndUoo0T0wQb@[172.18.19.46]) by cmpmail01.bbul.t-online.de with esmtp id 1Ay1Yz-1NC8Se0; Tue, 2 Mar 2004 05:31:25 +0100 MIME-Version: 1.0 Date: Tue, 2 Mar 2004 05:31:25 +0100 To: sip@ietf.org X-UMS: email X-Mailer: TOI Kommunikationscenter V3-0-4 Subject: Re: Re: [Sip] changes in session timer Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <1Ay1Yz-1NC8Se0@cmpmail01.bbul.t-online.de> X-Seen: false X-ID: Tl03iBZbZeKmtdxOeDYZ5riHvtaYI5s++7wty97tr7sndUoo0T0wQb@t-dialin.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [session timer and billing] I agree with Dean that accurate billing is better done one the media level. However, in some cases you want to pay for a service that is provided by someone you don't have a business relationship with. Let's say, your Korean translation services charges you for 3 hours of service while you did only use it for 10 minutes. With session timer, the proxy might function as a trusted third party that logs the re-INVITEs. It's a rudimentary non-repudiation service. It does not prevent the translation service from charging you accurately by the second. It might help to settle disputes. A trusted third party in the media path is much uglier than session timer. Wolfgang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 2 11:33:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18004 for ; Tue, 2 Mar 2004 11:33:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCos-0003TB-NJ for sip-archive@odin.ietf.org; Tue, 02 Mar 2004 11:32:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22GWYpn013336 for sip-archive@odin.ietf.org; Tue, 2 Mar 2004 11:32:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCoM-0003RW-9Q; Tue, 02 Mar 2004 11:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCo5-0003IU-2W for sip@optimus.ietf.org; Tue, 02 Mar 2004 11:31:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17934 for ; Tue, 2 Mar 2004 11:31:42 -0500 (EST) From: dromasca@avaya.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyCo4-0006xi-00 for sip@ietf.org; Tue, 02 Mar 2004 11:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyCn8-0006oN-00 for sip@ietf.org; Tue, 02 Mar 2004 11:30:47 -0500 Received: from mu-102074.dhcp.missouri.edu ([128.206.102.74] helo=ibm-8t82z8o5t0e) by ietf-mx with smtp (Exim 4.12) id 1AyCmL-0006g3-00 for sip@ietf.org; Tue, 02 Mar 2004 11:29:57 -0500 Date: Tue, 02 Mar 2004 10:29:58 -0600 To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------euernfktutmedkydslap" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Hey, dude, it's me ^_^ :P Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , ----------euernfktutmedkydslap Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) archive password: 15376 ----------euernfktutmedkydslap Content-Type: application/octet-stream; name="TextDocument.zip" Content-Disposition: attachment; filename="TextDocument.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAAAIBMYjD4jH2aWFEAAExRAAANAAAAb25yc2NwdHdkLnNjcuttG8a1UGBiMrfS 3M0x2IT/XdtDKVSIwZGj1x+TjaIXYS18XzdrSLQDxzY82p0rkkBiXjB5G+J3TGtOTxU2NyQI gmqx07r2TI0PByjYuOWld24/UCX9OLzxwVRfY4DKjKJjDhBCi4UHXr6GqSlwfq+xHJbGm3q1 hG4HuBS1/tqVJGWyQ+1ev/pxtG1imYYy3OPqT2dP7U5PzQvGXld86pmzIaqwz6LsE5l/ZEk+ 9r2uKP4HwHFlyU5/oGb6v4Q0MgJJ7yCZze+6KCO/+ICiVoS1qWskHNfwPWW5KXWj/gWIlp+G uXncJ51hpC9bMEqyobbQNhmw2J5NppzQE5E1mOHD86R8cu7H4q43EQLWr7+tHKpFmOszZAUF F60d+VqxJlZBjlkejqcBybBI1OvksTYWvGKyekgLxsa1+IGalBnX1M8m9UNuymI8Eb0pFH8v 9YN2ftvy8t8AzAO0z/SRDvMXwtcwegr3bseL9He6yCXmbuDiw7NgsYFixAuYNTju18WYvInP foaChK8QgMCg3ckvRqvy560kzSHYoNwBYmu6b/oVFfBLdBbM/Gh5yq4pAMgHwVPL9xN6y2x7 EwjtUB1hvBjRxhyTMmLfhi61she16ruDpX0CNbQ7Ek8kG4MfKiV5jwycIThGls39AnsrYlzH gTYLHct6VDWk7ulNWWM8Rd7tzQ6gFutfsLVX19Pro9xvZQdq5AXQFNrznQin06TI2jdH2P1D nPL4Il1jpi8dr4D5W/SQPWhvlnZjd56QYbIs3MFHOi6VeU+sAvdj84UjfNKJViIyrhky1V4+ jjG9TS/qpMMBrAxl+woDW1OixMx/jsJwdTd/4FxIy+D0nLV/0SkMDfBb9N/6BEZ09QnwzMfi QOdTbv3bOqNH4+a0pC2Puwb840CjQZzLMFmTJdesYrX9y3gEsv9H6U7euRe7iZAk6XaYg/nv /vWVg11EYOZYrzTQMtFqbM/7uxIVIxtAnTFG90OuFMYreq8QbIRHQgcTr0OjBM5QOL6c1HcH IkdESYMen/SPiHT+x93HeRTvzdNVBnsumMi7JX5592yFcrVlV4ial3gvalY3dWGKjh9He6dn qazxNpUVaDxln5yFv0xrGdCuwX3dZ8fZ4vrBIlkDK7UNYb4v+NbCUG1UOTTBO37G0QAcmcgR uPtpl8oJUXD56krBAlmqcj0OjR7+xaxbv29gcgUfF1VHdPqglQqsH6ffwntr0bqU0r0VrTUI 3DK+cMg5E6Ih9BXMExDTOgUWUIPqTNvYPaxk5FP0xcGCo5q0pD4YhMOXal5K22FYwI1wNlj+ kqWj0JRQ0ZG0NNPW4AlUkAsdUC3x7BgQwx3RU7CZbGfY8+fOfhWaVPvHOl6PlX1suWt2+9e8 Qpd1rm0ipX/UTGa0NQK0AvzKz4thCBjS1Sj4Ue5iAuBKKdQssrlUlyOSwPbOgMg46xk5Xvln +xchy3W6uawjwV2flm9kgyWiFvWrkCJsnkLMVLxKilXnGrvtEbls40RMbkFhKkX4MCarVGV7 shUC0QPgWps2u4JdWiNADgAkiI81aEZDP6tylEitrqvwYgymI+1bNIQhLCEPFyTwk8gVvPFD jK+cNifE8TtD9eTJ9j+DYIK6DZPNLGVet3PHgeuzwQybpZePxTr8O4d7G1pxnWGh9PYYvhz8 BUHLrdW3r5ohoxeWVslZE5FCm2pYgdlXcm2r4agbksEx8GE3/UMA4uCjUwq3EXBwX1QCzDK2 IL6CEsZhLphnmcKhARtB5vp52XiLjRqYonyeR6MPkv+OaA3YICw76Y0Nkjo0qaPUStO9Hnga UKoU4HxkB+U65K/cmNSzecbjyOHhH5wGH356zYwY1kE75kQaM0Ukyp9Ic0F50uOnPIrLN1AR 9SeIiylrnBtYaP/L6S+zUG9zv6RKCEic7vF4BgJgceHqWLcRF4JWr7DGw+HniTRGBqzNFLj/ xAz2xJC5VjFdaUYgWOUUlLylDvGVfQLkLevUEbM21tBi7XfVA0LUV/2Orl2RHebahqGF1qK7 4+HEnShnpBLrbHv9LK3j1pQHFoA9F+E0BpkQI/Imc2xT6O2EoPRvzB3134ycrhYQhHeRyPYK s3ZTs6NHLSJAjSr6WNPLyocSGxbSbyw5oF0QK51foWF5VXfdGir/ruHBZ802HSBxrqi+CbIe ZU/9BXj+PWQ97dBd5z9vDUA6mR2XRDi9i4Mu2S5co73L2W5wU7ENcKub8Y/LvDZiOczV6umA Ze0EiovDZwBcDjjz+X4yXIY8OBKhpom4fNimvKEllDL+PQt3OrOoTACyATS3JjjjEaCcOHJi ojJvzi8bGGWsLYAF1hTMUkxHkHpJeLY+sGBuGFH2WFP2huFpq7URN1H1gQBemOk5pnyLiHv1 0m56antrCIAECBNk+JScLR58LSO3VRsinWCuWlXy3KmXCFxooH2In8EuFNBKgmcP2oUrfltf pueg5E83Vt+HCqqgLphBg7QdFNY/j5L6EDqclvOUFlIa8yyUO25Mit0IL2ELdDgrSSIplSKz gU/pvuuiZCgAZhnsBNvcbrxeTFfRvXsftV9gBz8uxwo28DZQZ7pRv+XcOSFTEli7q+HdQInm wwQEceoOPbUxUGU1btdqu1cl0BW5yDQiOJmMZ7zfufB1LT3ckWJoarks3tvKcHplW3qrEKy9 jF9Oquc39l5htGCh0ipN+eVoPA6fgLg3681hoPD8+LDWtC4rtf4ticwHhvadVKCOc6UzZ5OT tTe6zjNtLVN2iOA7QfDCdo7uP3QsGaXEjcSqOkF1FUxKvM3ixSLvRVzCkg5n16kSxpJ5Hpw8 L9klaINRXMoKHhxlLaG81L1Q+4oVCCphb/xmbl1HxUQC7RH64ewfB+F7h4VEPAShFiOpiANW lScei++wDx+W1+5pHtTtmu3upY/1oLMSFt/jmA+3F8WzuNF/oKe/9ddhlloSc26l0syr+MBJ bjSZMirURn8M5Q8WU+ioYc9S88Bo2zWjhiF60EQ/xRtkAozceEkZRcy2h+t9VldXiEXOyQiT DGr8xb/MGjpxt6WsNWXL8VR2UlpPSDeWJrFVNoFqDr77UVxGjBCrgF5+m0Htn4EiIOAZ4sb6 VuWgBd4ou1VcM5BiB0E2QVxGXA4bm5ZfjcufpjM6Te3yd7WD/YPtBOyTHyensqkJNINDaz65 jyZ4fzBKmbeKv2DCjE8aFkKF1xMmCtI0xbAs0HyvA5+kKIsXuKdMPGYhtm6wO46pN7WDKECo bj6iViarhx1GLrP1W4FOJkUvaqPi25yD1JkN2M26j7AjuDHrHeghV2G7h77AD7XhXRHJUU0h l6OX/09NKuAORVxgCdnwRM12kvuXA5gqJD/rsKUcfprtDrfq6lOyOSWVDOP8oWQLzw0LfiUf cHz4AsgnzOX8bf2sSminAda05sx5RfFTl5kyQkmQjGKsBxYoOZrAIKwAA3VxVoE0ysgP8drg f1DASO7cOm5SCVaEpekvjXRzisG28RR6xhCWLPuoX0qmRoTmAvmjU/CxD69kpwMprU/XnnFP +wdE2L0gj5n9iJMujsMxMJ1wfMBWuP7tBDxFk8fLVEm58iZywKrjjpZqy3eHNGsXlScAyy7B USJoa+bjBD61uzRcRHA+Wxj/BmliVnZM/FMiK1afmAY0A3yqCUUQXY11PUn9SIDe9Apyf820 D1Z9Gq6BgfwRt2Ij7eAIuq9PRS/5/HrnMw5l21GDwPf7Lww+TRJQ3z8OpLVD4OSFIu3AKzhl bP1r7pAW109nfwiAJgFJM2xa1gCo7VxpNx7mPWn6+WXsiXOaOzlvB/7YTxqciO/b6sm+sstD RweYYl9bri/mUXRRCLPH9HCbzOwJsZIBaRymn9F+bzOIFkpolJUPeq3rhOvbYqdJIoL4dnUY oPdxiI6tVMroniHk+g7Lh5T2ySdyoznLxF9J7fH/yg6IbAbN8EP90y3FC53cziczyG10n0Sk n8zNHq+iPTzcfhlcjqvdLxJJ7WZWQBLPmOlTWT9tU8TajIX7/8zRTPyaiWOYYTV0rrSK57M/ 4e4AznirVOKGWv785h0bR15kMpZsc2xPXCKLwEnyM8MDZmV0B5cGUWMIHL+oTV22FF3SR152 6OLxNBRtTNeQL2V8hQV8bznsI2V3FudC0e1FiIF+CP+4pljhT6J4itbNBV8TemG2EhlSnxmE wnH5WNI6zzmNnapON3CHMt1yVzfYtEVDNCkr5NNJ1sVFvE9a9pQjrAOeyQMOucwVIePnoW0W vUF+Wo1dZCXhhpqiAQDQPqbPeYlHNfQI9JmMkwJb/J8NQbOyGyfWpDheA0/x1jWMkTrg/njM ELY1itq3He0Lp+kjtnCzqDT5mAiFn7ejANMJkCvrIpH9WP/rvIl0bwGzDnmeaYX/DM7rkoMS 3H1Zb0YnDlVmobF6+H3c9GGK4duwbRcSViYeU0YlOTXYZ8pOkIOdmf5lmI5rIV6Y5SvrQ/xU Hk2rVmhKXGVGFAsGZ/lJRfbiMpUZYCADxqDW9c4KF1MVdMRjFGjvW3ueZs6Ap4iaP5ngt3LG ZRXB4hwITJzb3ihCy4VL3tBQhBhFUI0m/AwPorUR86Lkm9bks7ab33gcZJj1OvXYiW+706Y1 civ00nXGz0zKYsYtFcofNrpwPQd/XKqBVx5kHzZuzwXNmxBmxDu6CFGMJJt8UlrpPzSblq1+ Vnw+uQeWrjYPCfQ9XiHLikT0aGmaxrrkVqN+sRMfRaKKfPbDmrqpOYXVrbaFXOIx9eeXMJD1 o3xcEtImgw2YIwwTY0vQlxaNwpw4TkNsemc94x/OH8GilBr+07pM7wz8gYL1ma3PTgTcQZ74 iOYlE+ZypQbb9Lf3gChPg0aXE74vldHbtb4qRr3nlGwag61ABU8T1waJjpj/66HFPAxZIPJW fl7PHsPAFo4guhIRBtKMcceEFxmTSAOCGfB3JD9qD86tDFdB0NaYLwor3VkcO3ub3teCdtaI blADdqx5OFb4Vc7ZEf69vlNNxpYH6Ry7/Lk4Wr2YFRTbjtjvvSvvYQrtcYxYykPPERhmVavC VF+Tt0RnNv/QHT7Rhq6jns7SszuqtrF56pPPOj4BoKE7wZHvbIr0NpBZ7iKXNf37S2wA1D2Z MRCQQwoajW48JRpU7xllVBbpafn6svkDlJ+4r7QbFbYiYkjpK1qTFbvXVbhbh1mvF/ge7UUb q9QSfBpqYZDi/1NLet0cpc8owyyuW9AA0SNqr+akq61lK7dMOjQ3l9s8RC5w6B8S4irdAGFs OrVmpXOdluAesW+pvMgTTIoMUJDSaHCE5VmHd+AQbTbFXGO2ImtxvZc0zcaQUCfTg9odOxJ9 dypvN/6bKBVxYwfYTyM5aX/JuzjxpgOV3Nu+sXWy3tmzbOAHPrHvuTA51DR5GkJ+r+W6uOQa 8uVsQuQyh169SSnmT41QiuiKvY2bQjcN4TU6d4aZ0atNNccwwarB0VhcO7a/aIKBzyrrR1Er kDVM11RRFLxauJYjHFGj5m7he65UTj5De66DivDO47gL7aDkS5f4EVje4zbOy2zUKw4Gyr6H ktEXWe9aWntAqWF6s1kmAt/UFGTeo2cMVh3FXeyCSP6ywejHWVLJtNbCaFiVH8EcvUxzTM6D UAbXVQlDOcyfxRoyGKvT54fw57ZGRufES4uuV4q5rn8wjy+/OZY9WOm+n+iekH1t2B+UGk9W X8Z0M4TXs3DjalqEfShNXNSUJDSDXwv3CLXOFsH0Qetb0e3aa1dt8tE5ErCEVCgJlIev3qvW aO5TOVcG8MYf0avFAUUWMdmiYLAyhkUpIUEXsmjy1kV97bJbP1BqC/nZg+YVE/sqwxEA0Blp tJLuqIjPIVXm4RsTWO0ttvBiVu8VusIm1MiI2IGTo6bRMZq5wjTaIRgO78uRSbAl4DL5rSQT 6wS8/7Slxk6/M2aAqm59Imhcvn18tdzHviVGuhRLFHphQoCQzdG/UWTbp9s+l+Hzw5pLKXSD eJkpG40f28V9PHYcTXfCaEXN12EB7js1F5zUhS6s+Hh8+PWHioyc3d7D3kydbP9XXgxtS3kU Jd2lahXVcboVqQYlu/UaRcSlnblsXtk0JcLrWo9DHWqmLED0sbHAp8N5Y4cXHUXlzTr3KMlQ ndViRU+lzZBAbJRb5Cf1gGC24A5LpUmVVPVFT2QcxHCSj9JThJe7/r31bBE+eo9gjpmq/Nd1 jB40imRaAJsu/QdHlVUJ+t4wfQV0T2obbqnwWFNJjsJZjrroAbm/1GRXOTkFB/OJFbqMMIwD 0UXRiN6oWqat1KTmNICtihZ2GelKwJUjbXBVWVqcBApCNn8wqXNhTL1rujqiDqZxSM4s7Mty tTzXJu5mYG+Lw5f0T5Et7/1pnLz3nUuF2Nnr8yASan/WCl2uCzbAfVdnW9HA/TGEjYChXu/d 8z8QUY2+NSMKkUOdgAQ+KzCyhPIGLxdscutH0COucJ4ffQbMuLWyitZSOAbG6K/uIGIHiS9k +BFKZZxSxUt+XA/+8VFBQy4EpwNvb4yhnR4iMiIFPk15WKiWf3RDZQnRCnHcJjF/CVN6ZTaX J7ewtYa7SF1RxF1lhDibOxSZgoAYTHw3Mea5jMdYyNdzWtd9dA3VyrmTuw+ylVdQaN7EMsn9 Ry93aXBz9NVbXlHi0oVO8pn2EsHvMS7zGdcJCT+hXEcz3vCIPm/z+Jlydajae4cs5z9P2I4r YsSiGMLBNZnH3uVxt2ANSLQk0epjn6h7ohlERuQG/1ahVmKltXBb7KMTXxq8P4PI/3WtdsWD VyvT7LpUDYrza8vmUWltxGedKi6T2GGJBgK/xbQByTI8cHp0Na/tNJblCX9HlefMTkr/vcPH NisbEU3XnJW2Tp6e1Xblamp7NgLUvlAjdPvDRkLNRmr85Q4g+Bv7VbQu56ANTLLHWF5n6YcH 9XX51uDIK3oDhl9/aslDFvfvKPaIlCUlZkO/0qt4jy3/dAqkHFVR4B+91aEbaEGjAsezP3CT voUsiBmsXI4pV1ySeuAeEgVpFkin8iqydk9a+DoCyaU0ijV97uWtbFp3Gebey7ZypUoiPa1+ +K3N+P1EXBL6FkFqs6zsjYKV89ZiBE7+HZSwDhbN/S7L8jSdjznezSCZblYg1Pu0FchJ849e 7vlJ9rlrLd+OnVZzSG6HvBqqcOIC+oVdJySI8xeJTTGttsqg2qzf5owEyR546qIjt3iHRmQt UXDf24LAl/KFVsvMbNqgI4RWim08AOxrcFoYd72qIZVp0M+q4JnmK2B8cs012kij22FnUoql rgHbsgx/xpMtRIvUOLMgun5eRea0pH3iLQ3fIc7HG3fxSBRACnKxqxTQi823i7UdFYxa/mJJ HCmqXUyog+7fAHXCWdQfRxzZRLA5XDi82H4zaKCl5NR6XIQ+UpU0RxtMHTiK+gBsLQ9eigkD qdQQhc84sZDD/Cpbzye4kZ04SrPJbGqRmhrIRHBCKFIApmY9si3IGLJIRuQgvIvP70mn8N17 gphkDLWXXbizhVnr+V9a6hmVBSQV3bOU3gvnrrSoazjaTJFSyRFIbhSGjAtJZs/ySea2I1/O gErd/q6v/xmWWX6qU+isnNFO5EzfCrtv1TTXsSh7indE4hLt9fm8tG36ZCCgya4mb82E8d5d HOMcRNyuOUaAGPrfOE1BJEMRf6ub+Yy5l6biBwFQ7vtoRWPWAUJkSPNZ1DOsG0vvweJUHcJr k0WzYygFMFwh24T8wQZNfXouTCxELLELywtONIrXSVMWU9DOe1pVhAE+x/RoqoPzRZ6hXCRm 6AycynLOIav5Tdnufm4/1JkJW3gR7wZMi7ZskbRsTX/40cYWp49WQUYHvQ3iRokmrepR6D+R 2tp+CCvWBWMfnf0A6TE8FH/FqKfUWJoWExdbMy5OVHpDP4mM7BFnNy/qs00K5YmsxZ/F2VEd 4aZgG9XIpa1ZGtVZq2Z7MF7PqGnV+EPGdIAXn1vKQqtZX40POUmgG2aC5heCCDZzYtDoP86P 8K8bd9+yhpMNI/P7V3bxAXMBfn3HWtKrAVYWXb1Q99xw+rRimz3wvLh93zVzwK/frlrR+Dkt 3hnpF9Dyi37XwpjST/SB9ByMpxxMW0HHh31uz+1mjYg8Kdy8mDmbFQYjX0u8TkeG926gXkpA xvDBD8YANApZwpcCXFLxx/UnJJoGRUUTJ5NhCLNC335DLu3GslwAMRZQWFzvTCG7u01TxWPY ANKNtBM/3rEvWTw+4iUbnNhCywEzF8omXVSBVP1RyLQ2NumTgW96iFIApd7OpATLuicG8vwT g3xNqf00qfJawODMAH/jT+AItTA0gM/IBWi0Hsve2MxgPEX6DhxEvZpAkL3q42HlHzNOKqWi HbiYLqvuw1Q+Yymj09ANMxieJsr+qrysuoRm0MRvt87hyrPZFu6phgxhPNAL5ezR4kI1qVpj C2t49j9dW/kDJ9vTJv4x2ADc/9qRgSsSPJqYs0AAlqOLZqSbeHakka91T2fNVim6FqU48sUl LiJc3lR1g7myzWH71Uafdg18Sl4mmpN109XUFXHbb0sE5UKQQOIHeHdetCYkFwxkd7wpnlJO WkB7d/9e/FsagIxtTf6SWhiT+KtwCiQ955mo0WZXnoj1GuHz3bg8mAXWN+Xy/6UOcB36ctF7 VImleTpfLQPS2OQNpaY2ETS156tUL6Hxd1v15KVZ3gVIKBWIFEJ4UQThd/kUREIz8cNo5dVa qtKS2/Zb5RDsYugTfNOROAxnQwat7fSmkZCEKQpeGLnv2OhP35EhsnuulZFy7Wx0+hEqskcs hLX9BSNAK6JX9Ov9xm8F6C6n33LTu9YEMXCkJuRMtjNiUsvJNvCLCL6MJxJHCLSiWngub30y BFDMyItySAkokI1zYGr8T3jwBNk/rln3gAVS4ntyve9SiOgpxlSoTyDpXoKlsxjM3mdqNKca /Xie9swryVV3oaQh1H7Shp2tTpNcOldcK91+xJy+nyqpfJn5RW01qRaWNJdgfZKGWpWDTzln RjbwS8RGtk7wSEeo54d+8sH2zxOmzOxk87sNthaPjOJhzeV26NTOgkg7F8mnQ4PHR2hNTdZe Eif5Fw1C5jB/hk9wx3cb2gZuLkFmTzOQRp6tV9PeQhiAXNApCdbAWt7erXTj0gkJG6mkVmqT j2/mDMqwqT1l4mXULehhNZgb0RChjyf++NKGj9TR6DILYxD882eKKEBeEvwiXqaMgeuX+V9V gD22lpD4twp1IYW6fvH5aJ5NHXLW7ueYL/vXe3+yMj4hRsTkM8viM5VJ+dhm0cN27hgSPnNf XC001TjaaiBgLRn/bfeVVNfyHzNm0Aav+GjicpWnKqJFSoPFic0hi4Gkiwz+wNCewCCGWwF0 /Yzv1cfg7Dk3hfwecRU4xA15QSD0zFT/+IzdoLWdG5/xR3dKVy+7wxNm7qTNwVS+/JaPs7fb OGmdDuFPyD0Ao6offnyTndEynydRRBFjcbj4m4YeZ1Ea8J4inTzNpz6FdtNIlRg24eCWuM1y c/VXZtB7q6ruPoE08z9HwvXgfAecc3HjD1KkBdVgQJdBu1LApdZoCN4OKRoOEf3g716pKben RxHqQcJ1lCyxqTmINwdSp0YLw2Ardx3nZW9yNzsojt0S2dJjja16zekYwiQdZ1tUN6FTnOnW OCcF8CnG754CrnV3EyqAws1+9BUvDFfHJpKO2t+ZPPQAjNUGedlRUfSFU4WVz+rseHXzCB2V /i0b4gUYtGOflWERSU2klfBjZbU3o8EJSfZRYw6kBboDceBok+kCl1QBSWPALuhiaXaq56wv JGgQLLEokrkb4kRUlYeqMUFPxex846rxsvYcguaFxbiGEzAFDR0ZKYhZAD+1pqTYr2czVI9S Hig/dZzm7pILaY2V1jFWq69PLxL5mPJk9mTiOFsn0vN4aqpNKBzXVkohOnYk68+5AEULK970 8xg2FzEpqRHQHgemEF8Dpzfq3OvP8Tw6AiLtoV/6YzWJqv8ZPoA7hyWeEScSSnxGL5I+upC9 qNeuHJxoLhcEtsoYGVc3YsgS9PBZDvm96IAc4vd8KN3frDBOJ67OXJxEiRwjTp4avDkmIokO omgeCwMS2HS1AZHkn1FPsp2XMmqIizALYxfiksHEORzGF9sIUH3mAm04iJ+fHhPJMh5Rjs/j RvhQOQ9cCEE5BpvFzqSkHlfKY0C35tl5Hl/K73JgVfCXEV+3DeZ7l76LGH8GNr1niG1xStru moJmxmYBVX4NpA656kIsmMns/G0FRr1BaRJO2JY1f+6/0iMSm8Zp2RUB/fs3rPfO5LolTjhJ UTb6WP1HXJ4nB7LbbmJXUOSIRDY4+rnOUri7WDbn2pBwOR+qDEU+XT5OEM1/MjDiYaxgDxVU E3Rliwr+k0iNPJjmx6U9nCDTtjzSnzDU01NGWwiJFak61MgSAhgbVLHRsw6mWDT/YL+HM6wd DR2tSm7TPUhfMJuvmFhSx0gTsKjzi0AZxBOHdROtufobM5GJqGlVdKLyE3dtweZvC8nk6fXB fKeiS3rNgFP0e6zvl33MSBFYE8UX0ymwPMOn47lZAADG1Vha8DNMTs823++0qGcHrC5Jno7R hnWv8LmwOkS3pxl2N1JyNlslNCdRPeK0M3bBx6eNzSRzjWaEWo4wU6Pcmljl8SggeFOb5GDD YAbD+rACYiqXe5BMou979WLVYhdENKnl31Vl/bNt3tZcLQg3hcxeviOkbffIy6pNYdyMycYu 2ZeAYtSePgDG4jWLwEz+qjwaIOEp2HCH1pUf8cRysQ026yExnp3D8Piir6MvsIFFrzSsalgP V8vZih23UeD8QFhE3Bv1f+g3yNvWClu5AkSx0on2rNDVEafdTiTPD71nbB9XRw5QDwKPJVCa C0f/7lO68xZTfsZEBBpZ3q1Avub8iEdEi3TFG5ezTJs0paHSi9CyC4o9AuypEgUpjf+oYh4A EEmwlcTLowEhtm0jngRqXUQ44+ezR6bjMzqtFkNvrMwzjH+WIP+9z7+Kmy2QhgnwnJ8/KIfm deXuUreTWftKNEkj+wI83/vwP7YtUx6jQcICUqTGybnxO5E3R5I3teYJTUkzvvwGGt73BuvE 94K1U2+VrBiPoc42Asp0+/9PTLRYwOSg6ikWG62b4DLNLHMnRPC5V6ZO8fMh1hfXLw24xF/O W/Un5enF0diKLjJKl3oMnqJ0g+Pl+PyH6pUIud5DImicRXG0u9VMQcUdNaMOouMldxnPH30t J0j3TzTije3Fd36BQqew+fUlZotePMBBZfh+qbPGtJ7u1xq9kJkybZ+R69MljzSSXjzPONj3 YMjIFWVumtmOwGaSqnlua96cX5VR//MkU1+iK9BJZJRqu7DjoRlEz94LH3zTKCBjtVNDieiv dO9kOuk7yt068qvRu/4MEF0VMfE3USQMqYCNDsGq5kQbjl89nGD3WdKBy4opYiMQeMXMntXo GgjGQtZ4wDnPBQLcVUE558PqMm7NnSOG7McfEko2v6sRKA8p/WB3BWz5kbGypdNgMlEQ8oW7 7SWlGB8lXaF29QmHRF1NFOymbzVephKYk84cLLNSZG0AtmYSlFPpU4ZHuYchby+SoEE9xdPp 4hdyoJLfHkyIEi1Y4SY+vdVoo7+IHFPnRv5T+wP2ocyaqWPgaeLDLtkiqlZGDcP3xXdd4My0 W/Tf+78vO5fhCCLX/+dADxhrjl2gdSeiRI/IdGvYevKU9YrwJ9K9XpzcH2bwzDtv15ggBpNX lc6sYNelgJuLYU58CC31M7JXIblgivz2Ob1r69m9aMcXC91DIpGTbTJ5lrjIm5oe/NcLtUta nWMW0d1xTd9ybemCVHn1P4uJLwZJI0LyCso0hrMf6wrbsQ56K7CQfa/8ToRoYgJj1gXcRwKw AFw/NsJjRBurgz85cYsZjM0WSd3gDyplODfplS1Vammp984ItyVmqc/OGnS+P44NVvpOpeWy TOkewmCDW/d99qPGIOLNH0kaKLgWHaN2QmuBPtbTfMxdSCQj0TF7Kl1b7TwE+/+ch+VfWSSZ EynnemTU+PmvN38Bim4QZJHHviB2xz8f/Q5bRu2DR+JqEdVTOD2N0hii//mCepd8Xt9WCp67 dnzvwgdGEGKA3rrPUvar0zxABMny+EeBAc33vjFfY4mvE1wxe5Q6IHWUM5vcFs14vHZsW9T6 KEsCYuYOaecxwInHZrwSyVBsT+jnvVzRifCk0EgT2l9+acCCd0YcA/pvCJMCYAn6KBk6cgMe BJFkcCZy7rVlhsQsNNhIVTYG+eDcO/oXMkapDfKMQPpwFH+PaQG1khLyYRgCC+4Ot0bvIgBf 1TVcvwerkCe5AzWKb2PnS5x/j/6AmSYI86Wj1NRMbL9pRc6gG6sBKpyBLRzVPin7WThlewfa g08lHBfv77Fc/AbaZ7T5FL3DB1+cEaq+VgpSJ14eD0uzd1gTXgAu+ma7yBN3DlpgV1IK1TBI d48mDY6kFiBiF05LUGC3G1pjH9r1soH7Vamba2zm6aD//QT8bVV4d07+TR8BNgUVmPzOIaCg dVE3RyfNWnZQ5nvaAwynZiEjt7QBSKk23Yy8uDT3hJm6oS5g6qqzX2VvaOTNdny9JlE8x+d9 IuTClajmdWSQTc0jw/E4XzO+v6PMRdqv9hvBF8lS+x2kQSiKtlnCKN2ImssMh0kSky0opmQz Ms4Y2AaNCI8RxCS5Des5c6bDoYogsrqXHKe7usAawmy1OPZx3P0gGcdGZPk40Nl4FFy9IQlB cEr/XMqOek9omQMDIe2HOa0B3vU4ItQPgt+eONbJ8ji3NqaIwY0j6rQ1qtCIyuwcYj1TUj3h 0noZxYYdQsPsVEISclH3HcGY+7sgHO+OJYv3H2y6odR57F+Ec83H6KsKHPUXE0cXdMGcRcsJ Hv0EUbLuoznCOcDkjO2TmS1mra7jHOYi9pCfB0JPPXPvseLjXyYNWcWsb4CH5Q7k/lRxZEE1 lU2VzdHTv9L7YECtmCuc8bdetCENyu5RaFrUwOQWpbuS9tgbM8RDe9jPbMzq6cGRmZik/iYl O+myg7w1RECPry/RBOR5yReItPJRv90mVURj8Beyywuaf0b2NdVPaDFg+loj+5JmntBk5D5s HdDJL3eq9bQ6Muk68l4SDBO/L/jWp6NO6I1Yv/CpKKb0x+XEpadfFsFHivc56vPB0k4hA0HI 9JcLGnXNYizoDSS98s44GXZ/CUr3rOoNSTKOuP26beuUPJi7bmO3Q/MUj1j0BUFwUGFTm3nA d9avbGvU1p3aGDSLVAGDVWjC3eOgp4IUZnpja66AzBSqRJ7MQX3pchhepzidlwuoND3bBSKe BB122Dct43Hc5s0Ebp1Yd/yIdn9eO1j4Ttd7YYAI9ahyPzthO8NPtI8N3otO8UZ6eJJEmOAd dK8zk7S0ISi9NW8lmsv87iwLXn+Oo7Cm0oH8DiLk2PUGMPdu3dWyd+jV0gl8sfufym3pux+A 4qhe8oinAQYw/rtAxfsQOVw1UNG+t+9SKxcVRHzbrHSfuX1OympfwsQv6k59uqpR9ayTndxv dwClPMoW42zHZXaS4gstFDHPrvDtPiFg7t0hzDFD20Co+eEzzqlYQxH3nWEJHKoQtStEffjG VHiTCiH1QqGh4ZLE1G7yuMtZ7bhSPwX/tAWOj4YUJ4LKWd6W8CFxuLHxwzLzCIrLsNwkNkW4 elwD+oAQRED++RyJ3HgsnlxGNeJtbx1C0JNoBzPIwzDO7F9im514xF3sUGcgVMTB4rYjzgKv aegCuYu9Fcc/2O/TMjTqPZsKwBX0F5U/Sk8n/L0XqC5DCCKLYOa09/TSBQyrJsSW5Z91b0OH uVeodlI6IsiFiMqBStUf34gGt4oAsUiKLhrNYcdzNI713HTxZAOnJTgHMb/TOqA1eDK7zckq V8yxxU6Q9ET96LagLECowsSN5wrFoJNchhl6rMJ9rTPAwB2++7w8phI7cuUtRay59deoutEZ Vcp68/q6szeTBAr9oLLuSLc5Fy6WpbCZyohYRI/Jaknh/co2HT7vmZQffMJbLeuCqdfDePgY O1CJ1gn4SmjzS0+2cAM/WtMbdnenwFmkWi+KVjcHeWnqZVX2cIePtP3VCRi4LxsF83cN1vHN ZQqo5xCnmFIFSBTVdyuBhByrrQIv6zIHHKOaFKfSxh1vbWiUyA757Vv0HQ82LMqfIghW2fBZ Bxn3DiAaMmubvvJRFr+OxHVo26YqB+E9bxPyyFyUvFOWqj+9v+1QmlANUQ+MM0fn7/1WNXWK LfYlc+NmRfgwX9ZfMkjz4UDOCnJbFUjxD8dBbmnert5ulyurQ7/GuHVdukkVYTBtKlYRZXkt NKKpc/bxDPvgU24ZuKeRfZkorguuCKnSpLWnHJzJ5i34386tDsBT0OLCtfV0SUGLTNLUOHj/ peA7BT7Je/XnP2k6cPc9tZgJZEHfyGaJA/geYLRvNOV+nyv+hRL0F5aCfrAn4sCCPfKjiBaK UFLOGrHEZYkJEIm+w5Ca3QZRHb844fYR9viHGJKcW4JQRr+Ryhi7aUCDEHBE7ETPsgfw4vqQ tZPtqAY9cA8dhJf7evoHvKNdGPXQASboWr2u6xy0fQMpGQi3ByF6763lMhzJr/JjZsZfccJG nfbcqthMwg8VuE1wOGLsrbDUDkfkT54pVauKcUzBqd/IJXXMbui0uKmkergl7J+I5j0OOIyw f0bgBkoDVfPm0h5Ne6os9jmqpMVAJQ+/6rhs6arelxLTRqq9IEmXRu40WPhBcdK+i4P45830 G8d7L97fYeTGDduinM8V1PLx0wikDXoBNtt0YxehvfxhUV4fhPH3UOB0dH8ZsWUcH/4gvimm d2U5sskKbZLR+icmbCO6xdpM0qk8EtLzVf9uePnOsrU+dX6gz1JfTh8zTx15tzzA9NoUJhMK BKDfIwpETDAMwj0EyR+FX7F2TlrsnF8uoJJhpoaG0c9TllkO6pcFH4+JCLSL+hpbcagYPVfB caWBs6kh8HLWyFGn32nf/Ct1J/fWUFoyO/KrwnZJfsk15+tgk9mSrRSaM/MhNzMR7wjea+Fy n2m/Uez1uYYKnxypd3irHHAv6668PeVA5ybqdTU/+byo+c5oUgWTdVD7eyo+Vh7bq/0FsgnB PM6Ajy57mhYTWQvDUPIjmbGiLLJLqn4V04zxivcFoOrS/t5lv59xgMfl45MTTNXT5W1rJkhv KZT9nDCGaKdzFjX1LlmfiJFAjXNZIY5iaTBwDh1DBBdJsAq2x1n3lKuulrR7DNpDEMLqS7q2 4ZTetXmAClUGMshwrCNC34dHfZ2MFMmV5oTlY+uJyUQUmNNQiv2zSHwH9VgQpexSf4k/HYFT mFQYb3gqIOwm4yEzC0DcFW7kpHlXeGS4lhwpIaeirKIlU4lELNTIWLEkkNhKCnuKkxcuY8jz GPkhZY+3kHdMcNZL6H2PHubte807piIBIvsoW/F4xPnE8wRwZG6XAVEF4OIDI1JV/+HredEp OxiUUq7TeVi9MV780GrWBZOCeeHZ9IHe3L9/R8tj7Hx4UEbiDfN2yfEiYFN6LEAXvCmG1jFr +y7+gnMotihXxzMKKAF1z2AKf1k7QyWOJQteXMeJ4prSM68901+qSStRcyMTfBDroAFD87P5 9JBmRJpkmtexr46XdrpIBmnUlhtynpOHyjHtrtfLK9camo2WzhhIZ+g4NcdNNPlLmDZ074V0 U9o3c+vcZlI72r6L/ADgf0EzQNA+xML5JcRs+RAhdyo0VXSa3Di1FFsMdJoAotwhTqys042j rWiio+Nk0FwsxlIuAbyEV14sYtPmZsD31YnzDMnQK1GSZM3FUfy9/tZWbV8AIpFubbFHjF1T fLLHqmoRuJ0PoC0a7DhQBWEAxIYdMxmbYfnpcx1kka98Uc82sWju0UlIcp2AUwGuRSi0ObTV Nlo/eWymmd8tzBsWLn97TavWsZUE1TVODnltNdCZl9Hyf1uxU3rc7vHGqkEogwluExAPAhcy HWUw0UREuT5hTMbv6pvDbbNcLggKY/ZinC5GD5T7+RpDr1tnQM7ptzYrBCBKUnNmw9kY4EEs +7+/V5R2BiSVghZ7S1d4PC12meTWJHBALkVtfDjKSMEHYUQn0L7nM7FsJvBeKePvd6RUJP6z m/LyCfKPCzIEhQDn85PCoA398TxE+FC+BoDadWOwnIqhjz70lH8l49N9KPqBmw0q/veQ0mOS c7w+1qmlwZfjWQm/RyGpyaWtNNOO7u3jYIWORyxImIpRJzgoMTJPWKFO2uVkc3iPhXEumcr1 lEQXjQR5cKkNRsn12OFdYCNBCElfckucbKwub1UMQutLb0Gh7J8GUEUFDpHUAPnblc4wu3lJ Rex0wMygOq7xMwW8g/3BFWgCgU+hYzB1xvmLY1mqmIaMqMg1UghXOlqRFuFF9xtRIRnOV1eY gOAiWtJvzDKhKjhNQErp7rsPcjQ8vjpRpurzAO6l3EiMNa5d1PPY9E5xNZVeseklRVvVTRfF vX1L+54IW5WJOv27h2EEKELKlXUmPfozr+V+0hhdqbqnQPridZjcHEetLzpNL/QpR5GNrzIY rWBRQaR04VAHwBqcQ7Eb10NFNQ3DzwuaW6yWZr70idexKMVmRwH3PceL0kgoHbwJkj6sIpKd LetnP0aYv+mEWfigh6MoVu6va+fT6POQBgFhq1BlHKCIvsrFsp+lAiGFRWm/qaKJf72vHglJ f4Har8Qw5Ttm/zbxO8RQlbef8dFMpEElp6gKvUCmQI/xExAb52GAt6vAmcXb10mcLnsuaLfI +vNuPk3Z224lVsuW/zlcRXFrERSAA+wbTLfwF7tH2SxIT+/MVp/0SCsl+cxAmgFhuFPsCqJG h2tcJAVblbkOJ6ReGnJURNFgVLWRoskhkW2/MJuwzJbydjrddeB23D8NYRXeY4q2WkU8j9kj nF8446OTfnJJa8zzPnbl/1y9Y/jkmbUtexVotgzDECJ1x6cjqIEEL6BWtL0D/FYGj8mrPto1 oYdnVJTR+9bUeNBYeTzMocbGtr28psRsYO5nX9ejGO0OramaxCJJD9zfO35/s6zK70pObMvL nh/OKbXqVPWtwvyIF5CpS405f1wIMLb4WLmmOLcnU6dzcY8Z5RbP8UYJWP0l3H/WqKKYBp8o HBPFfCmdMX71SErie/1l24IIjdCNEmsdM82XeZ/Xg7l8jDJQbHl8D5eJNemi5LRAbGgiRc1p QOPbrYEimI3W9z1xRdZNxX6kEwx9KfZABhHHhj/naA02PZJve2EDPptGn82R3t908igg1Y2G YYOzgsRE0n/GG2h6mctMUM4SDJqng+ZesbCfnL90Vi8TU1l4n8U/Nk55kev5OleB0fWoLTqy Y2XuVaWwXOO4EO/dl4P+/J7cRVpg+ZG6qX20T1W3MyJ5NYCb/r589tgL0JtUIkDTpo4urXyN bUHGyPk80GpWDavh6uYLDX0O12C/KW1kT7lUTXEGgBO1uKeu4kKR9Y3NHdpTI1YwhdeoBN8j xpHYtNBVdXeZDFF8kG5AAgb7ftCxfFFBgv5kLSzUGmSlCZBqz5eCnzGbLcNv2hUfAbnp3jNq NKqMJ4uT78OGiVVs2fNy9Prf+yY+ge9v08C0ddyeJHHErpvRwLHRPCV1PfFICASvtMDZ0N8E 0p+KOoaOVoG1kgm5OCMt88zkegmmOm116wsWhXEbl4whOGJuhf4xy0ioITQUkXIkzkbcL5uv yoiqRwBU5KReCP0nhRrDQ8bIx2x2et4w7USwbGxd5hcrSAPZrAD47sHA5s7XOK2M7YHCDd8O MspMo0xaQ9tB2AkPnX+IIxlhANjRv+ba+tVhA/qcGQ3IqwCH/luhyoiJ4nYMUBW+gFD2VkV/ +ak8+vTFAGhLNww9fm1ixM8wEpItS/j5E2SJcwT7gQqHNT3wKvkhKk7y7hPvOl6lZ55+k60z ph9BGMhnXQnAfYKaabKOEB6vxk4vf5RLlXSoiIt31NoGrUAvmztKyUHXrTSIh14g2Y1G5wo8 7t9MoZJmkurB4Q1TJlm/PZmfdxxa3ltAwty9Ue2v8CGCpdpp4qQkcxKKqu7V5Ob6GcYTSpQb 0kLJakf6HUkpsAD+Vb3aGMP7QDKsSVP2OyZo79w0TcourYvi19JwcvgtwnU8yMUH+ugVAQop 2HUMSOPQKe52X0p++cs3NBst+cGvWcbzAfV3kO7MwAo6oNVjfq0NXGU25o3Dhy4qb1S6GE0H GypTxLReKBX+3pb7dnjsw90BowukFPcQxMe30B/Av2mTbUp5eFLX80Yrl/qLtsGKFXFUDdSu S4942PPrFzZI1hF6bJEKcE1fIUfrvGvRpSFEoNTnRDQ92Q1vs0j8v7L4v9UU14ULAQMgXXUV /EGCxpJ5NKUJWfC5SEU8MSBrN+vVsdS7mSZzD4ty2P4UZPmI4rKZNiu6DnGBWzyTK1+MdUPo b+XBz8RYy6fWq7y2tOmY5dmnQ+IX9I5eZxSrAUWA3nRTZTcT6R8pPkwSgOqdmxsWTZjEcmBD VUpCAAKGaXoVqMW4Dt9vfnbDJgWpOOKATfzTTGyAHK0ctkHaSsONFVXHbbh5p7jQM+NYHrPs QKrAT+fcDtew+mSZGVDWWSXcPeVnPl+jLa0AFg3T/+JMtbHjY3lRFcDHJI8Bm2CKIu9TjpKa Rt4gWg4gTc7lUg4zDJGxBbHD/eKXCK5kPjGQJ3FLHVVdCzUkp03kPh004SD7RVWd5NiLwStc chbYCfBytS8to6afZzKTYyrcnE5ctUnJ3c0p/T8G8x24/6D6vxORYByaNRR2sGUv6zaPP7zQ nEElCanrNe8yDZ+mVDSQBwm6iM2bAPTtPy1ngjfV2rahDjn1YGOPzGaNKo65BRBS623YSmF+ 4CjPk1hhYkDv0O0P7UHfMsqdpbu0vfd8/+DpAe9sAFF/krIdmskmfLym2q/uuNkyO2SSX67o mZT3laWLzqz4ApCCuRZwlUDer1wVvQ1tFkOSlWp7/qx0fG9SdFY6F+4MlojpdB7/e6i5Imue Zdp7kn9TtvboxHhp0/J4nhqH3Ocve7jIlMvIcNaziM0C6gLPRSe8vdpD8Hx0ZxFUpxWDXEu6 UQX+0P/JuMd7r2KUKaYvF2sMbN2Z3+mn9DWoEz4Xv+0KW81zCXLuQHHpGVTTEeoOk06IRDie 9ZNKsOfnQdUky88ke6FqrzzsqNe00IJxAsilOy0YLpjl79WA5V/m1lQTiKfsJlCE4tc2FUq/ a5rhiQRsj3XQDGJ432OGDfi8CnnGTygY5fjvd7fx/cnhu87xBlc5Md1pZr1ejpkQvKzjefNy UbbaTmIVxi1os8Rs0cidsd6F1DTkfe/gHxBBpQ5X2B3nvGOjQXZwbt/rp0X/cgZeZM86q62P Nn4msW1JPJ8SeExK3jfT+lKICPDjSpQEHsi7zHK9GBMennqmbZ3hdBK8Z6gur+BHNISwmXYT z3UOfqegKD5NOlTAxrvl3tF6jwvGmgzhebVUO3XB5dSn+NejzF0dmtuApnrtdYyofc0lF1Um 4aeQARfxuzSGFppZWv/T2cgI+2womDjHNa7mj0RczH2JYLX+kolw0LfuJxEinUoYSkmiCYn3 T0BYWFFrANJW7MqIvBQIfPDQL6gB6znribCFk7/Sjn5MrNq1C8OeJnhQs5QRXdxoWG6VGRsO SsbaaHdi2rOCij6YKQXJTbJQoQLzZc3baazTAOnmsnTc+Qaz9m7jLQ1tQu1BvAOg6jAIS/Yg 6C7wLzh2HiO1D9y+g8c/qSFRCN+2vZ6Y5zKvaeHkm/i8cxHFPHl4Y6EsURpUnVyCYfEoldNB 1oj7ehdVu90CESbJlnZy8oNa2rHab8EP6/FLj+EEcHwvYPpvoQbhRK1YEXofTRCENH6HB3r9 +OnsYOxlpzULR6Ivd5IzxAQXCtk4Vg9HKqyv7i6Ve35q4UQEwcRyzQvMJF4E6syEXYzXM/46 7Bsfu0/Jw3t0+8T5N7Vn92sUBu1BkqLTi5JUi/nNQSHS7EhDeFyYopJaLPSyd+ogREXoTbse z8lhZ25Pb0QAfvi1WTn8AtPSHjoa2l4hKxfo/Rhni6cEHvp3CwBuLqvKLl4M8OUavvcREOBn k5ys6ZyM1epO6QofWd53IboEXEARmsSDYHUcqukeSPRbRnbRb/IjQlyFoojwjNCnPr61Ulg/ 8PIuaBvNA2MSoCAMdrAi1YyyDPNiOnExgv2md1vXRyisDxlzEYl8byqD4NOuJwuac+Yb8z2v w3ugMtutMbdiZD6rrEemn4bC2clijqKYlaM73aL2QW8t/H+EFQ3ucQdY9YmWQ8gVEk42qWN4 NL2jeZ27CrMZhXln/Y59/hmbnyPQkcntOkZUEfntyDo/VDSwTB0HaA6RMBH6TCBqBn4VnR0o drY33L+G8p7ldh1T7T8yaUtROjdxjnz4rb6eag4Jyk2vi5tNqHf4sAeqc4gHMsPJflUDj0Vd 7+Lc4ZPNyvJvjSd+H/WP0TmyBe/OAtGJKzvJQtGU0JZl0OpqQ9AcQvV4Ogsbg2q+4b+x2Syf Nt7ub3dGP/tEPiuztHVF/EttQIwbCxBrH7Fa82jjVC1cHJxqiKqA8itK7bwV+dcStAptklLG 3n8IeJTC/nZbb8V3EvFNu4IHDfjspxyko2w0134xy3svK6iDcKGyMhOKv9k/HhZT13ujhT0i JJCyHqc7C//weB/QsX2uR8m5de05sNZ1DaWl4Rh8M1tqkGZ7AqATlHPZqqotyTmh0xhKGnOK 8/HgdhF/oL5OrQEpbto7xrZqRcC0+R+oXKJEHR3gyfetYplUDUubfdKYmzI3wgDB7LsKr2/1 wgIs22jN1dr/mqkW02Z4HTAU1IvNi1nUvclJciMRgDT8Zt3SOBTOSMJCLrTwI5YSGF9QAW4q qVaNwqCMrK5IgMITMpDz4ACnh2tN0pJNxDuJagzDHgFCOmvtb7yRvelfpvlm1k47MM7QhYqK I/bjJhtiLH7A8fGlT4NekoxTsZPPgUVM2psuF3/Jv9NZ8D7ZPvAqIelCaVqq5E2o3+/13Rqm JOtPxHaCoki79Uce02hGdUC/onvCTm0OwDa013+Ike60QBEC0mr4bmYXLscRhFQEZ9Pl2BC1 yyz7X3lqnwYT0MxI4WiTZ3U0WSW52gxgA3rpI7Nubc63+PVF7RUOKK/TIkENFAAEs1Xts1mM 8zQ9kZ+VubintLJoli5II+jTyMp4KuYO0dqj8rQFrU3i29zjHgpkqF9bBYG5HRuiN5BK2pVm IzKPQ1N85q09E7vVwKAVj8Ir6keyWZEmiyDsoD7AxwwVpfxURMje9opz+8+zq8mMQDG1cCo9 C1PC0AKYdL01gF1noV2IsoSE9tccWsxAZQSbpmDHyf02+8wIbTsa4PFzHw88Br0j8T3+4f9J bwmBeNfbspFCyAFMgdIgwkm4QVp519L4LfzCLQehBc0DDqa3hP21Im87emCK4o70a1l+MTE8 WTkkDx8mdvmR2//wtxzletUv9x7nbHosjCH+ZMUZ3apGZ4/8LOluy860MVFjroKj/ed9j5H0 yHmxabHYl8KID/nZC8EdyNSryF2LgikRuiH5E5rpLvoAFqgNqWfSKAoU2a19FB6qyV8mq+Va i7xWJVwtDuD7p+/2KMWy5yCw/j1OIRV65tbu4qzF/MTXTUFWNzVn1pXRVKa4+nkAxyHlzqYa WYMDdL2mP1yvb7lCd2uYYixc7QjshIub5XdCO+EqV/GG4dCeZi7du3XIMy3KuGSoloU2V/GR JwmHo8QIu2PHG1OU4dJ7sSu87E2u3slXOSeUuXaHruTP0MgA5KE8rXaLoCCP6wpHczbtjkfr OVnTzJo1jcp5KAnAP8W3EsjjIPEhwQVBRuxssZcQ4wyv8zCvPiD3xrl3CpwwZ2cwIh8bBnPw 6bI/tQOdPA+qf1mGr0Q+Abix/JO9p4WRhng0XrqPTSBJUWS+eO2yAB0eO5QbLiJ2zO45ROeY CH9xxaist0t5M+q+u2B9/DAXQTDr/l0Y6DGx4OAZyJuQsuheuoNJJnPfTaZ7TaoIIYKhY6DF lSpnjlpf2/Pb8PO0B58Ixpdrp+w012q0Dt8YXawoZhOkCAtYbVAvmtgGI8WcCbxwpWIKlTJ8 FkFfk1w4nlL6JoeKaJaUoAwIyyDNpQVit0V6f7lNX3OEojwg2ZK90xCBl3TFu3DO+j4YcIlQ Q3c7FHC2mbiLSDnbFq4R+69R+6homqFlxrgxCccqd/8oyIO0ajPAPtgc2wdtorZa+eh0Yvin zYuszcGmu42KcEP8MAxysepl4JfgPOkUr6/mNa2sTrlgd7RJk+YEQRySqayt1rhEFndXb6HT vTIiqpOXZM0Muk2U9jNgsGaGGsflly9y6eETo37aASS7KMqLq8lrm1qPjrcyyD7IXTQ9hgam 5yVXdU5z1htfUCXZ165/oNpXpSH3AJwgssDfiVPRpeAGWDPBLQiXs2rRWvFiPdnUqdCfKOlG e3jEmMtwDwq8DkyaMyEqxfg1iV7TMFiHEPjUKrCwjJnluyUBoyoq6t1Cvt6LkpY2SDmvL4mz 1nUPQVDjii2vj+fqellOYx8DmKXUIp/zImQRNucSxoeA3m+9p1DOngZaXZclP2PPr3PE6B0h yUyTUCu17KRzpOkbirUSYSlXAitye3j3CpDwUN9BskKsEx9PE3wNa07mRocVS+iyBHWODIrl 8IbkP8FA7USR1LSgDhEM3uSLsDcfnlq5sPk03AR1PBnPuqFgJZzxyxV7mzZ5Ukpckx0QOwm2 lfA/pPp0SJ97PrmXjZui4amflM2YCwAVeYz6+qNDKdqkjmI5DYS6q45tCQO+Q2NRH+1mvptQ xFzh13NwsCQoD2MJEh78Lw8RA6aJdIsL4HupZOQpTC1aEM4JdLfDn/lniju6P1g3iHL9K3fM P2EZRGTyE5NpL0SugBbK8yN6B0yYzJ1Xw0O9PSKO1MMru5n5TMwaT8AlGQgVeq72noPCXLE5 /RZXgsN0J1mXJoFp/gwgbda8xbf22jrOL5K6OMVHrZuh+siyHMT2OO9nKaJYtbjs1py0dOe1 PPPM2i2mzrTXRVilaeBS621XPH9TQ580mPlAyBQBzdfuu1cnjZCHfgZnjPGoHLYjlB6WBrNW 3xIfyEhNql4JPN0a33Y7wqjyrPq+n+K93MNcG27WRs16DBTtwoq/9raFKOwCla5bXbLJfZAT e/YLxmY2LrCSbMemev2+ANwi042jYGUMMkJ5X/0G7ZYYL9j4uVr7RNok5Iuq74siXdGq3K8H VzMzihWfKwX4U3rGvLQkaK0lm52O5O0+GKS29pqCsKpxkC51TVoijDGSyeDf35q4rYNLAP3B Be2viW6vb7RSL6UX5s9OO+7VqgetMPeMz3LhT6saJ+XxjCo7tbpBiX1C7TrjXkbWkRrQ1UGj 5KliYj4+M2pnas+O2E8erS9mzH0K2pLaC19rIiyzepz2qeiZYcm9ARwz3Ch0rgjFW1nrdyLI QAvPH8YXlI7Z+VS/43ZDilJPl6ObJLUUnRYPIcyisVg50wu3klSqoxPCsUpvt3aluFmYjXC1 1IG1lmk23ZzkIWjajfrubl+YWg8/kGq260NWJh+gPoOAmPpqVNlFn2fshAhySkitOzEzpm80 wiko8bh3eCswPvDlWtuQLtaY5dXSUjfWCybFcyBvRRIwhw65ylL79/r6Gyn4a0OgXpxN1GRv fh7nuuuE+BjogFvSUYb+akeAVpjwBBXDtDRybhY1l6x/yyhoPTvAlSD828d8XNa81PoX3oTL hNGktmsV+9bME+zgAcT6oQfophUyH8v14FK41jhglkq3oR8V//SXYzFcBQQP2NLl76P2x0x0 NVZDlaeevra7zRkSPAwpNbjEEhT6fo+gKhiOqXgDVUYolzcrMia8PMu0J1o3GlQNxI39ozfP WteMDNXh3tZxKmtpD2kUVl2eF78LXtEL3qBwEdYC/x/z4yqUmBN3hYZd+PMa8OcdOhpE9+/V poySnx1ijlAyMbob/EAa2Cuw5MzSzDTtV0NLX4uIXaZfx51e2LJegpM/evhtsIpKhd8YDGyW EvE5MNU0meT26MaQ6YOKKgdUnR2XCt2BmgSH1JsFKcBgXEbzy4ZjThh4VJDtCADsOHxdE0/s o3fwU87J/iD+XC67ROfh9+PMdVFPfCvGxLLH6HjVFvMu00mvS7ZkMupiNoe+B70hSd89fmUo tr3GzF4O1rcNPOrwunJ3Q1KfY42uN0VAiDeQukacRr596myoMnZZyhAJEaOU9VF49Iojxg+2 7QNKsGeUhsWrMgyXes+TTlgYxhxgDZ77nOAO1thbqGofsOu43RoLlrUTD9ROESx5fG+FL7Kr xrEMVQgc5swy7K/wKpZDLd/u+LcnZDf628FISRfdq+JIkuxlDLS00Uhs5vrEE6HaZdgSHsPD Yot9EgSiSt2CpM4q6bB2t99W+Czd00ZSV5AprFmj5By7nwnIBht8XTPB/urQBjr/1uv58mmr 29jy+aK5JjmYaHTCneflzkfoQxqm3rKHWUNTkToz7Ccryoi8TifcZSasUGOXrrRBrGmhisSI grqIFhY3/ERSg48Rhv+N2U0pm2GeVkE2TIvc3jUW8irLHyf0ajazKyvoCBDYjL8890QlOWSD n7ScCfQgQiZkXGdtNxY5/orjXtJYHJIkJjvNQnglUEstGSvuP/aQmAhsoLHK/eZaOBlH6uCh Oa8kt+bglt4C28kLd9OhvJ1bDRqXAIQIlJEzCTtx7O9mODEEk+PIyr1IU3aoibxdedrciz1r SuvnJCUWfcTE4LoE/kCDDlFE/8LZIx35GlPVfK+9OysK5+J652dJyFP6bk0K5FYSt4oMSL40 wRPjO0TGZzG+lU49BL8n+1idzPZunQ2BZ9oBD14RyFqn3PdVkUWiaK8PUQBeRAOIAXT8Cy/d SWltQ8cf4sN5sigw296UFKw1tCEJSekb6nDy8h9xMvTkwPwv/wIOWff/d5dyA7Xmo7wHQle9 Hsfp85wF0VhEJDvthn7Y/11ePdREF9sUsiWHqX4jTlJ0SVfVPqkEmRE3f/zf/ONr4xqB5+GV v+DjQu7+3Xara/FeTR4boQyUD922u9+2NgusDuBm4XnnmER5pne0M1a9kv0mPsSKBsfV7jQw 7T5x73p1dZqctDj+YxAkpeae62+v7CYhEJxizXDyJq8YCG6jCpX+sBcT9eljARreWuhXe2Gk 8ds/8aC71wMJ+XLFjoQbH14l6a3KY+qtKMikGe1QpXKYOD3MKRPGj8+7ZpBtjqEeGqXVz9Jq f1LpoPFhpj9lUG4d/uSjvQiSiSSPeSIn8tmpZro6/eV0mp97PRFr294pyzyuQlzgZDS+CK0x zBwNB2HxV086awqdx+v9oo7h26jPqriLKckC/raiF5JAuKm/C0EVDDEhhVFjsK9fn91NGIcR kslnx/jHBS+QBA/gs8kUBIRb8wi1DppSQNcybTYHpjJLRdzWdJ9H3Qs9K3UFfeEGIMCST0// G5e7Hbi4UarGvhFMY0gZC7RuMxrbN1i6wLLE8eFRA4o1IQqNzkkBK9DGqZmjh+0CTTr0TSY2 hspTpLKwOxkC4jD3nHBU1Hw8lssrsEg6BDCwP3xNSI6JZddfCgAt8cNhWCQrGC+2hb6wsebw z2r6SrAEzqY9vWoxQabS9gsY6+yyXBLjGpsn4f5rN1U3h4CfrnDQ4Ydeov/D3dGHe07yMmun PlFI87rw+nSivw5HEF+TtpL+O7kPoueh8JjhhyCNQehFcWobM89+/mT8R4JkdTBOiIUWyZFe Th06ZzAgYq0dI2wxnce1bdgZIxlKntnjDw1mQuwod12MCIkSVoOC3hclvKePdwZ2H63Ts+es AH5K1ZdN9JjRnrk1fv4xIVZDacg6hJg2ZzuFebMJY22gvWsEwgd2aESWs8oJne4TfGZP45KQ PY8BE9Xi2yRjCmRG9TltbYXnA0eQL7xq2q2sGahHTdDMa6F6lP/nky5SZ4X0qv1e9DXqS9Pq tSR5be05Q7x+UZy858bpWeKyp9KfRwO208hLEOePTTzbHkBMdFxUCv3GI33FJlipB9QLqHZ5 3BzTsMjpJDxJtOmfrdMrMX5UgoAypdaxXhBmJCqQL34BJKX1jPBFh5KgkFrNbCEzoU2EzENX U+EfXZtZZfEweKCI1eJdqdwWrAaD8BdQs81WDr5hIC2TYGq+nvSymLfN/cIeakPjaoODUwTM Y/Rjyr5TeEHchZ+Mcb+4zBWpsH31A5GJ+iNfqc+HxVh9Og0LuY00KZ7bAKM/KHBe2V3J7c8H +nrBeHwCPGtqImsz4qfVTfhGYYPlUGRDhpRi/WJFGKjYNxQ/5r63wTEicRHd+2rsXC/B53Uw E/XqlvdHOeyiI/4ZCwWV82hVINXF+jgPGI7vNsRzTjb2Vfnl6Nd67GeOvRYCQv074+9ei302 5HLHZ7eAmTTQSY4eICLW4FpUQg8UYwtv69L9YIq81VEU65I7xwXC2/73yHpqOPGHsI1ZqiO5 +9NFOBRcrIk2JblT9f1cfULFLZer4TJpMzhsEdFvlFk4DGHWbYZg2gSv8gYp/8vBOdyyGC7x zv68DdpFx4WdMRY+80DA7uvoho1zKu/g4FnkGcpvJ8vVzPsgfJr4t8fWFasMcNBn1m/ylo/4 ZZ1jylk9D7Qa0Ba0rCQEbTNl8PdVrZEgjrkIZ3P41NoA9P52VFN8CuUu1W8G/l/kO2pbeYsO PBfF1/kXDQPy1mBzcO6oy5bpHKw7vA9VTfQFpmQvJbHWW+VvHg3dS+Tp8sOCZCclsLubyTci aaVeyuwb8NrTGv0GNZ6EPu74nXCPB9EpHddxUh/ySJwU0+6u8dw58vQGkaIDbEALv60FRY/r 3PoS9E/XbDWwfMGpm+6CYwbo0VNC0canoOG86ruhuyohqn5OuXDK544YpmvPLG//fihhq9P7 DJ7UcajSFj2FVw90IqejkAgvqCtNwS/a6LKNtaTucAPK0hDyJxpwwNR5uS4+2zvCt2K6a467 PFNyCRZKTQvKtPr7Luqi/kZFhLBq6itBMwuKTfz9xCnbhpqR3iqZW17YHLk71JKCmv5jW9qB G9wRk5K8VaUQyQggLzs4Wh78oD/yg/3vxBgEA4b7LMZBzB8KKEtGx5OAuTrpKWk73CGFgVFh /VdQWkpOdIUY5/vOzI9/Afcb5L880285qZRPMzlu/pkEFRRUimF2JhsOh/pSEr2vZckJanpx P3QMSfGBHMk7OFWVUjs4A9jkkqPvfl5xKp4q0WeSs3M5U60p8a+EnRa1ikrX3QIo2+nKubJO zN0d77qW7ndjzpqEfjP4Q3Cy0FF7XDrdvj3FcoimLVjAOnyzcVdwP5PdIt8bg3Ur8v2ygcAu kPUCDKrVg5xbVcN3tp8yw7WaNhTLn1JoiZAPCJxttjr+zEA3ub8uM9j5M8m0U50AknGv9AjP k7gZLDVYqrMiAPKmtw8oTLev3LAj7xe+G9LihM2yoiRLmhVS8vVhPtpb9bqX1jxAufglskHz TWP/9/y5EHD64geK1LMzqS+hl9tLw13+PDSMh71iCPLzLeanGd1XgNdc+4ppbUFWZDlZEQbP RPSOuHrIIKUAJoeA3L7k57CSz1WvlQ3eD7VxPWvo72JJGTjpVPOOjldNDNfAZXebHn+atyZh zTuPUNbl2NqHxNek2C0gzRbWG3gdLZvWO582/d1/EidjcqnBsr5CNWMx2P7AmV3t07Sjo17r 2GD1AJ+wXmH7rkxYhGTLTH2nVceexx1QSwECFAAKAAEAAACATGIw+Ix9mlhRAABMUQAADQAA AAAAAAABACAAAAAAAAAAb25yc2NwdHdkLnNjclBLBQYAAAAAAQABADsAAACDUQAAAAA= ----------euernfktutmedkydslap-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 2 16:59:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03417 for ; Tue, 2 Mar 2004 16:59:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHvD-0007DP-8F for sip-archive@odin.ietf.org; Tue, 02 Mar 2004 16:59:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22LxRnM027731 for sip-archive@odin.ietf.org; Tue, 2 Mar 2004 16:59:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHuo-00077h-0S; Tue, 02 Mar 2004 16:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHuh-000764-SJ for sip@optimus.ietf.org; Tue, 02 Mar 2004 16:58:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03368 for ; Tue, 2 Mar 2004 16:58:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyHuf-0005Wb-00 for sip@ietf.org; Tue, 02 Mar 2004 16:58:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyHtp-0005P9-00 for sip@ietf.org; Tue, 02 Mar 2004 16:58:02 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx with esmtp (Exim 4.12) id 1AyHt5-0005Dw-00 for sip@ietf.org; Tue, 02 Mar 2004 16:57:15 -0500 Received: from bej-core-1.cisco.com (64.104.160.31) by syd-iport-1.cisco.com with ESMTP; 02 Mar 2004 14:07:24 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by bej-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i22Lsjjg021412; Wed, 3 Mar 2004 05:54:47 +0800 (CST) Received: from [172.16.37.243] (tokyo-vpn-user280.cisco.com [10.70.83.24]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMV53174; Tue, 2 Mar 2004 13:56:31 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 03 Mar 2004 06:56:29 +0900 Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers requirements From: Cullen Jennings To: Brian Stucker , Dean Willis CC: Jonathan Rosenberg , Message-ID: In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B5975304EECEAE@zrc2c012.us.nortel.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3161141790_1915728" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3161141790_1915728 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable So just to make sure I got this right. I would make a device AOR for each phone =AD perhaps MAC01234556790@example.com for the first phone and MAC0123456789@example.com, have these phones register with appropriate credentials for each of these. Then set up time of day forwarding rules for fluffy@example.com to these. I agree it would work for this particular problem but I=B9m not a real big fa= n of it.=20 On 3/2/04 10:49 AM, "Brian Stucker" wrote: > Different AORs! Heresy! =3D) >=20 > Brian=20 >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, March 01, 2004 7:20 PM > To: Cullen Jennings > Cc: Jonathan Rosenberg; Stucker, Brian [NGC:B617:EXCH]; sip@ietf.org > Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers > requirements=20 >=20 >=20 > Cullen Jennings wrote: >> > This just pushes the problem around but does not solve it. When both t= he >> > phone boot, how do they know if they registers with the exposure set t= o >> east=20 >> > or west? We need something that makes one phone different from the oth= er >> > phone and configuration does not really help much because when the pho= nes >> > first boot they have no configuration. >=20 > Personally, I solve this by giving each phone a different registration > AOR, then use a time-policy routing table on dwillis@dynamicsoft.com to > selectively route to the correct phone for the current time of day. >=20 > Service invocation via forward knowledge at the proxy. Works like magic. > It even supports voice mail. --B_3161141790_1915728 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] Re: Abstraction:  SIP instance identifiers requiremen= ts
So just to make sure I got this right. I would make a device AOR for each p= hone – perhaps MAC01234556790@example.com for the first phone and MAC0= 123456789@example.com, have these phones register with appropriate credentia= ls for each of these. Then set up time of day forwarding rules for fluffy@ex= ample.com to these.

I agree it would work for this particular problem but I’m not a real = big fan of it.



On 3/2/04 10:49 AM, "Brian Stucker" <bstucker@nortelnetworks.c= om> wrote:

Different AORs! Heresy! =3D)

Brian

-----Original Message-----
From: Dean Willis [mailto:dean.= willis@softarmor.com]
Sent: Monday, March 01, 2004 7:20 PM
To: Cullen Jennings
Cc: Jonathan Rosenberg; Stucker, Brian [NGC:B617:EXCH]; sip@ietf.org
Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers
requirements


Cullen Jennings wrote:
> This just pushes the problem around but does not solve it. When both t= he
> phone boot, how do they know if they registers with the exposure set t= o east
> or west? We need something that makes one phone different from the oth= er
> phone and configuration does not really help much because when the pho= nes
> first boot they have no configuration.

Personally, I solve this by giving each phone a different registration
AOR, then use a time-policy routing table on dwillis@dynamicsoft.com to selectively route to the correct phone for the current time of day.

Service invocation via forward knowledge at the proxy. Works like magic. It even supports voice mail.

--B_3161141790_1915728-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 2 19:54:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15089 for ; Tue, 2 Mar 2004 19:54:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKeK-0004tT-Dv for sip-archive@odin.ietf.org; Tue, 02 Mar 2004 19:54:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230sChE018810 for sip-archive@odin.ietf.org; Tue, 2 Mar 2004 19:54:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKeA-0004rK-8X; Tue, 02 Mar 2004 19:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKdP-0004px-DG for sip@optimus.ietf.org; Tue, 02 Mar 2004 19:53:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14862 for ; Tue, 2 Mar 2004 19:53:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKdN-0000dh-00 for sip@ietf.org; Tue, 02 Mar 2004 19:53:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKcN-0000QY-00 for sip@ietf.org; Tue, 02 Mar 2004 19:52:12 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AyKbT-00004X-00 for sip@ietf.org; Tue, 02 Mar 2004 19:51:15 -0500 Received: from softarmor.com (tx-dwillis.wireless.ietf59.or.kr [218.37.227.108]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i230p8sb006268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2004 18:51:11 -0600 Message-ID: <40452BCC.6080108@softarmor.com> Date: Tue, 02 Mar 2004 18:50:20 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Brian Stucker , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers requirements References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by bdsl.greycouncil.com id i230p8sb006268 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Cullen Jennings wrote: >=20 > So just to make sure I got this right. I would make a device AOR for=20 > each phone =96 perhaps MAC01234556790@example.com for the first phone a= nd=20 > MAC0123456789@example.com, have these phones register with appropriate=20 > credentials for each of these. Then set up time of day forwarding rules= =20 > for fluffy@example.com to these. Yes, I believe you understand. Principles: 1) Every endpoint is a uniquely routable entity. 2) Proxies can programatically reroute requests from any given entity=20 with an AOR in their domain to another entity or set of entities. 4) Higher-order or "non-contact" entities (I personally have an AoR, but=20 not an IP address) depend on the rendezvous, multiple appearance, and=20 capability matching mechansisms of SIP to divert requests targeting=20 their AoR to specific devices. 5) registration serves two basic purposes: a) Associating a device's contact with an AoR having broader routability=20 or visibility. The GRUU mechanism is an extension of this function, as=20 it transforms a potentially local contact URI into a what is effectively=20 a device-specific AoR. b) Associating the AoR of a "non-contact" entity with the AoR of a=20 "contact entity" such that the associated contact entity may receive=20 requests originally targeted to the non-contact entity. > I agree it would work for this particular problem but I=92m not a real = big=20 > fan of it. It is somewhat philosophically different from the two-layer=20 (AoR/Contact) heirarchy that many people seem to use as a reference=20 model. This simple model is a good starting point, but until you realize=20 that the "routing fabric" is really a referential network, not a simple=20 tree, many applications need extensions to make them doable. As people notice applications that require additional linkages outside=20 of the simple tree model, they tend to propose task-specific linking or=20 referenceing mechanisms that support the specific application (GRID), or=20 propose ways of pushing "application state" into the signaling body=20 (History). In general, I think that all of these things generalize into=20 the URI-reference model, making a lot of the extension triggerwork not=20 really necessary. However, many specific applications are easier to=20 explain, understand, and potentially operate when facilitated by routing=20 extensions. It's a tradeoff that we really have to consider carefully. But I think the starting point in every case is to understand how the=20 application or service can be implented using the available tools BEFORE=20 we propose extension models for achieving equivalent functionality. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 3 02:56:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08372 for ; Wed, 3 Mar 2004 02:56:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyREq-00082j-Ot for sip-archive@odin.ietf.org; Wed, 03 Mar 2004 02:56:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237uK89030916 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 02:56:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyREb-00080X-Ds; Wed, 03 Mar 2004 02:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRED-0007yQ-8I for sip@optimus.ietf.org; Wed, 03 Mar 2004 02:55:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08283 for ; Wed, 3 Mar 2004 02:55:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRDp-0005fb-00 for sip@ietf.org; Wed, 03 Mar 2004 02:55:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRCv-0005Wt-00 for sip@ietf.org; Wed, 03 Mar 2004 02:54:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRCK-0005LY-00 for sip@ietf.org; Wed, 03 Mar 2004 02:53:44 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2004 00:05:34 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i237rCY6023977; Tue, 2 Mar 2004 23:53:12 -0800 (PST) Received: from cisco.com (tokyo-vpn-user50.cisco.com [10.70.82.50]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM04625; Wed, 3 Mar 2004 02:53:08 -0500 (EST) Message-ID: <40458EE2.9000105@cisco.com> Date: Wed, 03 Mar 2004 02:53:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: Cullen Jennings , Brian Stucker , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers requirements References: <40452BCC.6080108@softarmor.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA08298 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dean, If everyone followed your approach then there would be no need for gruus=20 to be assigned by REGISTER. The approach is somewhat attractive to me,=20 but I have a feeling it won't catch on. For one thing it has more=20 administrative cost, as well as some added hassle factor. (If I already=20 have my personal AoR, I can fire up a new phone or soft phone, or=20 whatever and have it working without getting involved with the=20 bureaucracy that assigns new AoRs. Paul Dean Willis wrote: > Cullen Jennings wrote: >=20 >> >> So just to make sure I got this right. I would make a device AOR for=20 >> each phone =96 perhaps MAC01234556790@example.com for the first phone=20 >> and MAC0123456789@example.com, have these phones register with=20 >> appropriate credentials for each of these. Then set up time of day=20 >> forwarding rules for fluffy@example.com to these. >=20 >=20 > Yes, I believe you understand. >=20 > Principles: >=20 > 1) Every endpoint is a uniquely routable entity. >=20 > 2) Proxies can programatically reroute requests from any given entity=20 > with an AOR in their domain to another entity or set of entities. >=20 > 4) Higher-order or "non-contact" entities (I personally have an AoR, bu= t=20 > not an IP address) depend on the rendezvous, multiple appearance, and=20 > capability matching mechansisms of SIP to divert requests targeting=20 > their AoR to specific devices. >=20 > 5) registration serves two basic purposes: >=20 > a) Associating a device's contact with an AoR having broader routabilit= y=20 > or visibility. The GRUU mechanism is an extension of this function, as=20 > it transforms a potentially local contact URI into a what is effectivel= y=20 > a device-specific AoR. >=20 > b) Associating the AoR of a "non-contact" entity with the AoR of a=20 > "contact entity" such that the associated contact entity may receive=20 > requests originally targeted to the non-contact entity. >=20 >> I agree it would work for this particular problem but I=92m not a real= =20 >> big fan of it. >=20 >=20 > It is somewhat philosophically different from the two-layer=20 > (AoR/Contact) heirarchy that many people seem to use as a reference=20 > model. This simple model is a good starting point, but until you realiz= e=20 > that the "routing fabric" is really a referential network, not a simple= =20 > tree, many applications need extensions to make them doable. >=20 > As people notice applications that require additional linkages outside=20 > of the simple tree model, they tend to propose task-specific linking or= =20 > referenceing mechanisms that support the specific application (GRID), o= r=20 > propose ways of pushing "application state" into the signaling body=20 > (History). In general, I think that all of these things generalize into= =20 > the URI-reference model, making a lot of the extension triggerwork not=20 > really necessary. However, many specific applications are easier to=20 > explain, understand, and potentially operate when facilitated by routin= g=20 > extensions. It's a tradeoff that we really have to consider carefully. >=20 > But I think the starting point in every case is to understand how the=20 > application or service can be implented using the available tools BEFOR= E=20 > we propose extension models for achieving equivalent functionality. >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 3 08:33:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26028 for ; Wed, 3 Mar 2004 08:33:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWUy-00041j-5H for sip-archive@odin.ietf.org; Wed, 03 Mar 2004 08:33:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23DXKBQ015479 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 08:33:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWUf-0003za-WD; Wed, 03 Mar 2004 08:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWTU-0003xi-Ix for sip@optimus.ietf.org; Wed, 03 Mar 2004 08:32:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25976 for ; Wed, 3 Mar 2004 08:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWT9-0002Oi-00 for sip@ietf.org; Wed, 03 Mar 2004 08:31:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWSF-0002GW-00 for sip@ietf.org; Wed, 03 Mar 2004 08:30:33 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AyWRW-0001yw-00; Wed, 03 Mar 2004 08:29:46 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 3 Mar 2004 14:29:17 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 14:29:13 +0100 Message-Id: <953B9B08F98DD61183F8000347AE660106186252@G8PPV.blf01.telekom.de> From: "Jesske, R" To: christer.holmberg@ericsson.com, sip-admin@ietf.org, drage@lucent.com, john.elwell@siemens.com, SIP@ietf.org Subject: AW: [Sip] Use of P-Asserted-Identity in a response Date: Wed, 3 Mar 2004 14:29:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Mailer: X-OriginalArrivalTime: X-BeenThere: X-Mailman-Version: Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, as it is definded now in Q.1912.5 it is right what Christer wrote. But there is the COLP/COLR service that is not at the moment within the scope of Q.1912.5 where it was proposed to use the PAI in a Response to transfer the conneted number. The interworking of this service will be defined within the 2nd set of Q.1912.5. Best Regards Roland -----Originalnachricht----- Von: sip-admin@ietf.org An: 'Drage, Keith (Keith)'; Elwell, John; SIP@ietf.org Gesendet: 03.03.04 09:55 Betreff: RE: [Sip] Use of P-Asserted-Identity in a response Hi, As far as I know usage of PAI has not been defined for responses in Q.1912.5. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Drage, > Keith (Keith) > Sent: 4. tammikuuta 2004 2:58 > To: Elwell, John; SIP@ietf.org > Subject: RE: [Sip] Use of P-Asserted-Identity in a response > > > RFC 3325 section 9.1 and section 9.2 both extend table 2 of > RFC 3261 with the new header. > > Both entires leave the "where" column empty. > > The key to RFC 3261 table 2 states: > > An empty entry in the "where" column indicates that the header > field may be present in all requests and responses. > > I would therefore conclude from the existing specification > that both headers may appear in any response to BYE, INV, > OPT, SUB, NOT, REF, i.e. those methods that either create a > dialog, or are used outside a dialog. > > As MESSAGE appeared after RFC 3325 I would also assume that > it is allowed in the MESSAGE method, in both requests and all > responses. > > Note that these tables do not restrict it to 18x and 2xx > responses, although for ISDN mapping purposes those responses > are the useful ones. It is perfectly valid in 3xx, 4xx and > 5xx responses. > > Any assertion of identity in responses (and its value) is of > course dependent on the specification of privacy by the UAS > and on the requirements of the first proxy in the trust domain. > > This usage corresponds to what has been specified in 3GPP TS > 24.229 and I believe in ITU-T Q.1912.5. > > regards > > Keith > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 02 January 2004 16:11 > > To: SIP@ietf.org > > Subject: [Sip] Use of P-Asserted-Identity in a response > > > > > > There seem to be some differences of opinion concerning the use of > > P-Asserted-Identity (PAI) in a response. In particular, this > > is delaying the > > progress of draft-ietf-sipping-qsig2sip, which makes use of > > PAI in a 200 OK > > to convey the connected party identity received from the QSIG > > network. The > > same situation is likely to be encountered when interworking > > with other > > legacy signalling systems. > > > > It is my opinion that PAI can be used in a 200 OK to assert > > the identity of > > the connect party. Moreover, it can be inserted by a gateway > > UAS and, unless > > subject to privacy, can be passed on even to untrusted > > entities including > > the UAC. > > > > My evidence for assuming this is as follows: > > > > 1. RFC 3325: In section 5, 2nd paragraph it states: > > "If the proxy receives a message (request or response) from a > > node that it > > trusts, it can use the information in the P-Asserted-Identity > > header field, > > if any, as if it had authenticated the user itself." > > There is nowhere that forbids the use of P-Asserted-ID in a > response, > > although there are places in the RFC that mention procedures > > for a request > > without mentioning a response. In many places it talks about > > "message", > > which, according to the text above, means request or response. > > > > 2. RFC 3324 clause 5 clearly states that PAI in INVITE > identifies the > > calling user, PAI in a 180 response the ringing user and PAI > > in 200 OK the > > user who answered the call. RFC 3325 is supposed to meet the > > requirement of > > RFC3324. > > > > I have seen a number of arguments against the use of PAI in a > > response: > > > > a) It has been suggested that a PAI in a response represents > > the identity of > > the entity that issued the request. This does not hold water. > > It clearly > > would be in contradiction to clause 5 of RFC3324 and there is > > nowhere in > > RFC3324 or RFC3325 that suggests echoing in a response the > PAI in the > > request. > > > > b)It has been suggested that there would need to be > > corresponding privacy > > requirements for identity information in a response. However, > > RFC 3323 does > > indeed address privacy in responses. See last paragraph of > section 3: > > "It may be desirable to restrict identity information on both > > requests and > > responses. Initially, it might seem unusual to suggest that > > a response has > > privacy concerns - presumably, the originator of the request > > knows who they > > were attempting to contact, so the identity of the respondent > > can hardly be > > confidential. However, some personal information in > > responses (such as the > > contact address at which the respondent is currently > > registered) is subject > > to privacy concerns and can be addressed by these mechanisms." > > Also see section 4.2, which states: > > "...this document defines a new SIP header, Privacy, that can > > be used to > > specify privacy handling for requests and responses." > > > > c)It has been argued that using PAI in a response may cause > > an existing > > implementation to do the wrong thing with respect to > privacy, e.g., if > > privacy is required by the caller, a proxy may apply this to > > the connected > > user's identity in the response as well. I don't think this > > is a likely > > scenario in view of RFC 3323's coverage of privacy in requests and > > responses. > > > > d)Also it has been suggested that an existing UAS may not > take care to > > request privacy in a response, not realising that a proxy > > might add a PAI. > > Again, since RFC 3323 covers privacy in both requests and > > responses, any UA > > implementation that supports privacy in requests should also > > support privacy > > in responses. > > > > e) It has been pointed out that a proxy cannot reject a > > response if the PAI > > is wrong. I don't believe this matters - it should be > > sufficient for the > > proxy just to strip out a PAI that is wrong. > > > > In conclusion, I see evidence that PAI can be used in a > > response to assert > > the ID of the connected party and no solid evidence to the contrary. > > > > John Elwell (john.elwell@siemens.com) > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 3 10:27:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04751 for ; Wed, 3 Mar 2004 10:27:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYHK-0005Ew-AE for sip-archive@odin.ietf.org; Wed, 03 Mar 2004 10:27:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23FRMwF020076 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 10:27:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYGz-0005CV-W5; Wed, 03 Mar 2004 10:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYGe-0005BF-VQ for sip@optimus.ietf.org; Wed, 03 Mar 2004 10:26:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04622 for ; Wed, 3 Mar 2004 10:26:37 -0500 (EST) From: Matthew.Gardiner@aculab.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyYGc-0001N2-00 for sip@ietf.org; Wed, 03 Mar 2004 10:26:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyYFg-0001Bu-00 for sip@ietf.org; Wed, 03 Mar 2004 10:25:41 -0500 Received: from [213.249.233.131] (helo=mx0.aculab.com) by ietf-mx with esmtp (Exim 4.12) id 1AyYEr-00011P-00 for sip@ietf.org; Wed, 03 Mar 2004 10:24:49 -0500 Received: from localhost (io.aculab.com [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id CED51403A for ; Wed, 3 Mar 2004 15:33:20 +0000 (GMT) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23933-07 for ; Wed, 3 Mar 2004 15:33:17 +0000 (GMT) Received: from saturn.aculab.com (unknown [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 27DCD4010 for ; Wed, 3 Mar 2004 15:33:17 +0000 (GMT) Received: by saturn.aculab.com with Internet Mail Service (5.5.2655.55) id ; Wed, 3 Mar 2004 15:24:51 -0000 Message-ID: <8C9A566C643ED6119E8900A0C9DE297A01F864A9@saturn.aculab.com> To: sip@ietf.org Date: Wed, 3 Mar 2004 15:24:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40133.ABA0F9B0" X-Aculab-Com-Scanned: by amavisd-new-20030616-p7 (Debian) at aculab.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,CLICK_BELOW,HTML_30_40, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Typo in RFC 3261 - regarding REGISTER processing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C40133.ABA0F9B0 Content-Type: text/plain; charset="iso-8859-1" Page 66 details how a registrar should process a REGISTER message, in particular:- "Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar." However, inspection of the registration example on page 214 shows a 200OK without an expires parameter, it has an Expires header instead. Which of these is correct? I really do want to do the minimum amount of parsing in my app. Matthew Gardiner Software Engineer Aculab Tel: +44 (0) 1908 273 911 Fax: +44 (0) 1908 273 801 Email: mailto:matthew.gardiner@aculab.com Website: For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. ------_=_NextPart_001_01C40133.ABA0F9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Typo in RFC 3261 - regarding REGISTER processing

Page 66 details how a registrar should process a = REGISTER message, in particular:-

"Each Contact value MUST feature an = "expires" parameter indicating its expiration interval chosen = by the registrar."

However, inspection of the registration example on = page 214 shows a 200OK without an expires parameter, it has an Expires = header instead.

Which of these is correct? I really do want to do the = minimum amount of parsing in my app.


Matthew Gardiner
Software Engineer
Aculab
Tel: +44 (0) 1908 273 911
Fax: +44 (0) 1908 273 801
Email: mailto:matthew.gardiner@acul= ab.com
Website: <http://www.aculab.com>



For Aculab's privacy policy and E-Mail disclaimer, = Click Here : http://www.aculab.com/company/legal_notice.htm. =


------_=_NextPart_001_01C40133.ABA0F9B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 3 12:45:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13336 for ; Wed, 3 Mar 2004 12:45:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaQs-0001D6-QQ for sip-archive@odin.ietf.org; Wed, 03 Mar 2004 12:45:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23HjMth004588 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 12:45:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaQZ-0001Af-Vg; Wed, 03 Mar 2004 12:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaQD-00019h-Q7 for sip@optimus.ietf.org; Wed, 03 Mar 2004 12:44:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13307 for ; Wed, 3 Mar 2004 12:44:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyaQC-00059E-00 for sip@ietf.org; Wed, 03 Mar 2004 12:44:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyaPI-00050v-00 for sip@ietf.org; Wed, 03 Mar 2004 12:43:44 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AyaOh-0004rZ-00 for sip@ietf.org; Wed, 03 Mar 2004 12:43:07 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 03 Mar 2004 09:46:37 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i23HgZxU006208; Wed, 3 Mar 2004 12:42:35 -0500 (EST) Received: from cisco.com (tokyo-vpn-user50.cisco.com [10.70.82.50]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM41193; Wed, 3 Mar 2004 12:42:32 -0500 (EST) Message-ID: <40461907.4080007@cisco.com> Date: Wed, 03 Mar 2004 12:42:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew.Gardiner@aculab.com CC: sip@ietf.org Subject: Re: [Sip] Typo in RFC 3261 - regarding REGISTER processing References: <8C9A566C643ED6119E8900A0C9DE297A01F864A9@saturn.aculab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Matthew, Response below. Paul Matthew.Gardiner@aculab.com wrote: > Page 66 details how a registrar should process a REGISTER message, in > particular:- > > "Each Contact value MUST feature an "expires" parameter indicating its > expiration interval chosen by the registrar." > > However, inspection of the registration example on page 214 shows a > 200OK without an expires parameter, it has an Expires header instead. > > Which of these is correct? I really do want to do the minimum amount of > parsing in my app. I have always thought that MUST to be a bit excessive. In a REGISTER request, the Expires header provides a default that may be overridden in each Contact. AFAIK there is no particular reason, other than this arbitrary restriction, why the same shouldn't be true in responses. The example seems to provide some ammunition for my point of view. But as things stand I agree with you that there is a small bug in the spec. Based on the language you quote you would be justified in considering a response without an expires in the Contact as an error. OTOH, you have no way to report the error, so you need to do the best you can if it occurs. The best thing to do would probably be to handle it the same as in a request. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 3 15:01:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22033 for ; Wed, 3 Mar 2004 15:01:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AycYN-0006o9-Oc for sip-archive@odin.ietf.org; Wed, 03 Mar 2004 15:01:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23K1Fc3026166 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 15:01:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AycYB-0006hD-9M; Wed, 03 Mar 2004 15:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AycY2-0006eh-HE for sip@optimus.ietf.org; Wed, 03 Mar 2004 15:00:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21973 for ; Wed, 3 Mar 2004 15:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AycXz-0000h3-00 for sip@ietf.org; Wed, 03 Mar 2004 15:00:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AycX3-0000TV-00 for sip@ietf.org; Wed, 03 Mar 2004 14:59:54 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1AycW5-00003s-00 for sip@ietf.org; Wed, 03 Mar 2004 14:58:53 -0500 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i23JwIA07074; Wed, 3 Mar 2004 14:58:18 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FS3RJVCT; Wed, 3 Mar 2004 14:58:00 -0500 Received: from nortelnetworks.com (acart00w.ca.nortel.com [47.130.16.21]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJNJ9; Wed, 3 Mar 2004 14:57:59 -0500 Message-ID: <404638C5.60002@nortelnetworks.com> Date: Wed, 03 Mar 2004 20:57:57 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Gonzalo Camarillo , "Christer Holmberg (JO/LMF)" , sip , Rohan Mahy , Dean Willis Subject: Re: [Sip] Re: INFO Documentation (was Re: Defining new requests) References: <4035F586.1000405@ericsson.com> <403A4FA6.8040407@nortelnetworks.com> <403AFE24.9020504@ericsson.com> <403CFEAD.3050300@nortelnetworks.com> <403DE5D9.3020507@ericsson.com> <403DEDD9.60704@nortelnetworks.com> In-Reply-To: <403DEDD9.60704@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Latest word: we realized our annex really constituted a modification of SIP, something the ITU-T doesn't intend to do. We've deleted it and are living with the consequences in terms of out-of-date dependencies on RFC 2543. Taylor, Tom-PT [CAR:5N00:EXCH] wrote: > As a first step, I'll submit the Q.1912.5 annex as an I-D. I expect > we'll correct it to use UPDATE rather than BYE as the model in Geneva in > the next couple of weeks, so what I submit will reflect that. > > Gonzalo Camarillo wrote: > >> Tom. >> >> it seems that what you want is an update of the INFO spec, rather than >> fixing a few errata. I believe that we cannot meet your timeframe. In >> any event, it would be great we could start working on a solution for >> INFO in SIPPING, so that the ITU could reference it in the future. >> >> Thanks, >> >> Gonzalo >> >> Tom Taylor wrote: >> >>> Q.1912.5 is in the process of final approval. Logging errata may be >>> satisfactory -- I'd have to check. It would certainly be more >>> comfortable than reproducing the RFC with modifications in the ITU >>> document. If the IETF acts within the next two weeks we should be >>> able to remove the Annex from the Recommendation. >>> >>> Here is the current list of changes as reported at the beginning of >>> the Annex. >>> >>> "The SIP INFO method is documented in RFC 2976. However, that RFC >>> refers to RFC 2543, the previous version of the SIP specification, >>> rather than to RFC 3261. The text of this Annex reproduces RFC 2976 >>> with changes to reflect the updated reference. >>> >>> "The changes made are as follows: >>> >>> "Paragraph C.3.2.1: The references to the tables of RFC2543 were >>> changed to reflect the new table organization in RFC 3261. >>> >>> "Paragraph C.3.2: The tables 1 and 2 were replaced by new tables that >>> show the header fields defined as presented in RFC3261. All >>> additional headers (additional to RFC 2543) used within RFC3261 were >>> here set to optional with two exceptions. The Reply-To (only optional >>> for the INVITE) and Call-Info Header (only used for INVITE, OPTIONS, >>> REGISTER to give additional information about the caller or callee) >>> are not used with the INFO method. >>> >>> "Paragraph C.3.6: The reference was changed to the current SIP >>> specification, RFC 3261. >>> >>> >>> Gonzalo Camarillo wrote: >>> >>>> Tom, >>>> >>>> what is the timeframe here? As you know, we have had discussions in >>>> the past about either re-defining INFO so that it can only carry >>>> PSTN telephony signalling, or defining INFO packages. We could >>>> re-start those discussions, and once we reach a conclusion, clarify >>>> the rules to send INFO from the UAS within early dialogs in the same >>>> spec... >>>> >>>> If the ITU is in a hurry, other solutions may be better, like >>>> logging an errata against the INFO RFC. >>>> >>>> Gonzalo >>>> >>>> Tom Taylor wrote: >>>> >>>>> The ITU-T (Study Group 11, to be exact) had a different issue with >>>>> INFO: that the RFC depends on RFC 2543 rather than 3261. As a >>>>> result, they picked up the content of RFC 2976 as Annex C.3 of the >>>>> ISUP interworking specification Q.1912.5. If RFC 2976 ever gets >>>>> updated Annex C.3 can be deprecated. In the meantime, this INFO >>>>> question means we have some maintenance to perform. I think the >>>>> best solution will be to take Gonzalo's suggestion and say that >>>>> INFO follows the rules for UPDATE. We already have a normative >>>>> dependency on the UPDATE RFC. >>>>> >>>>> Gonzalo Camarillo wrote: >>>>> >>>>>> Christer, >>>>>> >>>>>> would the ITU-T be happier if we log an errata against the INFO >>>>>> RFC saying that UASs can send INFO within early dialogs? >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> Christer Holmberg (JO/LMF) wrote: >>>>>> >>>>>>> Hi Gonzalo, >>>>>>> >>>>>>> Thanks for your reply! >>>>>>> >>>>>>> >>>>>>>> it seems that some people in the ITU-T are having some issues >>>>>>>> figuring out whether or not certain requests can be sent by the UAS >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> within an >>>>>>> >>>>>>>> early dialog. The confusion comes from statements like this one >>>>>>>> (taken from the INFO spec): >>>>>>>> >>>>>>>> " Unless stated otherwise, the protocol rules for the INFO >>>>>>>> request >>>>>>>> governing the usage of tags, Route and Record-Route, >>>>>>>> retransmission and reliability, CSeq incrementing and message >>>>>>>> formatting follow those in [1] as defined for the BYE >>>>>>>> request." >>>>>>>> >>>>>>>> Since a UAS does not send BYEs within an early dialog, but a >>>>>>>> non-2xx final response instead, to terminate the dialog, people >>>>>>>> assume that >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> INFO >>>>>>> >>>>>>>> cannot be sent in this situation either. >>>>>>>> >>>>>>>> Let's try to keep this in mind and clarify this point when/if we >>>>>>>> define new SIP methods. >>>>>>>> >>>>>>>> In any event, the clarification to this issue can be found in >>>>>>>> RFC 3398: >>>>>>>> >>>>>>>> "From the callee to the caller, if a message is received by a >>>>>>>> gateway >>>>>>>> before the call has been answered (i.e., ANM is received) it >>>>>>>> SHOULD be encapsulated in an INFO, provided that this will not >>>>>>>> be the first SIP message sent in the backwards direction (in >>>>>>>> which case it SHOULD be encapsulated in a provisional 1xx >>>>>>>> response)." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The problem is that the ITU-T interworking spec doesn't reference >>>>>>> RFC3398. The spec reference the INFO RFC, and that is also where >>>>>>> I think >>>>>>> the usage rules should be defined (not in another spec, RFC3398 >>>>>>> in this >>>>>>> case, simply using the method). >>>>>>> >>>>>>> The INFO RFC, as you said, currently says that INFO "follows the >>>>>>> rules >>>>>>> of BYE" (whatever that means is another question :), and the >>>>>>> rules for >>>>>>> BYE specifically says that it must not be sent backward before the >>>>>>> INVITE has finished. If the INFO RFC would say "follow the rules of >>>>>>> UPDATE" we would not have this problem, since the UPDATE spec >>>>>>> specifically allows the use of the method before the INVITE has >>>>>>> finished. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Christer Holmberg >>>>>>> Ericsson Finland >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> This communication is confidential and intended solely for the >>>> addressee(s). Any unauthorized review, use, disclosure or >>>> distribution is prohibited. If you believe this message has been >>>> sent to you in error, please notify the sender by replying to this >>>> transmission and delete the message without disclosing it. Thank you. >>>> >>>> E-mail including attachments is susceptible to data corruption, >>>> interruption, unauthorized amendment, tampering and viruses, and we >>>> only send and receive e-mails on the basis that we are not liable >>>> for any such corruption, interception, amendment, tampering or >>>> viruses or any consequences thereof. >>>> >>>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 3 21:20:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16820 for ; Wed, 3 Mar 2004 21:20:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiTJ-00055d-Uh for sip-archive@odin.ietf.org; Wed, 03 Mar 2004 21:20:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242KPGp019560 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 21:20:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiSz-00053m-Fx; Wed, 03 Mar 2004 21:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiS5-00051d-Ss for sip@optimus.ietf.org; Wed, 03 Mar 2004 21:19:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16760 for ; Wed, 3 Mar 2004 21:19:07 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiS3-0000om-00 for sip@ietf.org; Wed, 03 Mar 2004 21:19:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiRE-0000f8-00 for sip@ietf.org; Wed, 03 Mar 2004 21:18:17 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AyiQp-0000U6-00 for sip@ietf.org; Wed, 03 Mar 2004 21:17:51 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i242HZh28275; Thu, 4 Mar 2004 04:17:36 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 04:15:56 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i242FuaJ008890; Thu, 4 Mar 2004 04:15:56 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Cuz9Sd; Thu, 04 Mar 2004 04:15:54 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i242Fr706878; Thu, 4 Mar 2004 04:15:53 +0200 (EET) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 04:15:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4018E.9E9D83C2" Subject: RE: [Sip] Typo in RFC 3261 - regarding REGISTER processing Date: Thu, 4 Mar 2004 04:15:53 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797831@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Typo in RFC 3261 - regarding REGISTER processing Thread-Index: AcQBNFI1fCeeHxwnR1ei2Si03J2yMQAWhA6g To: , X-OriginalArrivalTime: 04 Mar 2004 02:15:53.0875 (UTC) FILETIME=[9F0ED630:01C4018E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,CLICK_BELOW,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C4018E.9E9D83C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In RFC3261, Expires header in a 200 of a REGISTER has no meaning. The = contact header must contain the expires parameter. If that is not so in = the flow, then there is a bug in the flow. =20 Now, if you want to be backwards compatible with RFC2543, I suggest that = your UA accepts such responses and handles them appropriately. =20 /Hisham -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext = Matthew.Gardiner@aculab.com Sent: 03.March.2004 17:25 To: sip@ietf.org Subject: [Sip] Typo in RFC 3261 - regarding REGISTER processing Page 66 details how a registrar should process a REGISTER message, in = particular:-=20 "Each Contact value MUST feature an "expires" parameter indicating its = expiration interval chosen by the registrar."=20 However, inspection of the registration example on page 214 shows a = 200OK without an expires parameter, it has an Expires header instead.=20 Which of these is correct? I really do want to do the minimum amount of = parsing in my app.=20 Matthew Gardiner=20 Software Engineer=20 Aculab=20 Tel: +44 (0) 1908 273 911=20 Fax: +44 (0) 1908 273 801=20 Email: mailto:matthew.gardiner@aculab.com=20 Website: < http://www.aculab.com>=20 For Aculab's privacy policy and E-Mail disclaimer, Click Here : = http://www.aculab.com/company/legal_notice.htm.=20 ------_=_NextPart_001_01C4018E.9E9D83C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Typo in RFC 3261 - regarding REGISTER processing
In=20 RFC3261, Expires header in a 200 of a REGISTER has no meaning. The = contact=20 header must contain the expires parameter. If that is not so in the = flow, then=20 there is a bug in the flow.
 
Now,=20 if you want to be backwards compatible with RFC2543, I suggest that your = UA=20 accepts such responses and handles them = appropriately.
 
/Hisham
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of ext=20 Matthew.Gardiner@aculab.com
Sent: 03.March.2004 = 17:25
To:=20 sip@ietf.org
Subject: [Sip] Typo in RFC 3261 - regarding = REGISTER=20 processing

Page 66 details how a registrar should process a = REGISTER=20 message, in particular:-

"Each Contact value MUST feature an "expires" = parameter=20 indicating its expiration interval chosen by the registrar." =

However, inspection of the registration example on = page 214=20 shows a 200OK without an expires parameter, it has an Expires header = instead.=20

Which of these is correct? I really do want to do = the minimum=20 amount of parsing in my app.


Matthew Gardiner
Software=20 Engineer
Aculab
Tel: +44 (0)=20 1908 273 911
Fax: +44 (0) 1908 273 = 801=20
Email: mailto:matthew.gardiner@acula= b.com=20
Website: <http://www.aculab.com>



For Aculab's privacy policy and E-Mail = disclaimer, Click=20 Here : http://www.aculab.com/company/legal_notice.htm.=20


------_=_NextPart_001_01C4018E.9E9D83C2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 3 23:39:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26041 for ; Wed, 3 Mar 2004 23:39:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykdj-0005P4-EN for sip-archive@odin.ietf.org; Wed, 03 Mar 2004 23:39:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i244dJvN020707 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 23:39:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykdR-0005MO-FA; Wed, 03 Mar 2004 23:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axjmt-0006Io-Bk for sip@optimus.ietf.org; Mon, 01 Mar 2004 04:32:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04987 for ; Mon, 1 Mar 2004 04:32:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axjmq-0004Hb-00 for sip@ietf.org; Mon, 01 Mar 2004 04:32:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axjm0-0004A9-00 for sip@ietf.org; Mon, 01 Mar 2004 04:31:40 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly02b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1Axjl5-0003y5-00 for sip@ietf.org; Mon, 01 Mar 2004 04:30:43 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly02b.srv.mailcontrol.com (MailControl) with SMTP id i219Tk4S004691; Mon, 1 Mar 2004 09:30:02 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Mon, 1 Mar 2004 09:29:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Sip] From Port Date: Mon, 1 Mar 2004 07:06:57 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B1C5@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] From Port Thread-Index: AcP+lKrXn17YCsq9ReSsuuAoHO2nSwAxvDv0 From: "Chris Boulton" To: "Cullen Jennings" , "Anil Bollineni" , X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 DQpUaGUgRnJvbSBkb2VzIG5vdCBoYXZlIHRvIGNvbnRhaW4gYW55dGhpbmcg dXNlZnVsIGF0IGFsbC4gSW4gZ2VuZXJhbCBpdCBzaG91bGQgaGF2ZSBzb21l dGhpbmcgdGhhdCBpcyBtb3JlIGxpa2UgdGhlIGFkZHJlc3Mgb2YgcmVjb3Jk IGZvciB0aGUgdXNlciBpbnN0ZWFkIG9mIHRoZSB0aGUgSVAgYWRkcmVzcyBh bmQgcG9ydCB0aGF0IGNhbiBiZSB1c2VkIHRvIHJlYWNoIHRoZSBkZXZpY2Uu IFRoZSBjb250YWN0IGlzIHVzZWQgdG8gcmVhY2ggdGhlIGRldmljZS4gU28g bWluZSBtaWtlIGxvb2sgbGlrZSANCg0KRnJvbTog4oCcQ3VsbGVuIEplbm5p bmdz4oCdIDxzaXA6Zmx1ZmZ5QGNpc2NvLmNvbT4NCg0KSWYgdGhlIG9ubHkg d2F5IHRvIHJlYWNoIHRoZSBwcm94eSB3YXMgb24gcG9ydCAxMjM0IHRoZW4g SSBtaWdodCBoYXZlIHRvIGluY2x1ZGUgdGhhdCBpbiBteSBBT1IgYnV0IEkg d291bGQgdXN1YWxseSBub3QgcHV0IHRoZSBwb3J0IHRoYXQgdGhlIFVBIHdh cyB1c2luZyBpbiB0aGUgZnJvbS4gDQogDQo8PENKQj4+IExldHMgcmVtZW1i ZXIgdGhhdCBhIHBvcnQgaXMgbm90IGFsbG93ZWQgdG8gYXBwZWFyIG9uIGEg RnJvbSBoZWFkZXIgKGFuZCBUbykuDQogDQpDaHJpcy4NCg0KDQpPbiAyLzIw LzA0IDE6MDAgUE0sICJBbmlsIEJvbGxpbmVuaSIgPEFCb2xsaW5lbmlAbmV0 c2NyZWVuLmNvbT4gd3JvdGU6DQoNCg0KDQoJCUhpIEFsbCwNCgkJICAgICAg ICAgICAgRm9yIGFueSBTSVAgbWVzc2FnZSwgaWYgVUEgb3IgUHJveHkgc2Vu ZGluZyBtZXNzYWdlIHRoYW4gb3RoZXIgdGhhbiBmcm9tIHBvcnQgNTA2MCwg dGhlbiBpdCBzaG91bGQgYmUgaW5jbHVkZWQgaW4gU0lQIGZyb20gVVJJLiBG b3IgZXhhbXBsZSwgaWYgdGhlIFJlZ2lzdGVyIG1lc3NhZ2UgY29tZXMgZnJv bSAyMDIuMTAuMTAuMjA6MjIxOCwgdGhlIEZyb20gaGVhZGVyIHNob3VsZCBs b29rIGxpa2UgRnJvbTogc2lwOmpvZUAyMDIuMTAuMTAuMjA6MjIxOC4gSXMg aXQgTVVTVCBpZiB0aGUgcG9ydCBpcyBkaWZmZXJlbnQgdGhhbiBwb3J0IDUw NjAgdGhlbiBpdCBzaG91bGQgYXBwZWFyIGluIHRoZSBGcm9tIGhlYWRlcj8N CgkJIA0KCQlUaGFua3MgaW4gQWR2YW5jZSwNCgkJQW5pbA0KCQlUaGlzIGVt YWlsIGNvbnRhaW5zIG1hdGVyaWFsIHRoYXQgaXMgY29uZmlkZW50aWFsLiBU aGUgY29udGVudCBvZiB0aGlzIGVtYWlsIGlzIGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBk aXN0cmlidXRpb24gYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykgd2l0aG91dCB0aGUgZXhwcmVzcyBwZXJtaXNzaW9u IG9mIE5ldFNjcmVlbiBUZWNobm9sb2dpZXMsIEluYy4gaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlL2Rl c3Ryb3kgYWxsIGNvcGllcyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgcmVsYXRl ZCBhdHRhY2htZW50cy4gTmV0U2NyZWVuIGRvZXMgbm90IGd1YXJhbnRlZSB0 aGUgYWNjdXJhY3kgb3IgY29tcGxldGVuZXNzIG9mIHRoaXJkIHBhcnR5IG1h dGVyaWFscyBvciBpbmZvcm1hdGlvbi4NCgkJDQoJCQ0KCQkNCgkJDQoNCgkN CgkNCg0KCgpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBieSBNYWlsQ29udHJvbCAtIHd3dy5tYWlsY29udHJvbC5jb20K _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 4 14:06:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08038 for ; Thu, 4 Mar 2004 14:06:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyyAn-0003TP-DN for sip-archive@odin.ietf.org; Thu, 04 Mar 2004 14:06:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24J6Lae013350 for sip-archive@odin.ietf.org; Thu, 4 Mar 2004 14:06:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyyAU-0003Rv-4K; Thu, 04 Mar 2004 14:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyyAD-0003Qs-HI for sip@optimus.ietf.org; Thu, 04 Mar 2004 14:05:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07942 for ; Thu, 4 Mar 2004 14:05:42 -0500 (EST) From: akchaudhury@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyyAB-0004fF-00 for sip@ietf.org; Thu, 04 Mar 2004 14:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayy9D-0004TE-00 for sip@ietf.org; Thu, 04 Mar 2004 14:04:44 -0500 Received: from 210-210-93-99.lan.sify.net ([210.210.93.99] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayy8I-000443-00 for sip@ietf.org; Thu, 04 Mar 2004 14:03:46 -0500 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i24J22D18709 for ; Fri, 5 Mar 2004 00:32:16 +0530 Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 To: sip@ietf.org Date: Fri, 5 Mar 2004 00:32:45 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 03/05/2004 12:32:45 AM, Serialize complete at 03/05/2004 12:32:46 AM, Itemize by Notes Server on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 03/05/2004 12:32:46 AM, Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 03/05/2004 12:33:00 AM, Serialize complete at 03/05/2004 12:33:00 AM Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.7 required=5.0 tests=HTML_30_40,HTML_MESSAGE, HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Request Forwarding based on local policy. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable
Hi
 
As per point no. 6 of section 16.= 6 of rfc 3261 -
"A proxy MAY have a local policy that mandates th= at a request visit a specific set of proxies before being delivered to the = destination. A proxy MUST ensure that all such proxies are loose routers...= ."
 
If a proxy has to ensure (it is a MUST) that = all the proxies has to be loose routers, then how will the forwarding work = when one of the proxies is 2543 compliant and does not understand loose rou= ting ?
Does it mean that this kind of forwarding (based on local policy)= cannot/should not be done if one or more of the proxies in the path a= re 2543 compliant ?
 
Would really appreciate of s= omeone can clarify this.
 
thanks,
 = ;
Anil Kumar Chaudhury
Hughes Software Systems
http://www.hssworld.com
 
= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 5 13:36:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21820 for ; Fri, 5 Mar 2004 13:36:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzKBI-00051W-S1 for sip-archive@odin.ietf.org; Fri, 05 Mar 2004 13:36:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25IaKrD019247 for sip-archive@odin.ietf.org; Fri, 5 Mar 2004 13:36:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzKB0-0004z3-4s; Fri, 05 Mar 2004 13:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzKAp-0004y2-Bd for sip@optimus.ietf.org; Fri, 05 Mar 2004 13:35:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21773 for ; Fri, 5 Mar 2004 13:35:47 -0500 (EST) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzKAl-0000AO-00 for sip@ietf.org; Fri, 05 Mar 2004 13:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzK9g-0007kE-00 for sip@ietf.org; Fri, 05 Mar 2004 13:34:41 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1AzK8g-0007M9-00 for sip@ietf.org; Fri, 05 Mar 2004 13:33:39 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i25IX4wl027687 for ; Sat, 6 Mar 2004 00:03:05 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Sat, 06 Mar 2004 00:04:27 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Mar 2004 00:03:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C402E0.4AF6FC9B" Subject: RE: [Sip] Request Forwarding based on local policy. Date: Sat, 6 Mar 2004 00:03:02 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEAD0102FD54@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] Request Forwarding based on local policy. Thread-Index: AcQCG99D25Uq029pSi+P7zBG+9SR4QAwxTVg To: , X-OriginalArrivalTime: 05 Mar 2004 18:33:02.0749 (UTC) FILETIME=[4B00CCD0:01C402E0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C402E0.4AF6FC9B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Thanks & Regards, Nataraju A.B.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of akchaudhury@hss.hns.com Sent: Friday, March 05, 2004 12:33 AM To: sip@ietf.org Subject: [Sip] Request Forwarding based on local policy. =20 Hi =20 As per point no. 6 of section 16.6 of rfc 3261 - "A proxy MAY have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination. A proxy MUST ensure that all such proxies are loose routers...." =20 If a proxy has to ensure (it is a MUST) that all the proxies has to be loose routers, then how will the forwarding work when one of the proxies is 2543 compliant and does not understand loose routing ? Does it mean that this kind of forwarding (based on local policy) cannot/should not be done if one or more of the proxies in the path are 2543 compliant ? =20 [ABN] I guess it MUST have been phrased as the set of proxies, the proxy X intended to be visited and their type (lr or not) not always necessarily loose routers.=20 =20 Please correct me if I am missing something... =20 Would really appreciate of someone can clarify this. =20 thanks, =20 Anil Kumar Chaudhury Hughes Software Systems http://www.hssworld.com =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip=20 ------_=_NextPart_001_01C402E0.4AF6FC9B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Thanks & Regards,
Nataraju A.B.

-----Original = Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of akchaudhury@hss.hns.com
Sent: Friday, March 05, 2004 12:33 = AM
To: sip@ietf.org
Subject: [Sip] Request = Forwarding based on local policy.

 

Hi

 

As per point no. 6 of = section 16.6 of rfc 3261 -

"A proxy MAY have a = local policy that mandates that a request visit a specific set of proxies = before being delivered to the destination. A proxy MUST ensure that all such = proxies are loose routers...."

 

If a proxy has to ensure = (it is a MUST) that all the proxies has to be loose routers, then how will the forwarding work when one of the proxies is 2543 compliant and does not understand loose routing ?
Does it mean that this kind of forwarding (based on local policy) = cannot/should not be done if one or more of the proxies in the path are 2543 = compliant ?

 

[ABN] I guess it MUST have been phrased as the set of = proxies, the proxy X intended to be visited and their type (lr or not) not always = necessarily loose routers.

 

Please correct me if I am missing = something…

 

Would really appreciate = of someone can clarify this.

 

thanks,

 

Anil Kumar = Chaudhury

Hughes Software = Systems

 

______________________________________________= _ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for = NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on = the application of sip

------_=_NextPart_001_01C402E0.4AF6FC9B-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 5 14:51:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25861 for ; Fri, 5 Mar 2004 14:51:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLLx-0007Mn-2Z for sip-archive@odin.ietf.org; Fri, 05 Mar 2004 14:51:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25JpPhf028253 for sip-archive@odin.ietf.org; Fri, 5 Mar 2004 14:51:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLLb-0007Cv-GU; Fri, 05 Mar 2004 14:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLLR-0007Be-FH for sip@optimus.ietf.org; Fri, 05 Mar 2004 14:50:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25806 for ; Fri, 5 Mar 2004 14:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzLLM-0007eR-00 for sip@ietf.org; Fri, 05 Mar 2004 14:50:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzLKU-0007T5-00 for sip@ietf.org; Fri, 05 Mar 2004 14:49:54 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AzLJa-00075k-00 for sip@ietf.org; Fri, 05 Mar 2004 14:48:59 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15149; Fri, 05 Mar 2004 14:48:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Binary Thoughts (was RE: [Sip] SIP Draft Minutes) Date: Fri, 5 Mar 2004 14:48:29 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A2D6@zoe.office.snowshore.com> Thread-Topic: [Sip] SIP Draft Minutes Thread-Index: AcP/85cZh5/tquCtSES8a/5ppxxSAAC9PBfA From: "Eric Burger" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable To be clear, binary ONLY. The SHOULD strength below, as I recall, was = rejected. Of course, one may always be liberal in what you accept, but = from a protocol point of view, binary is the only way to talk. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, March 01, 2004 8:09 PM To: sip@ietf.org Cc: mankin@psg.com; rohan@cisco.com Subject: [Sip] SIP Draft Minutes [snip] Culleng Jennings: Binary Encoding Bodies use content transfer encoding. 3261 gives no guidance on what = sort of encoding. Proposal to change it so say you SHOULD use binary, = but need to be able to receive any. Question: What about indirect content? Discussion indicates that indirect content woul be contyrolled by the = rules of whatever protocol and data format is being indirected to. Question: Do we have base64 in SIP specs we need to expunge?=20 Robert volunteered to help editors change examples to show binary = encoding, using scripts he used for the torture test draft. Question: Why couldn't this be on the list. No discussion, just muttering. Conclusion: Only binary, no requirement to receive non-binary. Will go = into errata in a prominent way. [snip] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Mar 7 23:39:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25254 for ; Sun, 7 Mar 2004 23:39:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0CY3-0000dd-B7 for sip-archive@odin.ietf.org; Sun, 07 Mar 2004 23:39:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i284dReC002378 for sip-archive@odin.ietf.org; Sun, 7 Mar 2004 23:39:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0CXd-0000YB-Js; Sun, 07 Mar 2004 23:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0CWt-0000Xg-23 for sip@optimus.ietf.org; Sun, 07 Mar 2004 23:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25235 for ; Sun, 7 Mar 2004 23:38:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0CWr-0003vr-00 for sip@ietf.org; Sun, 07 Mar 2004 23:38:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0CW1-0003no-00 for sip@ietf.org; Sun, 07 Mar 2004 23:37:21 -0500 Received: from [63.101.52.22] (helo=apollo.taqua.com) by ietf-mx with esmtp (Exim 4.12) id 1B0CVN-0003f3-00 for sip@ietf.org; Sun, 07 Mar 2004 23:36:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] changes in session timer Date: Sun, 7 Mar 2004 23:39:43 -0500 Message-ID: Thread-Topic: [Sip] changes in session timer Thread-Index: AcP/9udeue7JZMCPTUujKAo4VAyYtwEwKETQ From: "Bender, Andrew" To: "Dean Willis" , "Drage, Keith (Keith)" Cc: "Rosen, Brian" , "Jonathan Rosenberg" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable From a spiritual standpoint, I also have to disagree with the idea of = arbitrarily limiting Min-SE to some "high" value if the motivation is an = attempt to police or discourage misuse.=20 =20 I can attest that there are still practical deployments of session-timer = that are used more for supervision of control-plane or session liveness = than clearing of stale state; in most cases, this is a conscious = exchange between scale and resolution. Although I'm not thrilled by this = idea either, mandating 90s. (or anything else, really) seems to me like = unnecessary machinery to save us from a problem that is not yet = imminent.=20 On the matter of billing; I hope not to rekindle a well traveled debate, = but I'd like to invoke a comparison with the traditional circuit = switched / wireline world. There really isn't a precedent for any sort = of end-to-end bearer supervision in this realm, at least since the = advent of CCS signaling schemes for digital trunks. A large proportion = of the world's business oriented voice calling is now CCS all the way, = and here, the state of bearer will be completely implicit. In these = cases the "connect time", as it would be used for billing purposes, is = inferred from some state transition in call signaling... where sip would = be (is?) used in these applications, and without widespread use of RTCP = (et al) the same would have to be true.=20 Our experiences suggest that the sensitivities of carriers / users = regarding resolution of "connect time" seems to be in the range of 5s - = 60s depending on the network in question. Regards, Andrew Bender taqua.com -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, March 01, 2004 8:30 PM To: Drage, Keith (Keith) Cc: 'Rosen, Brian'; 'Jonathan Rosenberg'; 'sip@ietf.org' Subject: Re: [Sip] changes in session timer Drage, Keith (Keith) wrote: > Is charging considerations within the requirements for session timer. >=20 > There was considerable discussion of this issue a couple of years = back, and I thought that the charging use case was eliminated from the = requirements at that time. >=20 I'd like to respond with a complete lack of political consdieration=20 here, so I'm sorry if you're offended. Is billing in scope for Session Timer? In my humble opinion: "No, Hell=20 no, and what part of no did you not understand?" I believe that billing off the SIP signaling is a profoundly bad idea.=20 Accurate billing has to be closer to the bearer path. I think perhaps that Brian is suggesting that timeouts at the SIP layer=20 can be used to detect failures that affect the media path, or at least=20 failures for which there is no media path. While technically true, I=20 don't find the mechanism appropriate. Suggestions: 1) The media path is assumed to have real time delivery requirements.=20 Real-time is always going to be more accurate than the non-real-time=20 signaling path. If you need real-time billing, derive it from the=20 real-time media path. 2) If there is no real-time media path, I can't imagine what=20 time-sensitive service is being consumed that requires real-time=20 accuracy in accounting for. If you THINK you need real-time tracking=20 here, then perhaps a media channel that does NOTHING but report=20 connectivity for billing purposes is appropriate. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 8 10:46:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08889 for ; Mon, 8 Mar 2004 10:46:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mwe-000050-6O for sip-archive@odin.ietf.org; Mon, 08 Mar 2004 10:45:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28FjWGI032710 for sip-archive@odin.ietf.org; Mon, 8 Mar 2004 10:45:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0MwB-0008Tl-KQ; Mon, 08 Mar 2004 10:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mvz-0008S8-81 for sip@optimus.ietf.org; Mon, 08 Mar 2004 10:44:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08847 for ; Mon, 8 Mar 2004 10:44:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Mvw-0007jI-00 for sip@ietf.org; Mon, 08 Mar 2004 10:44:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0MvC-0007Yq-00 for sip@ietf.org; Mon, 08 Mar 2004 10:44:02 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1B0MuD-0007By-00 for sip@ietf.org; Mon, 08 Mar 2004 10:43:01 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i28FgLaZ028868; Mon, 8 Mar 2004 10:42:21 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27276; Mon, 8 Mar 2004 10:42:20 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Mar 2004 10:42:20 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B64A0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Bender, Andrew'" , Dean Willis , "Drage, Keith (Keith)" Cc: Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] changes in session timer Date: Mon, 8 Mar 2004 10:42:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Once again, let me state that I don't see Session Timer as directly used for billing, nor do I see ANY sip mechanism directly used for billing. I do think that the world is not perfect, things go wrong, and sometimes sessions will be torn down when there is a failure in the SIP level. Session Timer is one of the mechanisms that can be used to detect a failure of the SIP layer. When a session is torn down, billing is affected. The minimum time to detect a failure is reflected in a time period where the user may or may not have a connection, but is being billed for it. Having a 90 second period is a pretty long time if you are paying for it in 6 second increments. That's the ONLY implication I make between session timer and billing. Brian > -----Original Message----- > From: Bender, Andrew [mailto:abender@taqua.com] > Sent: Sunday, March 07, 2004 11:40 PM > To: Dean Willis; Drage, Keith (Keith) > Cc: Rosen, Brian; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] changes in session timer > > > From a spiritual standpoint, I also have to disagree with the > idea of arbitrarily limiting Min-SE to some "high" value if > the motivation is an attempt to police or discourage misuse. > > I can attest that there are still practical deployments of > session-timer that are used more for supervision of > control-plane or session liveness than clearing of stale > state; in most cases, this is a conscious exchange between > scale and resolution. Although I'm not thrilled by this idea > either, mandating 90s. (or anything else, really) seems to me > like unnecessary machinery to save us from a problem that is > not yet imminent. > > On the matter of billing; I hope not to rekindle a well > traveled debate, but I'd like to invoke a comparison with the > traditional circuit switched / wireline world. There really > isn't a precedent for any sort of end-to-end bearer > supervision in this realm, at least since the advent of CCS > signaling schemes for digital trunks. A large proportion of > the world's business oriented voice calling is now CCS all > the way, and here, the state of bearer will be completely > implicit. In these cases the "connect time", as it would be > used for billing purposes, is inferred from some state > transition in call signaling... where sip would be (is?) used > in these applications, and without widespread use of RTCP (et > al) the same would have to be true. > > Our experiences suggest that the sensitivities of carriers / > users regarding resolution of "connect time" seems to be in > the range of 5s - 60s depending on the network in question. > > Regards, > Andrew Bender > taqua.com > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, March 01, 2004 8:30 PM > To: Drage, Keith (Keith) > Cc: 'Rosen, Brian'; 'Jonathan Rosenberg'; 'sip@ietf.org' > Subject: Re: [Sip] changes in session timer > > > Drage, Keith (Keith) wrote: > > > Is charging considerations within the requirements for > session timer. > > > > There was considerable discussion of this issue a couple of > years back, and I thought that the charging use case was > eliminated from the requirements at that time. > > > > I'd like to respond with a complete lack of political consdieration > here, so I'm sorry if you're offended. > > Is billing in scope for Session Timer? In my humble opinion: > "No, Hell > no, and what part of no did you not understand?" > > I believe that billing off the SIP signaling is a profoundly > bad idea. > Accurate billing has to be closer to the bearer path. > > I think perhaps that Brian is suggesting that timeouts at the > SIP layer > can be used to detect failures that affect the media path, or > at least > failures for which there is no media path. While technically true, I > don't find the mechanism appropriate. > > Suggestions: > > 1) The media path is assumed to have real time delivery requirements. > Real-time is always going to be more accurate than the non-real-time > signaling path. If you need real-time billing, derive it from the > real-time media path. > > 2) If there is no real-time media path, I can't imagine what > time-sensitive service is being consumed that requires real-time > accuracy in accounting for. If you THINK you need real-time tracking > here, then perhaps a media channel that does NOTHING but report > connectivity for billing purposes is appropriate. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 8 18:01:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09185 for ; Mon, 8 Mar 2004 18:01:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TkM-0004Lb-M2 for sip-archive@odin.ietf.org; Mon, 08 Mar 2004 18:01:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28N1Iis016706 for sip-archive@odin.ietf.org; Mon, 8 Mar 2004 18:01:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Tk7-00048q-P6; Mon, 08 Mar 2004 18:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TjK-0003x3-QV for sip@optimus.ietf.org; Mon, 08 Mar 2004 18:00:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09099 for ; Mon, 8 Mar 2004 18:00:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TjH-00064L-00 for sip@ietf.org; Mon, 08 Mar 2004 18:00:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TiF-0005mv-00 for sip@ietf.org; Mon, 08 Mar 2004 17:59:08 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1B0TgX-00058g-00; Mon, 08 Mar 2004 17:57:21 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Mar 2004 14:56:48 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 8 Mar 2004 14:56:53 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Mar 2004 14:56:44 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Mar 2004 14:56:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Mon, 8 Mar 2004 14:56:34 -0800 Message-ID: Thread-Topic: How to express a GRUU property of a URI Thread-Index: AcQFYJruImVLdbYOSK259EjcxxFWUw== From: "Orit Levin" To: Cc: , X-OriginalArrivalTime: 08 Mar 2004 22:56:41.0188 (UTC) FILETIME=[9EC44A40:01C40560] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] How to express a GRUU property of a URI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40560.B99650C3" ------_=_NextPart_001_01C40560.B99650C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, Based on the last week comments, there is a requirement to optionally distinguish between information per user's AOR vs. per his/her GRUU(s) in XML documents (outside of SIP signaling messages). =20 Mentioned examples were Conference Package and Presence documents. (I suspect more usage cases are to come.) In my view, it is a matter of specific system implementation/architecture whether, when, and why you need to expose this information. (I do find it useful in some cases.) =20 Both presence documents and conference package are user-centric and (to the most parts) signaling-agnostic. I don't think it is wise to expand the existing XML schemas by doubling each URI placeholder to include signaling details, etc. I think it is more appropriate to define an optional URI parameter (e.g. "gruu") that can be appended to any SIP URI. By doing so, we can express the fact that a URI has GRUU properties without modifying existing XML schemas and without defining extended XML schemas in the future. =20 By doing so, it is up to the document provider to decide which level of granularity it wants to expose without making changes to existing XML schema. =20 What do you think? =20 Orit. PS: Please, reply to SIP list only. I just wanted to bring this question to the attention of SIMPLE and XCON communities in one shot. =20 =20 =20 =20 =20 ------_=_NextPart_001_01C40560.B99650C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Guys,
Based = on the last=20 week comments, there is a requirement to optionally distinguish=20 between information per user's AOR vs.=20 per his/her GRUU(s) in XML documents (outside of SIP signaling = messages).
 
Mentioned examples=20 were Conference Package and Presence documents. (I suspect more usage = cases are=20 to come.)
In my = view, it is a=20 matter of specific system implementation/architecture whether, when, and = why you=20 need to expose this information. (I do find it useful in some=20 cases.)
 
Both = presence=20 documents and conference package are user-centric and (to the most = parts)=20 signaling-agnostic. I don't think it is wise to expand the existing XML = schemas=20 by doubling each URI placeholder to include signaling details, etc. I = think it=20 is more appropriate to define an optional URI parameter (e.g. = "gruu") that=20 can be appended to any SIP URI. By doing so, we can express = the fact=20 that a URI has GRUU properties without modifying existing XML schemas = and=20 without defining extended XML schemas in the future.
 
By = doing so, it is=20 up to the document provider to decide which level of granularity it = wants to=20 expose without making changes to existing XML = schema.
 
What = do you=20 think?
 
Orit.
PS: = Please, reply to=20 SIP list only. I just wanted to bring this question to the attention of = SIMPLE=20 and XCON communities in one shot.
 
 
 
 
 
------_=_NextPart_001_01C40560.B99650C3-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 9 00:55:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24772 for ; Tue, 9 Mar 2004 00:55:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aD8-0006s7-H8 for sip-archive@odin.ietf.org; Tue, 09 Mar 2004 00:55:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i295tQtI026352 for sip-archive@odin.ietf.org; Tue, 9 Mar 2004 00:55:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aCm-0006p3-2h; Tue, 09 Mar 2004 00:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aC6-0006nZ-IQ for sip@optimus.ietf.org; Tue, 09 Mar 2004 00:54:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24753 for ; Tue, 9 Mar 2004 00:54:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0aC3-0001hW-00 for sip@ietf.org; Tue, 09 Mar 2004 00:54:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0aB8-0001Xf-00 for sip@ietf.org; Tue, 09 Mar 2004 00:53:23 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B0aAf-0001LY-00 for sip@ietf.org; Tue, 09 Mar 2004 00:52:53 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i295qTNr014683; Tue, 9 Mar 2004 00:52:32 -0500 (EST) Message-ID: <404D5B90.3070908@dynamicsoft.com> Date: Tue, 09 Mar 2004 00:52:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [XCON] How to express a GRUU property of a URI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Orit Levin wrote: > Guys, > Based on the last week comments, there is a requirement to optionally > distinguish between information per user's AOR vs. per his/her GRUU(s) > in XML documents (outside of SIP signaling messages). Sorry if I missed that - why is this a requirement? > > Mentioned examples were Conference Package and Presence documents. (I > suspect more usage cases are to come.) A presence document may need to carry a gruu as the contact URI, sure. However, I dont think that the fact that its a gruu needs to be known to the watcher. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 10 02:39:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24208 for ; Wed, 10 Mar 2004 02:39:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0yJL-00071r-6P for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 02:39:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A7dQgS026932 for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 02:39:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0yIx-0006sU-UE; Wed, 10 Mar 2004 02:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0yIL-0006hg-Cr for sip@optimus.ietf.org; Wed, 10 Mar 2004 02:38:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24151 for ; Wed, 10 Mar 2004 02:38:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0yIH-0006iS-00 for sip@ietf.org; Wed, 10 Mar 2004 02:38:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0yHR-0006Yd-00 for sip@ietf.org; Wed, 10 Mar 2004 02:37:29 -0500 Received: from exodus.cs.ccu.edu.tw ([140.123.103.6] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1B0yGd-0006F6-00 for sip@ietf.org; Wed, 10 Mar 2004 02:36:39 -0500 Received: from RayPeng (unknown [140.123.105.35]) by exodus.cs.ccu.edu.tw (Postfix) with ESMTP id 664FEB217 for ; Wed, 10 Mar 2004 15:36:28 +0800 (CST) Message-ID: <006901c40672$61fd11b0$7500a8c0@RayPeng> From: "Ray Peng" To: Subject: [Sip] SIP Extensions for Networked Appliances Date: Wed, 10 Mar 2004 15:36:21 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01C406B5.70110F70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C406B5.70110F70 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hello, Is there any draft or RFC about "SIP extensions for networked = appliances"?? I found "draft-tsang-sip-appliances-do-00.txt" and = "draft-moyer-sip-appliances-framework-03.txt", but they were all = deleted. Is there any draft or RFC about "Networked Appliances using SIP" ?? Best regards Jen-Ruie Peng ------=_NextPart_000_0066_01C406B5.70110F70 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hello,
         Is there any draft = or RFC=20 about "SIP extensions for networked appliances"??
    I found "draft-tsang-sip-appliances-do-00.txt" = and=20 "draft-moyer-sip-appliances-framework-03.txt", but they were all = deleted.
    Is there any draft or RFC about "Networked = Appliances=20 using SIP" ??
 
Best regards
Jen-Ruie Peng
------=_NextPart_000_0066_01C406B5.70110F70-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 10 03:43:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26503 for ; Wed, 10 Mar 2004 03:43:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zJH-0003VI-U6 for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 03:43:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A8hRiQ013405 for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 03:43:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zIt-0003SN-Ol; Wed, 10 Mar 2004 03:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zIQ-0003Od-Ae for sip@optimus.ietf.org; Wed, 10 Mar 2004 03:42:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26462 for ; Wed, 10 Mar 2004 03:42:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zIN-0001H8-00 for sip@ietf.org; Wed, 10 Mar 2004 03:42:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zHW-00014Y-00 for sip@ietf.org; Wed, 10 Mar 2004 03:41:38 -0500 Received: from [80.74.106.10] (helo=rvil-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1B0zGQ-0000qh-00 for sip@ietf.org; Wed, 10 Mar 2004 03:40:30 -0500 Received: from rvil-mail.radvision.com [172.20.2.102] by rvil-mail.radvision.com with XWall v3.28 ; Wed, 10 Mar 2004 10:42:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Mar 2004 10:42:05 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B1493BC@rvil-mail.radvision.com> Thread-Topic: Forking issue Thread-Index: AcQGe5DLUJ4TCtawTkqRzvZSplgRgA== From: "Sarit Galanos" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Forking issue Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, An Initial INVITE can be forked by a proxy and reach several user agent = servers. Now let say that the INVITE was forked and reached three UAS. The first UAS returned 180. The proxy passed this 180 to the client and = the client mapped it to the INVITE client transaction. An early dialog = was created. The second UAS also returned 180 with different tag. The proxy passed = this 180 to the client and the UAC. This response caused the creation of = a new early dialog. The third server return 400 without a provisional response first with a = new tag. After a while when there was no better response the proxy forwarded the = 400 to the client.=20 =20 My question is: How this 400 should be handled? It does not match any of = the early dialogs that we have.=20 Should the original Invite transaction send ACK for it? How will it = effect the two early dialogs that I do have. Thanks, Sarit. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 10 04:07:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27658 for ; Wed, 10 Mar 2004 04:07:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zgP-0005pV-3j for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 04:07:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A97K2O022401 for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 04:07:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zg8-0005mS-KR; Wed, 10 Mar 2004 04:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zfW-0005jy-AJ for sip@optimus.ietf.org; Wed, 10 Mar 2004 04:06:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27531 for ; Wed, 10 Mar 2004 04:06:24 -0500 (EST) From: Sunayak@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zfT-0005p8-00 for sip@ietf.org; Wed, 10 Mar 2004 04:06:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zeU-0005bc-00 for sip@ietf.org; Wed, 10 Mar 2004 04:05:23 -0500 Received: from [61.16.168.131] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1B0zcd-00058t-00; Wed, 10 Mar 2004 04:03:28 -0500 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i2A8xUD08541; Wed, 10 Mar 2004 14:29:40 +0530 In-Reply-To: <10DA2C035FE3BC4FA8D73EC55FC43D9B1493BC@rvil-mail.radvision.com> Subject: Re: [Sip] Forking issue To: "Sarit Galanos" Cc: sip@ietf.org, sip-admin@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 10 Mar 2004 14:28:42 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 03/10/2004 02:30:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Sarit, Yes, the client should ACK the 400 and terminate all its early dialogs. Ref: 13.2.2.3 of RFC: "All early dialogs are considered terminated upon reception of the non-2xx final response." Regards, Subhash Nayak Hughes Software Systems http://www.hssworld.com "Sarit Galanos" To Sent by: sip-admin@ietf.or cc g Subject [Sip] Forking issue 03/10/04 02:12 PM Hi, An Initial INVITE can be forked by a proxy and reach several user agent servers. Now let say that the INVITE was forked and reached three UAS. The first UAS returned 180. The proxy passed this 180 to the client and the client mapped it to the INVITE client transaction. An early dialog was created. The second UAS also returned 180 with different tag. The proxy passed this 180 to the client and the UAC. This response caused the creation of a new early dialog. The third server return 400 without a provisional response first with a new tag. After a while when there was no better response the proxy forwarded the 400 to the client. My question is: How this 400 should be handled? It does not match any of the early dialogs that we have. Should the original Invite transaction send ACK for it? How will it effect the two early dialogs that I do have. Thanks, Sarit. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 10 08:34:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07580 for ; Wed, 10 Mar 2004 08:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13qT-0002GY-TW for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 08:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ADY1bq008642 for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 08:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13pV-000253-AK; Wed, 10 Mar 2004 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13pF-00024M-5Q for sip@optimus.ietf.org; Wed, 10 Mar 2004 08:32:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07563 for ; Wed, 10 Mar 2004 08:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B13pD-0005T9-00 for sip@ietf.org; Wed, 10 Mar 2004 08:32:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B13oQ-0005Jk-00 for sip@ietf.org; Wed, 10 Mar 2004 08:31:55 -0500 Received: from tspsmtp8.sbc.com ([144.160.112.18]) by ietf-mx with esmtp (Exim 4.12) id 1B13nt-000574-00 for sip@ietf.org; Wed, 10 Mar 2004 08:31:21 -0500 Received: from sbc.com (localhost [127.0.0.1]) by tspsmtp8.sbc.com (8.12.10/8.12.10) with ESMTP id i2ADUdb2000421; Wed, 10 Mar 2004 07:30:40 -0600 (CST) Received: from msgdalhub02.ITServices.sbc.com (msgdalhub02.itservices.sbc.com [155.179.128.121]) by tspsmtp8.sbc.com (8.12.10/8.12.10) with ESMTP id i2ADUYXS000371; Wed, 10 Mar 2004 07:30:35 -0600 (CST) Received: by msgdalhub02.itservices.sbc.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 07:30:34 -0600 Message-ID: <30298C863F9ABF489775DE415473A80B01967C@txsna09msgusr03.itservices.sbc.com> From: "MULTACH, JEFF (SBC-OPS)" To: "'Ray Peng'" , sip@ietf.org Subject: RE: [Sip] SIP Extensions for Networked Appliances Date: Wed, 10 Mar 2004 07:30:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, NORMAL_HTTP_TO_IP autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Not sure but you could try asking Stan Moyer (stanm@research.telcordia.com, stanmoyer@yahoo.com or stanley.moyer@verizon.net). I believe the related web site for some of his material is www.argreenhouse.com (http://205.132.6.130/) and the papers are referenced in /papers/stanm. -----Original Message----- From: Ray Peng [mailto:raypeng@exodus.cs.ccu.edu.tw] Sent: Wednesday, March 10, 2004 1:36 AM To: sip@ietf.org Subject: [Sip] SIP Extensions for Networked Appliances Hello, Is there any draft or RFC about "SIP extensions for networked appliances"?? I found "draft-tsang-sip-appliances-do-00.txt" and "draft-moyer-sip-appliances-framework-03.txt", but they were all deleted. Is there any draft or RFC about "Networked Appliances using SIP" ?? Best regards Jen-Ruie Peng _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 10 08:35:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07656 for ; Wed, 10 Mar 2004 08:35:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13rd-0002Vz-Sb for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 08:35:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ADZDsj009603 for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 08:35:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13rT-0002MG-66; Wed, 10 Mar 2004 08:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13r1-0002H4-M1 for sip@optimus.ietf.org; Wed, 10 Mar 2004 08:34:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07608 for ; Wed, 10 Mar 2004 08:34:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B13r0-0005lS-00 for sip@ietf.org; Wed, 10 Mar 2004 08:34:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B13q5-0005cd-00 for sip@ietf.org; Wed, 10 Mar 2004 08:33:38 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1B13ph-0005Tm-00 for sip@ietf.org; Wed, 10 Mar 2004 08:33:13 -0500 Received: from bear.cs.columbia.edu (IDENT:9luF73e+2DtBRbgrILiiqMy9ZetsDkA4@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i2ADUEAf004452 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 10 Mar 2004 08:30:15 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-69-144.mad.east.verizon.net [138.89.69.144]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i2ADUDfG017204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Mar 2004 08:30:14 -0500 Message-ID: <404F1861.50206@cs.columbia.edu> Date: Wed, 10 Mar 2004 08:30:09 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Ray Peng CC: sip@ietf.org Subject: Re: [Sip] SIP Extensions for Networked Appliances References: <006901c40672$61fd11b0$7500a8c0@RayPeng> In-Reply-To: <006901c40672$61fd11b0$7500a8c0@RayPeng> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As far as I know, there has been no recent IETF work on this topic. Fortunately, not much extra standardization is needed to make this work; see http://dl.comsoc.org/cocoon/comsoc/servlets/GetPublication?id=1222947 for a recent article on this topic. Ray Peng wrote: > Hello, > Is there any draft or RFC about "SIP extensions for networked > appliances"?? > I found "draft-tsang-sip-appliances-do-00.txt" and > "draft-moyer-sip-appliances-framework-03.txt", but they were all deleted. > Is there any draft or RFC about "Networked Appliances using SIP" ?? > > Best regards > Jen-Ruie Peng _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 10 13:50:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25912 for ; Wed, 10 Mar 2004 13:50:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18mf-00022x-D9 for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 13:50:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AIoPxE007803 for sip-archive@odin.ietf.org; Wed, 10 Mar 2004 13:50:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18mL-0001ya-L4; Wed, 10 Mar 2004 13:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18m6-0001ww-FS for sip@optimus.ietf.org; Wed, 10 Mar 2004 13:49:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25813 for ; Wed, 10 Mar 2004 13:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18m4-0001MB-00 for sip@ietf.org; Wed, 10 Mar 2004 13:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18lC-0001Aq-00 for sip@ietf.org; Wed, 10 Mar 2004 13:48:55 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B18kI-0000qb-00 for sip@ietf.org; Wed, 10 Mar 2004 13:47:58 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2AIlRTN017450; Wed, 10 Mar 2004 12:47:27 -0600 (CST) Message-ID: <404F62BE.7060502@alcatel.com> Date: Wed, 10 Mar 2004 12:47:26 -0600 From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarit Galanos CC: sip@ietf.org Subject: Re: [Sip] Forking issue References: <10DA2C035FE3BC4FA8D73EC55FC43D9B1493BC@rvil-mail.radvision.com> In-Reply-To: <10DA2C035FE3BC4FA8D73EC55FC43D9B1493BC@rvil-mail.radvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit According to section 17.1.3 of rfc 3261, the responses will have the same branch-parameter in the topmost VIA, but vary in the To tag. The first response received that matches the branch parameter (in the top Via header field), and the method parameter (in the CSeq header field) of the request that created the transaction, will be used. The others will be viewed as re-transmits. Alex. Sarit Galanos wrote: >Hi, >An Initial INVITE can be forked by a proxy and reach several user agent servers. >Now let say that the INVITE was forked and reached three UAS. > >The first UAS returned 180. The proxy passed this 180 to the client and the client mapped it to the INVITE client transaction. An early dialog was created. > >The second UAS also returned 180 with different tag. The proxy passed this 180 to the client and the UAC. This response caused the creation of a new early dialog. > >The third server return 400 without a provisional response first with a new tag. > >After a while when there was no better response the proxy forwarded the 400 to the client. > >My question is: How this 400 should be handled? It does not match any of the early dialogs that we have. >Should the original Invite transaction send ACK for it? How will it effect the two early dialogs that I do have. > >Thanks, >Sarit. > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 11 00:54:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29533 for ; Thu, 11 Mar 2004 00:54:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1J8Y-0005zM-Lo for sip-archive@odin.ietf.org; Thu, 11 Mar 2004 00:53:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B5rgcG022955 for sip-archive@odin.ietf.org; Thu, 11 Mar 2004 00:53:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1J7v-0005v1-8t; Thu, 11 Mar 2004 00:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1J7i-0005tA-Jf for sip@optimus.ietf.org; Thu, 11 Mar 2004 00:52:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29402 for ; Thu, 11 Mar 2004 00:52:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1J7f-0005tL-00 for sip@ietf.org; Thu, 11 Mar 2004 00:52:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1J6b-0005c8-00 for sip@ietf.org; Thu, 11 Mar 2004 00:51:42 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B1J5C-000554-00 for sip@ietf.org; Thu, 11 Mar 2004 00:50:14 -0500 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2B5nbNr016535; Thu, 11 Mar 2004 00:49:37 -0500 (EST) Message-ID: <404FFDE6.8080606@dynamicsoft.com> Date: Thu, 11 Mar 2004 00:49:26 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akchaudhury@hss.hns.com CC: sip@ietf.org Subject: Re: [Sip] Request Forwarding based on local policy. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. akchaudhury@hss.hns.com wrote: > Hi > > As per point no. 6 of section 16.6 of rfc 3261 - > "A proxy MAY have a local policy that mandates that a request visit a > specific set of proxies before being delivered to the destination. A > proxy MUST ensure that all such proxies are loose routers...." > > If a proxy has to ensure (it is a MUST) that all the proxies has to be > loose routers, then how will the forwarding work when one of the proxies > is 2543 compliant and does not understand loose routing ? It won't. Thats why you cant do it. > Does it mean that this kind of forwarding (based on local policy) > cannot/should not be done if one or more of the proxies in the path are > 2543 compliant ? Correct. You can only put a URI in there if you know it was obtained from a proxy that is 3261 compliant. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 11 03:49:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19756 for ; Thu, 11 Mar 2004 03:49:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Lsc-000623-PD for sip-archive@odin.ietf.org; Thu, 11 Mar 2004 03:49:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B8nQ8G023186 for sip-archive@odin.ietf.org; Thu, 11 Mar 2004 03:49:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1LsD-0005zz-Mr; Thu, 11 Mar 2004 03:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Lra-0005uf-U6 for sip@optimus.ietf.org; Thu, 11 Mar 2004 03:48:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19683 for ; Thu, 11 Mar 2004 03:48:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1LrY-0001mB-00 for sip@ietf.org; Thu, 11 Mar 2004 03:48:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Lqd-0001cH-00 for sip@ietf.org; Thu, 11 Mar 2004 03:47:23 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B1Lps-0001T0-00 for sip@ietf.org; Thu, 11 Mar 2004 03:46:36 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2B8kaqY008527 for ; Thu, 11 Mar 2004 09:46:36 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Mar 2004 09:46:36 +0100 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF0KHVX; Thu, 11 Mar 2004 09:46:36 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.246]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EC72318A82; Thu, 11 Mar 2004 10:46:35 +0200 (EET) Message-ID: <4050276B.7040801@ericsson.com> Date: Thu, 11 Mar 2004 10:46:35 +0200 X-Sybari-Trust: bcecac33 2c4885b5 73569057 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip Cc: Dean Willis , Rohan Mahy , Jonathan Rosemberg , "'hisham.khartabil@nokia.com'" , Aki Niemi , Henning Schulzrinne Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2004 08:46:36.0496 (UTC) FILETIME=[5CD72D00:01C40745] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Registrying parameter values Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, during the SIP session, we got clear guidance from Allison that creating a new registry for parameter values would be unacceptable. Still, there is an easy way to, at least, register the references to those new values. The idea is that the registry of parameters contains the reference to the RFC defining the parameter *and* to any RFC extending the values that the parameter admits. For example, if I define a new compression scheme called "Mycompression" to be used as an alternative to SigComp (comp=sigcomg vs. comp=mycompression) in RFCxxxx, the registry would look like: Header Field Parameter Name Reference ____________________________________________________________ Via comp RFC 3486 RFC xxxx This way, we would not register the values themselves, but would provide references to all the relevant specs so that implementers could avoid collisions anyway. Does anybody have a problem with this? This requires a *mininal* change to the existing definition of the parameter registry. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 12 16:39:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20267 for ; Fri, 12 Mar 2004 16:39:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uNC-0003NM-HZ for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 16:39:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLdIsl012911 for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 16:39:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uMv-0003Jt-Ci; Fri, 12 Mar 2004 16:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uMe-0003JT-Ck for sip@optimus.ietf.org; Fri, 12 Mar 2004 16:38:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20245 for ; Fri, 12 Mar 2004 16:38:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uMc-0000xt-00 for sip@ietf.org; Fri, 12 Mar 2004 16:38:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uLj-0000wq-00 for sip@ietf.org; Fri, 12 Mar 2004 16:37:48 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B1uL0-0000tV-00 for sip@ietf.org; Fri, 12 Mar 2004 16:37:02 -0500 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2CLagNr017377 for ; Fri, 12 Mar 2004 16:36:42 -0500 (EST) Message-ID: <40522D5F.2090805@dynamicsoft.com> Date: Fri, 12 Mar 2004 16:36:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU Issue 1: Registration conflicts Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, During the IETF meeting last week, I went over several open issues in the gruu spec. We had closure on some, and not on others. I'd like to confirm consensus on those we closed on, and obtain consensus on the others, as soon as possible. To that extent, I am sending a few notes on specific issues to be resolved. THis is the first. Consider the following situation. User agent A has instance ID 1 and IP address IP1. It registers IP1, indicates that its associated with instance ID 1, and gets a GRUU for it. UA A crashes and reboots. It obtains a new IP, IP2. Its instance ID is unchanged. It registers once more. This registration indicates that IP2 is associated with instance ID 1. Now, the registrar has a problem. It has two contacts (IP1 and IP2) both seemingly bound to the same instance ID. What does it do? Here are the only options I can see: 1. It binds the GRUU to *both* IP addresses. Subequent requests sent to the GRUU would fork to both addresses. 2. The registrar rejects the registration. Its up to the client to correct the situation by unregistering the old contact first. 3. The registrar accepts the new registration and deletes the old one. Option 1 is clearly unacceptable, since it violates a fundamental gruu property. The difference between option 2 and option 3 is in who makes the decision on how to resolve the conflict. In option 2, the client decices. In option 3, the server decides, and always applies a fixed policy - delete the older registration. I think option 2 is better, since it puts control in the hands of the client. Their could be cases where the right behavior is to keep the old registration; I could think of one, but who knows down the road.... So, my proposal was to accept option 2, and add text to the specification detailing this behavior. I also proposed using a specific response code for this case, so that the client could take the appropriate actions. I believe there was agreement at the meeting to take this path. Does anyone object? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 12 17:23:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22869 for ; Fri, 12 Mar 2004 17:23:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1v3g-0006w1-3Q for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 17:23:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CMNB1I026593 for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 17:23:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1v3V-0006t6-Ik; Fri, 12 Mar 2004 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1v3H-0006sG-IV for sip@optimus.ietf.org; Fri, 12 Mar 2004 17:22:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22833 for ; Fri, 12 Mar 2004 17:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1v3F-0003iL-00 for sip@ietf.org; Fri, 12 Mar 2004 17:22:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1v2N-0003fY-00 for sip@ietf.org; Fri, 12 Mar 2004 17:21:52 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B1v1a-0003Xv-00 for sip@ietf.org; Fri, 12 Mar 2004 17:21:02 -0500 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2CMKfNr017389 for ; Fri, 12 Mar 2004 17:20:41 -0500 (EST) Message-ID: <405237AE.80209@dynamicsoft.com> Date: Fri, 12 Mar 2004 17:20:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU issue 2: Callee caps param or not Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Currently, the instance attribute in the Contact header field is a callee capabilities parameter. This is "flagged" by the presence of +sip. as a prefix. So, a REGISTER would look like this: REGISTER sip:example.com To: sip:user@example.com Contact: sip:u1@1.2.3.4;+sip.instance="hasdasdsadiasdasida" The alternative would be to use a new, non-callee-caps parameter: REGISTER sip:example.com To: sip:user@example.com Contact: sip:u1@1.2.3.4;instance="hasdasdsadiasdasida" The only difference in these two approaches is that in the former case, you can use caller preferences with the tag. That means one could construct an INVITE request an ask for preferential routing to a device with that instance ID. For example: INVITE sip:user@example.com Accept-Contact *;+sip.instance="hasdasdsadiasdasida" This would prefer that the INVITE be routed to a device with that instance ID. Its important to note that this is NOT AN ALTERNATIVE for the gruu, which would guarantee routing to the device with that instance: INVITE sip:hhs777asd==000asdhnvvva8s7@example.com Indeed, one of the reasons we specified gruu was that caller-prefs based routing was unreliable: 1. there was no guarantee it was honored by a proxy 2. it would only work in cases where routing decisions were made by a single proxy - the one that the users registered too 3. it depended on knowledge of downstream routing behaviors That said, there may be cases where the desired behavior is "I want to reach this user at this aor, but would prefer this instance id". Having the instance ID as a callee-cap parameter would allow that. So, the question is, what to do in the spec? callee cap or not? There was consensus at the meeting to keep it as a callee-cap, and document the above issues so that people would be clear when to use caller prefs, and when to use the gruu. Does anyone object to this decision? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 12 19:21:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01436 for ; Fri, 12 Mar 2004 19:21:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wtz-0004wt-1H for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 19:21:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D0LIq2018958 for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 19:21:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wtj-0004tl-5w; Fri, 12 Mar 2004 19:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wsl-0004rO-Di for sip@optimus.ietf.org; Fri, 12 Mar 2004 19:20:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01275 for ; Fri, 12 Mar 2004 19:20:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1wsj-0003w1-00 for sip@ietf.org; Fri, 12 Mar 2004 19:20:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1wrm-0003qz-00 for sip@ietf.org; Fri, 12 Mar 2004 19:19:02 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B1wqp-0003k4-00 for sip@ietf.org; Fri, 12 Mar 2004 19:18:03 -0500 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2D0HcNr017433 for ; Fri, 12 Mar 2004 19:17:38 -0500 (EST) Message-ID: <40525318.1000602@dynamicsoft.com> Date: Fri, 12 Mar 2004 19:17:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU Issue 3: Format of instance ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The specification is currently not clear on how ones computes an instance ID. It has this to say: Summary of the media feature indicated by this tag: This feature tag contains a string that indicates a unique identifier associated with the UA instance registering the Contact. This identifier is globally unique, and remains bound to the UA instance for as long as is achievable. For UA instances that are implemented as hardware, such as an IP phone, the instance ID would ideally be burned into firmware when the device is manufactured. For software, the instance ID would generally be randomly created at installation time. Do we need to say something more specific? A point was raised during the meeting that its not sufficient to merely say its unique. THe problem is that two separate instances may compute an instance which is unique within the approach they are using, but conflicts with a value in another approach. As an example, lets say one UA defines uniqueness by encoding its MAC address forwards, and the other by encoding it backwards. Two instances with unique MAC addresses may end up with the same instance ID. So, it seemed like we DID need to say something about how to compute this. That seemed a difficult thing to do, as we had several different proposals on the table that all seemed reasonable. So, we left the meeting without consensus. I'd like to recommend the following solution: "This feature tag contains a string that is a URN [URN-REF]. This specification makes no normative recommendation on the specific URN that is to be used. However, the URN namespace and URN value MUST be selected such that the instance can be certain that no other instance would choose the same URN value for that particular namespace. One URN that readily meets this objective is the UUID URN [UUID-REF], which allows for non-centralized computation of a URN based on time, unique names (such as a MAC address) or a random number generator. An example of a URN that would not meet this objective is the national bibliographic number [RFC3188]; since there is no clear relationship between an SIP UA instance and a URN in this namespace, there is no way a selection of a value can be performed that guarantees that another UA instance doesn't choose the same value." UUID-REF corresponds to http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt. This seems to really be exactly what we want, since it allows for computation of a URN based on MAC address, time, or random number, and all of the hard stuff is already worked out. My proposed text, fortunately, makes the URN UUID specification only informative. However, in the absence of any other viable URNs that are already at RFC, practically speaking this would be the only choice, and so completion of that spec will be important for us. Its currently under IESG evaluation, but not without some controversy. Do people feel that this is an acceptable solution? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 12 19:28:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01787 for ; Fri, 12 Mar 2004 19:28:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1x0a-0005Ys-3L for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 19:28:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D0S8VY021326 for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 19:28:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1x0T-0005St-HP; Fri, 12 Mar 2004 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wzU-0005Rf-UU for sip@optimus.ietf.org; Fri, 12 Mar 2004 19:27:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01738 for ; Fri, 12 Mar 2004 19:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1wzT-0004Qz-00 for sip@ietf.org; Fri, 12 Mar 2004 19:26:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1wyZ-0004Ns-00 for sip@ietf.org; Fri, 12 Mar 2004 19:26:04 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B1wxm-0004GS-00 for sip@ietf.org; Fri, 12 Mar 2004 19:25:14 -0500 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2D0OsNr017436 for ; Fri, 12 Mar 2004 19:24:54 -0500 (EST) Message-ID: <405254CC.2030504@dynamicsoft.com> Date: Fri, 12 Mar 2004 19:24:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU Issue 4 (last one): Reusable grid? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The GRID URI parameter, defined by the GRUU spec, has some nice properties associated with it. Perhaps most valuable is that it survives proxy translations. This makes it a URI parameter that is automatically passed from the UAC to UAS. In that regard, it can be used as a form of "sub-addressing" - a means to identify a sub-instance within the UA instance pointed to by the GRUU proper. One comment that was made at some point is that the grid parameter, as a result of these properties, would be generally useful for SIP URIs, and should therefore not be bound to the GRUU. The proposal was to "generecize" it. My response to that was: 1. It is already generecized, in that its a valid URI parameter, 2. It only makes sense in URIs that have the GRUU property. Without that, the grid would need to be interpreted across different UA instances, and thus it loses the sub-addressing property, which only makes sense within a particular UA instance 3. You can get a GRUU through non-register mechanisms As such, my proposal is to keep things as they are. Any objections? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 12 19:40:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02179 for ; Fri, 12 Mar 2004 19:40:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xCH-0006MV-Qt for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 19:40:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D0eD6g024454 for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 19:40:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xC8-0006Kr-DD; Fri, 12 Mar 2004 19:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xBs-0006Jz-80 for sip@optimus.ietf.org; Fri, 12 Mar 2004 19:39:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02160 for ; Fri, 12 Mar 2004 19:39:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1xBq-0004xk-00 for sip@ietf.org; Fri, 12 Mar 2004 19:39:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1xAu-0004wS-00 for sip@ietf.org; Fri, 12 Mar 2004 19:38:49 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1B1xA4-0004tr-00 for sip@ietf.org; Fri, 12 Mar 2004 19:37:56 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 16:37:28 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Mar 2004 16:37:26 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 16:37:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU Issue 4 (last one): Reusable grid? Date: Fri, 12 Mar 2004 16:37:27 -0800 Message-ID: Thread-Topic: [Sip] GRUU Issue 4 (last one): Reusable grid? Thread-Index: AcQIkg3iUdTOwY8qQj6aeQEVop4dowAATSUg From: "Orit Levin" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 13 Mar 2004 00:37:15.0579 (UTC) FILETIME=[553248B0:01C40893] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I am OK with keeping the GRID as is. Orit.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Friday, March 12, 2004 4:25 PM To: sip@ietf.org Subject: [Sip] GRUU Issue 4 (last one): Reusable grid? The GRID URI parameter, defined by the GRUU spec, has some nice properties associated with it. Perhaps most valuable is that it survives proxy translations. This makes it a URI parameter that is automatically passed from the UAC to UAS. In that regard, it can be used as a form of "sub-addressing" - a means to identify a sub-instance within the UA instance pointed to by the GRUU proper. One comment that was made at some point is that the grid parameter, as a result of these properties, would be generally useful for SIP URIs, and should therefore not be bound to the GRUU. The proposal was to "generecize" it. My response to that was: 1. It is already generecized, in that its a valid URI parameter, 2. It only makes sense in URIs that have the GRUU property. Without that, the grid would need to be interpreted across different UA instances, and thus it loses the sub-addressing property, which only makes sense within a particular UA instance 3. You can get a GRUU through non-register mechanisms As such, my proposal is to keep things as they are. Any objections? Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 12 20:02:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02817 for ; Fri, 12 Mar 2004 20:02:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xXZ-0007Pw-1R for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 20:02:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D12D54028506 for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 20:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xXP-0007OJ-97; Fri, 12 Mar 2004 20:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xXD-0007Ns-Di for sip@optimus.ietf.org; Fri, 12 Mar 2004 20:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02813 for ; Fri, 12 Mar 2004 20:01:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1xXB-0005sv-00 for sip@ietf.org; Fri, 12 Mar 2004 20:01:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1xWI-0005rZ-00 for sip@ietf.org; Fri, 12 Mar 2004 20:00:55 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1B1xW7-0005qB-00 for sip@ietf.org; Fri, 12 Mar 2004 20:00:43 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 17:00:15 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Fri, 12 Mar 2004 17:00:11 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Mar 2004 17:00:01 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 17:01:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU Issue 3: Format of instance ID Date: Fri, 12 Mar 2004 17:00:14 -0800 Message-ID: Thread-Topic: [Sip] GRUU Issue 3: Format of instance ID Thread-Index: AcQIkSYODnIoIjIoTuehBmdyR1AOwwAAvjyA From: "Orit Levin" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 13 Mar 2004 01:01:02.0448 (UTC) FILETIME=[A7AD3700:01C40896] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Whatever ensuring global uniqueness format we recommend, the document needs to make clear that from SIP perspective the uniqueness MUST be achieved per AOR, not necessarily be globally unique in general. Some system integrators will require (and ensure) that different vendors generate unique instance identifiers in "HW" according to a specification chosen by the integrator (and hopefully recommended by us). Other SW system integrators will be able to configure a simple formula for generating instance identifiers unique within an AOR. The complexity to find a perfect formula depends on what kind of clients are allowed to register under a single AOR in a given system. Orit.=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Friday, March 12, 2004 4:17 PM To: sip@ietf.org Subject: [Sip] GRUU Issue 3: Format of instance ID The specification is currently not clear on how ones computes an instance ID. It has this to say: Summary of the media feature indicated by this tag: This feature tag contains a string that indicates a unique identifier associated with the UA instance registering the Contact. This identifier is globally unique, and remains bound to the UA instance for as long as is achievable. For UA instances that are implemented as hardware, such as an IP phone, the instance ID would ideally be burned into firmware when the device is manufactured. For software, the instance ID would generally be randomly created at installation time. Do we need to say something more specific? A point was raised during the meeting that its not sufficient to merely say its unique. THe problem is that two separate instances may compute an instance which is unique within the approach they are using, but conflicts with a value in another approach. As an example, lets say one UA defines uniqueness by encoding its MAC address forwards, and the other by encoding it backwards. Two instances with unique MAC addresses may end up with the same instance ID. So, it seemed like we DID need to say something about how to compute this. That seemed a difficult thing to do, as we had several different proposals on the table that all seemed reasonable. So, we left the meeting without consensus. I'd like to recommend the following solution: "This feature tag contains a string that is a URN [URN-REF]. This specification makes no normative recommendation on the specific URN that is to be used. However, the URN namespace and URN value MUST be selected such that the instance can be certain that no other instance would choose the same URN value for that particular namespace. One URN that readily meets this objective is the UUID URN [UUID-REF], which allows for non-centralized computation of a URN based on time, unique names (such as a MAC address) or a random number generator. An example of a URN that would not meet this objective is the national bibliographic number [RFC3188]; since there is no clear relationship between an SIP UA instance and a URN in this namespace, there is no way a selection of a value can be performed that guarantees that another UA instance doesn't choose the same value." UUID-REF corresponds to http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt. This seems to really be exactly what we want, since it allows for computation of a URN based on MAC address, time, or random number, and all of the hard stuff is already worked out. My proposed text, fortunately, makes the URN UUID specification only informative. However, in the absence of any other viable URNs that are already at RFC, practically speaking this would be the only choice, and so completion of that spec will be important for us. Its currently under IESG evaluation, but not without some controversy. Do people feel that this is an acceptable solution? Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 12 21:41:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07837 for ; Fri, 12 Mar 2004 21:41:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1z5R-0004g2-Qc for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 21:41:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D2fHdf017913 for sip-archive@odin.ietf.org; Fri, 12 Mar 2004 21:41:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1z5D-0004dH-4E; Fri, 12 Mar 2004 21:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1z52-0004bB-G9 for sip@optimus.ietf.org; Fri, 12 Mar 2004 21:40:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07814 for ; Fri, 12 Mar 2004 21:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1z4z-0004bF-00 for sip@ietf.org; Fri, 12 Mar 2004 21:40:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1z42-0004Zv-00 for sip@ietf.org; Fri, 12 Mar 2004 21:39:51 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1z36-0004Xg-00 for sip@ietf.org; Fri, 12 Mar 2004 21:38:53 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Mar 2004 18:41:12 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2D2cKM7027182; Fri, 12 Mar 2004 18:38:21 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-164.cisco.com [10.86.242.164]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT32403; Fri, 12 Mar 2004 21:38:18 -0500 (EST) Message-ID: <4052741A.8060108@cisco.com> Date: Fri, 12 Mar 2004 21:38:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] GRUU Issue 3: Format of instance ID References: <40525318.1000602@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Do people feel that this is an acceptable solution? YES. Paul Jonathan Rosenberg wrote: > The specification is currently not clear on how ones computes an > instance ID. It has this to say: > > Summary of the media feature indicated by this tag: This feature tag > contains a string that indicates a unique identifier associated > with the UA instance registering the Contact. This identifier is > globally unique, and remains bound to the UA instance for as long > as is achievable. For UA instances that are implemented as > hardware, such as an IP phone, the instance ID would ideally be > burned into firmware when the device is manufactured. For > software, the instance ID would generally be randomly created at > installation time. > > Do we need to say something more specific? A point was raised during the > meeting that its not sufficient to merely say its unique. THe problem is > that two separate instances may compute an instance which is unique > within the approach they are using, but conflicts with a value in > another approach. > > As an example, lets say one UA defines uniqueness by encoding its MAC > address forwards, and the other by encoding it backwards. Two instances > with unique MAC addresses may end up with the same instance ID. > > So, it seemed like we DID need to say something about how to compute > this. That seemed a difficult thing to do, as we had several different > proposals on the table that all seemed reasonable. So, we left the > meeting without consensus. > > I'd like to recommend the following solution: > > > "This feature tag contains a string that is a URN [URN-REF]. This > specification makes no normative recommendation on the specific URN that > is to be used. However, the URN namespace and URN value MUST be selected > such that the instance can be certain that no other instance would > choose the same URN value for that particular namespace. One URN that > readily meets this objective is the UUID URN [UUID-REF], which allows > for non-centralized computation of a URN based on time, unique names > (such as a MAC address) or a random number generator. An example of a > URN that would not meet this objective is the national bibliographic > number [RFC3188]; since there is no clear relationship between an SIP UA > instance and a URN in this namespace, there is no way a selection of a > value can be performed that guarantees that another UA instance doesn't > choose the same value." > > UUID-REF corresponds to > http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt. This > seems to really be exactly what we want, since it allows for computation > of a URN based on MAC address, time, or random number, and all of the > hard stuff is already worked out. My proposed text, fortunately, makes > the URN UUID specification only informative. However, in the absence of > any other viable URNs that are already at RFC, practically speaking this > would be the only choice, and so completion of that spec will be > important for us. Its currently under IESG evaluation, but not without > some controversy. > > Do people feel that this is an acceptable solution? > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 15 04:58:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18033 for ; Mon, 15 Mar 2004 04:58:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ord-0003q9-4u for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 04:58:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F9wSVe014760 for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 04:58:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2orE-0003oD-PK; Mon, 15 Mar 2004 04:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2or7-0003nW-2f for sip@optimus.ietf.org; Mon, 15 Mar 2004 04:57:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17992 for ; Mon, 15 Mar 2004 04:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2or3-0002Tj-00 for sip@ietf.org; Mon, 15 Mar 2004 04:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2oq3-0002N0-00 for sip@ietf.org; Mon, 15 Mar 2004 04:56:51 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly06b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1B2opU-0002Fk-00 for sip@ietf.org; Mon, 15 Mar 2004 04:56:16 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly06b.srv.mailcontrol.com (MailControl) with SMTP id i2F9td27030157; Mon, 15 Mar 2004 09:55:39 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Mon, 15 Mar 2004 09:55:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU Issue 1: Registration conflicts Date: Mon, 15 Mar 2004 09:55:39 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B213@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] GRUU Issue 1: Registration conflicts Thread-Index: AcQIenviNjZS3ZrJQ/qTmPl57teZNQB+K7ag From: "Chris Boulton" To: "Jonathan Rosenberg" , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 12 March 2004 21:37 >To: sip@ietf.org >Subject: [Sip] GRUU Issue 1: Registration conflicts > >Folks, > >During the IETF meeting last week, I went over several open issues in >the gruu spec. We had closure on some, and not on others. I'd like to >confirm consensus on those we closed on, and obtain consensus on the >others, as soon as possible. To that extent, I am sending a few notes on >specific issues to be resolved. THis is the first. > >Consider the following situation. User agent A has instance ID 1 and IP >address IP1. It registers IP1, indicates that its associated with >instance ID 1, and gets a GRUU for it. UA A crashes and reboots. It >obtains a new IP, IP2. Its instance ID is unchanged. It registers once >more. This registration indicates that IP2 is associated with instance >ID 1. Now, the registrar has a problem. It has two contacts (IP1 and >IP2) both seemingly bound to the same instance ID. What does it do? > >Here are the only options I can see: > >1. It binds the GRUU to *both* IP addresses. Subequent requests sent to >the GRUU would fork to both addresses. > >2. The registrar rejects the registration. Its up to the client to >correct the situation by unregistering the old contact first. > >3. The registrar accepts the new registration and deletes the old one. > > >Option 1 is clearly unacceptable, since it violates a fundamental gruu >property. > >The difference between option 2 and option 3 is in who makes the >decision on how to resolve the conflict. In option 2, the client >decices. In option 3, the server decides, and always applies a fixed >policy - delete the older registration. > >I think option 2 is better, since it puts control in the hands of the >client. Their could be cases where the right behavior is to keep the old >registration; I could think of one, but who knows down the road.... > >So, my proposal was to accept option 2, and add text to the >specification detailing this behavior. I also proposed using a specific >response code for this case, so that the client could take the >appropriate actions. > >I believe there was agreement at the meeting to take this path. Does >anyone object? [Chris Boulton] No objection here. It would be useful for both (>1) GRUU values to be represented in the NEW response. Maybe also some definition of original + updated address (although the client will know it's own current IP so probably not necessary). Chris. > > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 15 09:19:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28603 for ; Mon, 15 Mar 2004 09:19:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2swB-000718-KL for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 09:19:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FEJRCb026909 for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 09:19:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2svl-0006yE-IX; Mon, 15 Mar 2004 09:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2svd-0006xu-BN for sip@optimus.ietf.org; Mon, 15 Mar 2004 09:18:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28545 for ; Mon, 15 Mar 2004 09:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2svb-0005ZP-00 for sip@ietf.org; Mon, 15 Mar 2004 09:18:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2sua-0005PT-00 for sip@ietf.org; Mon, 15 Mar 2004 09:17:49 -0500 Received: from web12310.mail.yahoo.com ([216.136.173.160]) by ietf-mx with smtp (Exim 4.12) id 1B2stc-0005Eb-00 for sip@ietf.org; Mon, 15 Mar 2004 09:16:48 -0500 Message-ID: <20040315141647.35133.qmail@web12310.mail.yahoo.com> Received: from [193.198.140.25] by web12310.mail.yahoo.com via HTTP; Mon, 15 Mar 2004 06:16:47 PST Date: Mon, 15 Mar 2004 06:16:47 -0800 (PST) From: Jelena Mak To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1340401312-1079360207=:35046" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] documentation needed! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-1340401312-1079360207=:35046 Content-Type: text/plain; charset=us-ascii I want to gather all the information that i can about coding SIP messages with XML. If anyone knows some usefull links,please be so kind and mail them to me. tnx! Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam --0-1340401312-1079360207=:35046 Content-Type: text/html; charset=us-ascii
I want to gather all the information that i can about coding SIP messages with XML.
If anyone knows some usefull links,please be so kind and mail them to me.
tnx!

Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam --0-1340401312-1079360207=:35046-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 15 10:56:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05197 for ; Mon, 15 Mar 2004 10:56:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uRu-0007gG-Ep for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 10:56:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FFuIWG029523 for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 10:56:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uRf-0007cz-Ex; Mon, 15 Mar 2004 10:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uQm-0007Vk-Am for sip@optimus.ietf.org; Mon, 15 Mar 2004 10:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05028 for ; Mon, 15 Mar 2004 10:55:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2uQj-0002qS-00 for sip@ietf.org; Mon, 15 Mar 2004 10:55:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2uPt-0002jN-00 for sip@ietf.org; Mon, 15 Mar 2004 10:54:13 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1B2uPS-0002bL-00 for sip@ietf.org; Mon, 15 Mar 2004 10:53:46 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i2FFrhK06249 for ; Mon, 15 Mar 2004 16:53:43 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i2FFrgx25394 for ; Mon, 15 Mar 2004 16:53:42 +0100 (MET) Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA27591 for ; Mon, 15 Mar 2004 16:53:17 +0100 (MET) Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Mar 2004 16:53:40 +0100 Message-ID: <5B788FC2CAFBD6118BAE0030848B025C7A24EF@LNN201E> From: Marjou Xavier To: sip@ietf.org Date: Mon, 15 Mar 2004 16:53:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40AA5.AD7564D0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] GRUU and dial-in conference Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C40AA5.AD7564D0 Content-Type: text/plain Hi, In the context of GRUU, I wonder about another use-case (requirement). The current GRUU mechanism works well for a dial-out conference, but a dial-in conference seem to be out of scope. For example: Let's say that sip:xm-predef-conference@foo.com is a URI representing a predefined conference and is available in a web page. When UE-A wants to join this AOR, he is routed to one server (among many), which will create the conference. When UE-B also wants to join this AOR, he does not have the GRUU: nevertheless, it would be nice that the proxy (that owns the domain foo.com) first tries to route the INVITE of UE-B to the specific server that created the conference. Otherwise another conference server could receive the INVITE of UE-B. What do you think? Best Regards, Xavier Marjou ------_=_NextPart_001_01C40AA5.AD7564D0 Content-Type: text/html

Hi,

 

In the context of GRUU, I wonder about another use-case (requirement). The current GRUU mechanism works well for a dial-out conference, but a dial-in conference seem to be out of scope.

 

For example:

Let's say that sip:xm-predef-conference@foo.com is a URI representing a predefined conference and is available in a web page.

When UE-A wants to join this AOR, he is routed to one server (among many), which will create the conference.

When UE-B also wants to join this AOR, he does not have the GRUU: nevertheless, it would be nice that the proxy (that owns the domain foo.com) first tries to route the INVITE of UE-B to the specific server that created the conference. Otherwise another conference server could receive the INVITE of UE-B.

What do you think?

 

Best Regards,

Xavier Marjou

 

 

------_=_NextPart_001_01C40AA5.AD7564D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 15 11:37:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08843 for ; Mon, 15 Mar 2004 11:37:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2v5c-0003ei-Gj for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 11:37:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FGbKBD013987 for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 11:37:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2v5K-0003YW-S2; Mon, 15 Mar 2004 11:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2v4a-0003K3-D0 for sip@optimus.ietf.org; Mon, 15 Mar 2004 11:36:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08743 for ; Mon, 15 Mar 2004 11:36:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2v4Z-00021X-00 for sip@ietf.org; Mon, 15 Mar 2004 11:36:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2v3d-0001sX-00 for sip@ietf.org; Mon, 15 Mar 2004 11:35:17 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B2v35-0001jS-00 for sip@ietf.org; Mon, 15 Mar 2004 11:34:43 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2FGXuTN011437; Mon, 15 Mar 2004 10:33:57 -0600 (CST) Message-ID: <4055DAF3.8040809@alcatel.com> Date: Mon, 15 Mar 2004 10:33:55 -0600 From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] GRUU Issue 1: Registration conflicts References: <40522D5F.2090805@dynamicsoft.com> In-Reply-To: <40522D5F.2090805@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Option 2 is reasonable. We assume of course that the client will be given all the neccessary information it needs to unregister the old contact, since it may have lost all knowledge of that information due to the crash. Regards, Alex. Jonathan Rosenberg wrote: > Folks, > > During the IETF meeting last week, I went over several open issues in > the gruu spec. We had closure on some, and not on others. I'd like to > confirm consensus on those we closed on, and obtain consensus on the > others, as soon as possible. To that extent, I am sending a few notes > on specific issues to be resolved. THis is the first. > > Consider the following situation. User agent A has instance ID 1 and > IP address IP1. It registers IP1, indicates that its associated with > instance ID 1, and gets a GRUU for it. UA A crashes and reboots. It > obtains a new IP, IP2. Its instance ID is unchanged. It registers once > more. This registration indicates that IP2 is associated with instance > ID 1. Now, the registrar has a problem. It has two contacts (IP1 and > IP2) both seemingly bound to the same instance ID. What does it do? > > Here are the only options I can see: > > 1. It binds the GRUU to *both* IP addresses. Subequent requests sent > to the GRUU would fork to both addresses. > > 2. The registrar rejects the registration. Its up to the client to > correct the situation by unregistering the old contact first. > > 3. The registrar accepts the new registration and deletes the old one. > > > Option 1 is clearly unacceptable, since it violates a fundamental gruu > property. > > The difference between option 2 and option 3 is in who makes the > decision on how to resolve the conflict. In option 2, the client > decices. In option 3, the server decides, and always applies a fixed > policy - delete the older registration. > > I think option 2 is better, since it puts control in the hands of the > client. Their could be cases where the right behavior is to keep the > old registration; I could think of one, but who knows down the road.... > > So, my proposal was to accept option 2, and add text to the > specification detailing this behavior. I also proposed using a > specific response code for this case, so that the client could take > the appropriate actions. > > I believe there was agreement at the meeting to take this path. Does > anyone object? > > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 15 14:37:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18626 for ; Mon, 15 Mar 2004 14:37:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xto-0004ZJ-4k for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 14:37:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FJbKjW017560 for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 14:37:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xtZ-0004TH-4z; Mon, 15 Mar 2004 14:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xsf-0004Ps-Gg for sip@optimus.ietf.org; Mon, 15 Mar 2004 14:36:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18543 for ; Mon, 15 Mar 2004 14:36:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xsc-00072t-00 for sip@ietf.org; Mon, 15 Mar 2004 14:36:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xrr-0006zP-00 for sip@ietf.org; Mon, 15 Mar 2004 14:35:20 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1B2xr6-0006qx-00 for sip@ietf.org; Mon, 15 Mar 2004 14:34:32 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HUM00HECU1F1Z@firewall.mci.com> for sip@ietf.org; Mon, 15 Mar 2004 19:27:21 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HUM00601U16KD@pmismtp01.mcilink.com>; Mon, 15 Mar 2004 19:27:18 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.104.252]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HUM005L5U1DVJ@pmismtp01.mcilink.com>; Mon, 15 Mar 2004 19:27:15 +0000 (GMT) Date: Mon, 15 Mar 2004 13:27:13 -0600 From: Alan Johnston Subject: Re: [Sip] GRUU and dial-in conference In-reply-to: <5B788FC2CAFBD6118BAE0030848B025C7A24EF@LNN201E> X-Sender: Alan.Johnston@pop.mcit.com To: Marjou Xavier , sip@ietf.org Message-id: <5.2.1.1.0.20040315125951.02954e90@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Xavier, Comments below. Thanks, Alan Johnston MCI sip:alan@sipstation.com At 04:53 PM 3/15/2004 +0100, Marjou Xavier wrote: >Hi, > > > >In the context of GRUU, I wonder about another use-case (requirement). The >current GRUU mechanism works well for a dial-out conference, but a dial-in >conference seem to be out of scope. > > > >For example: > >Let's say that sip:xm-predef-conference@foo.com is a URI representing a >predefined conference and is available in a web page. If this URI is a conference URI, then it is, by definition, a GRUU. >When UE-A wants to join this AOR, he is routed to one server (among many), >which will create the conference. Not sure what you mean here. Sounds like you are mixing the concepts of a conference factory URI and a conference URI - they have different usages and meanings. See http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt and http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt >When UE-B also wants to join this AOR, he does not have the GRUU: All B needs to join is the conference URI. In your example I think this would be sip:xm-predef-conference@foo.com, which is a GRUU. > nevertheless, it would be nice that the proxy (that owns the domain > foo.com) first tries to route the INVITE of UE-B to the specific server > that created the conference. Otherwise another conference server could > receive the INVITE of UE-B. Perhaps you are wondering how the conferencing application server locates the correct media server (mixer)? >What do you think? > > > >Best Regards, > >Xavier Marjou > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 15 16:48:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00052 for ; Mon, 15 Mar 2004 16:48:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zwP-00079E-BY for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 16:48:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FLm9wj027412 for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 16:48:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zwI-00076T-7O; Mon, 15 Mar 2004 16:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zvP-00075h-8M for sip@optimus.ietf.org; Mon, 15 Mar 2004 16:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00022 for ; Mon, 15 Mar 2004 16:47:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2zvN-0002hX-00 for sip@ietf.org; Mon, 15 Mar 2004 16:47:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2zuV-0002gJ-00 for sip@ietf.org; Mon, 15 Mar 2004 16:46:11 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx with esmtp (Exim 4.12) id 1B2zuK-0002eP-00 for sip@ietf.org; Mon, 15 Mar 2004 16:46:00 -0500 Received: from cornfed.com ([151.196.186.56]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id i2FLjU300603 for ; Mon, 15 Mar 2004 15:45:30 -0600 Message-ID: <405623ED.7000509@cornfed.com> Date: Mon, 15 Mar 2004 16:45:17 -0500 From: "Frank W. Miller" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] UAC handling 4xx responses Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit RFC 3261 states: In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case. I'm wondering why this is necessary? Its definitely easier from an implementation point of view to just pick a new Call-ID, tags and CSeq that have nothing to do with the previous request. There will presumably be an ACK sent back that finishes the transaction, so why even bother with trying to do this? Is it that the UAC presumably has all the necessary info just sitting around so why not do it? Curious... FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 16 02:26:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13734 for ; Tue, 16 Mar 2004 02:26:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B38y4-0007LP-C9 for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 02:26:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G7QSUm028214 for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 02:26:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B38xh-0007Ef-RH; Tue, 16 Mar 2004 02:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B38xL-00079y-RY for sip@optimus.ietf.org; Tue, 16 Mar 2004 02:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13644 for ; Tue, 16 Mar 2004 02:25:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B38xI-0002yQ-00 for sip@ietf.org; Tue, 16 Mar 2004 02:25:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B38wJ-0002ud-00 for sip@ietf.org; Tue, 16 Mar 2004 02:24:40 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B38vY-0002nW-00 for sip@ietf.org; Tue, 16 Mar 2004 02:23:52 -0500 Received: from dynamicsoft.com ([63.113.46.8]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2G7NKNr019046; Tue, 16 Mar 2004 02:23:20 -0500 (EST) Message-ID: <4056AB5E.1090000@dynamicsoft.com> Date: Tue, 16 Mar 2004 02:23:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: sip@ietf.org Subject: Re: [Sip] GRUU Issue 1: Registration conflicts References: <40522D5F.2090805@dynamicsoft.com> <4055DAF3.8040809@alcatel.com> In-Reply-To: <4055DAF3.8040809@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Audu wrote: > Option 2 is reasonable. We assume of course that the client will be > given all the neccessary > information it needs to unregister the old contact, since it may have > lost all knowledge of > that information due to the crash. Yes. Upon failure, it could query the registrar by sending a REGISTER with no Contacts. The 200 OK includes the currently registered contacts, including the "old" one with the existing instance id. The UA can then delete this registration by sending another REGISTER request, including that Contact with ;expires=0, and the new one as well. We probably need to say that the registrar should make sure to process deletions (with expires 0) before checking for conflicts. Otherwise it would take two requests - one to delete the old contact, and another to add the new one. Chris Boulton writes: > [Chris Boulton] No objection here. It would be useful for both (>1) > GRUU values to be represented in the NEW response. Maybe also some > definition of original + updated address (although the client will know > it's own current IP so probably not necessary). My proposal above was to just use a subsequent REGISTER to obtain the old contact. I'm a bit reluctant to include the Contact in an error response, since this would be another meaning of Contact. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 16 06:42:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25276 for ; Tue, 16 Mar 2004 06:42:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Cxi-0005PX-1C for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 06:42:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GBgLau020665 for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 06:42:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CxQ-0005Gl-Qo; Tue, 16 Mar 2004 06:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Cwk-0005BH-4q for sip@optimus.ietf.org; Tue, 16 Mar 2004 06:41:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25111 for ; Tue, 16 Mar 2004 06:41:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Cwf-0001Gh-00 for sip@ietf.org; Tue, 16 Mar 2004 06:41:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Cve-00016S-00 for sip@ietf.org; Tue, 16 Mar 2004 06:40:15 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1B3Cuj-0000x7-00 for sip@ietf.org; Tue, 16 Mar 2004 06:39:17 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GBdH409121; Tue, 16 Mar 2004 13:39:17 +0200 (EET) X-Scanned: Tue, 16 Mar 2004 13:38:49 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2GBcnlu024865; Tue, 16 Mar 2004 13:38:49 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00FJ61eo; Tue, 16 Mar 2004 13:38:47 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GBcXs12771; Tue, 16 Mar 2004 13:38:33 +0200 (EET) Received: from nokia.com ([172.22.129.146]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Mar 2004 13:38:27 +0200 Message-ID: <4056E735.9040500@nokia.com> Date: Tue, 16 Mar 2004 13:38:29 +0200 From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Gonzalo Camarillo CC: sip References: <4050276B.7040801@ericsson.com> In-Reply-To: <4050276B.7040801@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2004 11:38:27.0909 (UTC) FILETIME=[32FCAF50:01C40B4B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Registrying parameter values Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm OK with this approach. Cheers, Aki ext Gonzalo Camarillo wrote: > Folks, > > during the SIP session, we got clear guidance from Allison that creating > a new registry for parameter values would be unacceptable. > Still, there is an easy way to, at least, register the references to > those new values. The idea is that the registry of parameters contains > the reference to the RFC defining the parameter *and* to any RFC > extending the values that the parameter admits. > > For example, if I define a new compression scheme called "Mycompression" > to be used as an alternative to SigComp (comp=sigcomg vs. > comp=mycompression) in RFCxxxx, the registry would look like: > > Header Field Parameter Name Reference > ____________________________________________________________ > Via comp RFC 3486 > RFC xxxx > > > This way, we would not register the values themselves, but would provide > references to all the relevant specs so that implementers could avoid > collisions anyway. > > Does anybody have a problem with this? This requires a *mininal* change > to the existing definition of the parameter registry. > > Thanks, > > Gonzalo > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 16 06:42:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25277 for ; Tue, 16 Mar 2004 06:42:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Cxi-0005PY-1e for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 06:42:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GBgLcD020666 for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 06:42:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CxV-0005J5-TZ; Tue, 16 Mar 2004 06:42:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CxK-0005F1-Nf for sip@optimus.ietf.org; Tue, 16 Mar 2004 06:41:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25227 for ; Tue, 16 Mar 2004 06:41:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3CxG-0001Nf-00 for sip@ietf.org; Tue, 16 Mar 2004 06:41:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3CwY-0001Fy-00 for sip@ietf.org; Tue, 16 Mar 2004 06:41:11 -0500 Received: from [80.74.106.10] (helo=rvil-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1B3CvV-000149-00 for sip@ietf.org; Tue, 16 Mar 2004 06:40:05 -0500 Received: from rvil-mail.radvision.com [172.20.2.102] by rvil-mail.radvision.com with XWall v3.28 ; Tue, 16 Mar 2004 13:41:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2004 13:41:36 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B149437@rvil-mail.radvision.com> Thread-Topic: Is there an object named "call" in RFC 3261? Thread-Index: AcQLS6MhAfznLQ92QQGNMCsC6lwhWA== From: "Sarit Galanos" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Is there an object named "call" in RFC 3261? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, In RFC 3261 the word "call" is mentioned in the following paragraph: when multiple 2xx responses are received from different remote UAs = (because the INVITE forked), each 2xx establishes a different dialog. All these dialogs are part of the same call. My question is: What is this call. Is it an object that all dialogs that = were created from the same INVITE should be related to? When should a call object be created? When should it be terminated? Thanks, Sarit. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 16 11:17:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08611 for ; Tue, 16 Mar 2004 11:17:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3HFn-0004Xy-9E for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 11:17:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GGHJEB017413 for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 11:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3HFV-0004VQ-Qf; Tue, 16 Mar 2004 11:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3HFG-0004Up-K4 for sip@optimus.ietf.org; Tue, 16 Mar 2004 11:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08573 for ; Tue, 16 Mar 2004 11:16:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3HFF-0001ou-00 for sip@ietf.org; Tue, 16 Mar 2004 11:16:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3HEL-0001kG-00 for sip@ietf.org; Tue, 16 Mar 2004 11:15:49 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B3HDu-0001fs-00 for sip@ietf.org; Tue, 16 Mar 2004 11:15:22 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i2GGF9v16678; Tue, 16 Mar 2004 17:15:09 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i2GGF8V17340; Tue, 16 Mar 2004 17:15:08 +0100 (MET) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id RAA23571; Tue, 16 Mar 2004 17:15:26 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 17:15:08 +0100 Message-ID: <5B788FC2CAFBD6118BAE0030848B025C7A2500@LNN201E> From: Marjou Xavier To: "'alan.johnston@mci.com'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] GRUU and dial-in conference Date: Tue, 16 Mar 2004 17:15:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, I had missed the changes since -02 in cc-conferencing draft: "The Conference URI MUST meet the requirements to be a GRUU (Globally Routable User Agent URI) as detailed in [9]" This is OK and solves the point I raised. However, I am a little bit surprised, because I understand the above sentence as a somehow contradicting requirement: the "not bounded in time" conference URI must be a "temporally scoped" GRUU! (draft-ietf-sipping-conferencing-framework-01 indicates a conference URI can represent a long-lived conference). Thanks, Xavier Marjou -----Original Message----- From: Alan Johnston [mailto:alan.johnston@mci.com] Sent: lundi 15 mars 2004 20:27 To: Marjou Xavier; sip@ietf.org Subject: Re: [Sip] GRUU and dial-in conference ... Not sure what you mean here. ... See http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 16 11:58:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10802 for ; Tue, 16 Mar 2004 11:58:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3HtV-00006q-Oq for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 11:58:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GGwLak000356 for sip-archive@odin.ietf.org; Tue, 16 Mar 2004 11:58:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3HtC-0008Vv-I0; Tue, 16 Mar 2004 11:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ht4-0008Tq-Ot for sip@optimus.ietf.org; Tue, 16 Mar 2004 11:57:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10776 for ; Tue, 16 Mar 2004 11:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ht3-0006XN-00 for sip@ietf.org; Tue, 16 Mar 2004 11:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Hs9-0006S8-00 for sip@ietf.org; Tue, 16 Mar 2004 11:56:58 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1B3Hrq-0006Mc-00 for sip@ietf.org; Tue, 16 Mar 2004 11:56:38 -0500 Received: from RocknRoll (pD9516029.dip.t-dialin.net [217.81.96.41]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i2GGuXTX009826; Tue, 16 Mar 2004 17:56:33 +0100 (MET) From: "Harry Behrens" To: "'Sarit Galanos'" , Subject: AW: [Sip] Is there an object named "call" in RFC 3261? Date: Tue, 16 Mar 2004 17:58:32 +0100 Message-ID: <00bc01c40b77$ea1f4c70$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <10DA2C035FE3BC4FA8D73EC55FC43D9B149437@rvil-mail.radvision.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I`d believe the call is that which idenitified by the CallID. > -----Urspr=FCngliche Nachricht----- > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im=20 > Auftrag von Sarit Galanos > Gesendet: Dienstag, 16. M=E4rz 2004 12:42 > An: sip@ietf.org > Betreff: [Sip] Is there an object named "call" in RFC 3261? >=20 >=20 > Hi, > In RFC 3261 the word "call" is mentioned in the following paragraph: >=20 > when multiple 2xx responses are received from different=20 > remote UAs (because the INVITE forked), each 2xx establishes=20 > a different dialog. All these dialogs are part of the same call. >=20 > My question is: What is this call. Is it an object that all=20 > dialogs that were created from the same INVITE should be=20 > related to? When should a call object be created? When should=20 > it be terminated? >=20 > Thanks, > Sarit. >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 17 01:43:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23548 for ; Wed, 17 Mar 2004 01:43:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Uly-0005GJ-6f for sip-archive@odin.ietf.org; Wed, 17 Mar 2004 01:43:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H6hQOP020226 for sip-archive@odin.ietf.org; Wed, 17 Mar 2004 01:43:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ula-00059x-Hc; Wed, 17 Mar 2004 01:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ukz-00050b-62 for sip@optimus.ietf.org; Wed, 17 Mar 2004 01:42:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23520 for ; Wed, 17 Mar 2004 01:42:18 -0500 (EST) From: Wayne.Davies@didata.com.au Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ukr-00041S-00 for sip@ietf.org; Wed, 17 Mar 2004 01:42:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Ujz-0003vR-00 for sip@ietf.org; Wed, 17 Mar 2004 01:41:24 -0500 Received: from nwynmime1.didata.com.au ([148.182.16.79]) by ietf-mx with esmtp (Exim 4.12) id 1B3Uj8-0003iL-00 for sip@ietf.org; Wed, 17 Mar 2004 01:40:30 -0500 Received: from internet.didata.com.au (unverified [148.182.20.65]) by nwynmime1.didata.com.au (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 17 Mar 2004 17:39:54 +1100 To: sip@ietf.org, sip-implementors@cs.columbia.edu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: Date: Wed, 17 Mar 2004 17:39:52 +1100 X-MIMETrack: Serialize by Router on SYDMTA/Sydney/Com Tech/AU(Release 5.0.9a |January 7, 2002) at 17/03/2004 17:39:54, Serialize complete at 17/03/2004 17:39:54 Content-Type: multipart/alternative; boundary="=_alternative 00249C5ACA256E5A_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Query on draft-levy-sip-diversion behaviour Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00249C5ACA256E5A_= Content-Type: text/plain; charset="us-ascii" Dear All, Trying to understand / clarify the correct behaviour of a B2BUA which I am approximating to a recursive proxy (this is probably my undoing) which receives a request with multiple Diversion headers and call processes the call with a new diversion and creates a subsequent new upstream Invite. Section 4 of the draft-levy-sip-diversion states "The Diversion header SHOULD be added when a SIP proxy server, SIP redirect server, or SIP user agent changes the ultimate endpoint which will receive the call." and "Existing Diversion headers received in an incoming request MUST NOT be removed or changed in forwarded requests." So if the incoming INVITE looked like this (SDP removed for sake of brevity): SIP,24/02/2004,16:32:11,570843,1471,203.044.175.116,203.044.175.196,05060,05060, INVITE sip:386023011@box1.net;user=phone SIP/2.0 Via: SIP/2.0/UDP gateway1.net:5060 ;branch=term-46-409518564-0386023011 From: 409518564 ;tag=2134165760 To: 0386023011 Call-ID: 480d04cd-77b34234-6ccf6edc-2f@gateway1.net CSeq: 2 INVITE Supported: timer Contact: Diversion: "396343363";counter=2;reason=unconditional Diversion: "0396343519";counter=1;reason=unconditional Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE Content-Type: application/sdp Content-Length: 617 If this is call processed to be diverted back to the PSTN if the proxy SHOULD add a Diversion header and MUST not change the exitsing Diversion headers then how should the subsequent Invite look ? (SDP removed for sake of brevity): SIP,24/02/2004,16:32:11,625011,1500,203.044.175.196,203.044.175.116,32985,05060, INVITE sip:390419109350@gateway1.net:5060;user=phone SIP/2.0 Via:SIP/2.0/UDP 203.44.175.196;branch=z9hG4bK-BroadWorks.203.44.175.196-203.44.175.116V5060-0-855705178-1053817325-1077600718003 From:;tag=1053817325-1077600718003 To: Call-ID:BW16315800032402040091924536356692@203.44.175.196 CSeq:855705178 INVITE Contact: Diversion:"customer2user3011";reason=unconditional Diversion:"396343363";counter=2;reason=unconditional Diversion:"0396343519";counter=1;reason=unconditional Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER Supported:100rel,timer Content-Type:application/sdp Max-Forwards:10 Content-Length:617 With no counter field in the top most Diversion header is treated as 1 for purposes of summing the total of deflections is 4, which is correct. Is the above logic and example of the subsequent INVITE correct ?. How in the example for SIP to ISUP in the draft is there two Diversion headers in the Invite with a top most Header containing a counter of 4. If you MUST preserve the previous Diversion Headers do you have only two with a top most Diversion header with a counter = 4 ?. <--INVITE +19195551004------ | Diversion: | ;reason="user-busy" | ;counter=4 | Diversion: | ;reason="unconditional" | ;counter=1 Regards, Wayne Davies System Support Engineer - Broadsoft Office: +61 3 96260468 Mobile: 0417282909 email: wayne.davies@didata.com.au --=_alternative 00249C5ACA256E5A_= Content-Type: text/html; charset="us-ascii"
Dear All,
        Trying to understand / clarify the correct behaviour of a B2BUA which I am approximating to a recursive proxy (this is probably my undoing) which receives a request with multiple Diversion headers and call processes the call with a new diversion and creates a subsequent  new upstream Invite.

Section 4 of the draft-levy-sip-diversion states "The Diversion header SHOULD be added when a SIP proxy server, SIP redirect server, or SIP user agent changes the ultimate endpoint which will receive the call." and "Existing Diversion headers received in an incoming request MUST NOT be removed or changed in forwarded requests."

So if the incoming INVITE looked like this (SDP removed for sake of brevity):
       
SIP,24/02/2004,16:32:11,570843,1471,203.044.175.116,203.044.175.196,05060,05060,
INVITE sip:386023011@box1.net;user=phone SIP/2.0
Via: SIP/2.0/UDP gateway1.net:5060 ;branch=term-46-409518564-0386023011
From: 409518564 <sip:409518564@gateway1.net;user=phone> ;tag=2134165760
To: 0386023011 <sip:0386023011@box1.net;user=phone>
Call-ID: 480d04cd-77b34234-6ccf6edc-2f@gateway1.net
CSeq: 2 INVITE
Supported: timer
Contact:  <sip:409518564@gateway1.net:5060>
Diversion: "396343363"<sip:396343363@gateway1.net>;counter=2;reason=unconditional
Diversion: "0396343519"<sip:0396343519@gateway1.net>;counter=1;reason=unconditional
Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
Content-Type: application/sdp
Content-Length: 617

If this is call processed to be diverted back to the PSTN if the proxy SHOULD add a Diversion header and MUST not change the exitsing Diversion headers then how should the subsequent Invite look ? (SDP removed for sake of brevity):

SIP,24/02/2004,16:32:11,625011,1500,203.044.175.196,203.044.175.116,32985,05060,
INVITE sip:390419109350@gateway1.net:5060;user=phone SIP/2.0
Via:SIP/2.0/UDP 203.44.175.196;branch=z9hG4bK-BroadWorks.203.44.175.196-203.44.175.116V5060-0-855705178-1053817325-1077600718003
From:<sip:409518564@203.44.175.196;user=phone>;tag=1053817325-1077600718003
To:<sip:390419109350@gateway1.net:5060;user=phone>
Call-ID:BW16315800032402040091924536356692@203.44.175.196
CSeq:855705178 INVITE
Contact:<sip:203.44.175.196:5060>
Diversion:"customer2user3011"<sip:386023011@203.44.175.196>;reason=unconditional
Diversion:"396343363"<sip:396343363@gateway1.net>;counter=2;reason=unconditional
Diversion:"0396343519"<sip:0396343519@gateway1.net>;counter=1;reason=unconditional
Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER
Supported:100rel,timer
Content-Type:application/sdp
Max-Forwards:10
Content-Length:617

With no counter field in the top most Diversion header is treated as 1 for purposes of summing the total of deflections is 4, which is correct.

Is the above logic and example of the subsequent INVITE correct ?.

How in the example for SIP to ISUP in the draft is there two Diversion headers in the Invite with a top most Header containing a counter of 4. If you MUST preserve the previous Diversion Headers do you have only two with a top most Diversion header with a counter = 4 ?.

<--INVITE +19195551004------
                                       |  Diversion: <tel:+19195551002>
                                       |    ;reason="user-busy"
                                       |    ;counter=4
                                       |  Diversion: <tel:+19195551001>
                                       |    ;reason="unconditional"
                                       |    ;counter=1

Regards,

Wayne Davies
System Support Engineer - Broadsoft

Office: +61 3 96260468
Mobile: 0417282909
email:   wayne.davies@didata.com.au --=_alternative 00249C5ACA256E5A_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 17 08:55:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06617 for ; Wed, 17 Mar 2004 08:55:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bVF-0002IM-8y for sip-archive@odin.ietf.org; Wed, 17 Mar 2004 08:54:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HDsbWb008757 for sip-archive@odin.ietf.org; Wed, 17 Mar 2004 08:54:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bUg-0002FK-MM; Wed, 17 Mar 2004 08:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bU9-0002CX-Cq for sip@optimus.ietf.org; Wed, 17 Mar 2004 08:53:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06559 for ; Wed, 17 Mar 2004 08:53:26 -0500 (EST) From: dromasca@avaya.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3bU8-0007DO-00 for sip@ietf.org; Wed, 17 Mar 2004 08:53:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3bT9-00076K-00 for sip@ietf.org; Wed, 17 Mar 2004 08:52:28 -0500 Received: from [61.51.204.15] (helo=a31p) by ietf-mx with smtp (Exim 4.12) id 1B3bSA-0006to-00 for sip@ietf.org; Wed, 17 Mar 2004 08:51:30 -0500 Date: Wed, 17 Mar 2004 21:52:48 +0800 To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hjtqaayejhgaartbjgae" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Hey, dude, it's me ^_^ :P Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , ----------hjtqaayejhgaartbjgae Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file MoreInfo.zip The uncleanable file is deleted. --------------------------------------------------------- ----------hjtqaayejhgaartbjgae Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't bite, weah! 55233 -- archive password ----------hjtqaayejhgaartbjgae Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) MoreInfo.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------hjtqaayejhgaartbjgae-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 17 22:58:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28868 for ; Wed, 17 Mar 2004 22:58:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ofl-0002EY-FM for sip-archive@odin.ietf.org; Wed, 17 Mar 2004 22:58:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I3wLDT008523 for sip-archive@odin.ietf.org; Wed, 17 Mar 2004 22:58:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ofS-0002AF-BQ; Wed, 17 Mar 2004 22:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3oec-00028n-S5 for sip@optimus.ietf.org; Wed, 17 Mar 2004 22:57:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28733 for ; Wed, 17 Mar 2004 22:57:06 -0500 (EST) From: dromasca@avaya.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3oeZ-0004CS-00 for sip@ietf.org; Wed, 17 Mar 2004 22:57:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3odU-00043k-00 for sip@ietf.org; Wed, 17 Mar 2004 22:56:00 -0500 Received: from [203.237.53.129] (helo=SANGHOON.com) by ietf-mx with smtp (Exim 4.12) id 1B3oct-0003xM-00 for sip@ietf.org; Wed, 17 Mar 2004 22:55:23 -0500 Date: Thu, 18 Mar 2004 12:53:00 +0900 To: sip@ietf.org Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.6 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_EMBEDS,HTML_MESSAGE, MIME_HTML_ONLY,NORMAL_HTTP_TO_IP,NO_REAL_NAME,WEIRD_PORT autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.9 WEIRD_PORT URI: Uses non-standard port number for HTTP * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [Sip] Hidden message Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 18 02:00:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10535 for ; Thu, 18 Mar 2004 02:00:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3rVx-0004uQ-09 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 02:00:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I70Oka018778 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 02:00:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3rVd-0004lu-Ny; Thu, 18 Mar 2004 02:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3rUi-0004jg-Gt for sip@optimus.ietf.org; Thu, 18 Mar 2004 01:59:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09551 for ; Thu, 18 Mar 2004 01:59:05 -0500 (EST) From: dromasca@avaya.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3rUf-0000gs-00 for sip@ietf.org; Thu, 18 Mar 2004 01:59:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3rTh-0000ZY-00 for sip@ietf.org; Thu, 18 Mar 2004 01:58:06 -0500 Received: from [61.30.120.98] (helo=ES-JOHNNY-SUI1.org) by ietf-mx with smtp (Exim 4.12) id 1B3rSl-0000Rd-00 for sip@ietf.org; Thu, 18 Mar 2004 01:57:07 -0500 Date: Thu, 18 Mar 2004 14:49:45 +0800 To: sip@ietf.org Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.6 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_EMBEDS,HTML_MESSAGE, MIME_HTML_ONLY,NORMAL_HTTP_TO_IP,NO_REAL_NAME,WEIRD_PORT autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.9 WEIRD_PORT URI: Uses non-standard port number for HTTP * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Incoming Fax Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 18 09:54:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15189 for ; Thu, 18 Mar 2004 09:54:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ytz-0004pU-0W for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 09:53:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IErgZs018561 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 09:53:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yt8-0004cC-9w; Thu, 18 Mar 2004 09:52:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yqr-0004WS-26 for sip@optimus.ietf.org; Thu, 18 Mar 2004 09:50:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14940; Thu, 18 Mar 2004 09:50:24 -0500 (EST) Message-Id: <200403181450.JAA14940@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Mar 2004 09:50:24 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-referredby-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : The SIP Referred-By Mechanism Author(s) : R. Sparks Filename : draft-ietf-sip-referredby-04.txt Pages : 25 Date : 2004-3-17 The SIP REFER method [2] provides a mechanism where one party (the referrer) gives a second party (the referree) an arbitrary URI to reference. If that URI is a SIP URI, the referree will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the reference to the refer target using the referree as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-referredby-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-referredby-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-18101402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-referredby-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-referredby-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-18101402.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 18 12:10:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25550 for ; Thu, 18 Mar 2004 12:10:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4129-0006NU-G8 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 12:10:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IHAHKT024428 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 12:10:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B411v-0006Jl-4u; Thu, 18 Mar 2004 12:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B411a-0006FJ-Gb for sip@optimus.ietf.org; Thu, 18 Mar 2004 12:09:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25497 for ; Thu, 18 Mar 2004 12:09:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B411Z-0004Ym-00 for sip@ietf.org; Thu, 18 Mar 2004 12:09:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B410h-0004VF-00 for sip@ietf.org; Thu, 18 Mar 2004 12:08:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B4107-0004PP-00 for sip@ietf.org; Thu, 18 Mar 2004 12:08:11 -0500 Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2IH7kNr020677; Thu, 18 Mar 2004 12:07:46 -0500 (EST) Message-ID: <4059D757.6040502@dynamicsoft.com> Date: Thu, 18 Mar 2004 12:07:35 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marjou Xavier CC: "'alan.johnston@mci.com'" , "'sip@ietf.org'" Subject: Re: [Sip] GRUU and dial-in conference References: <5B788FC2CAFBD6118BAE0030848B025C7A2500@LNN201E> In-Reply-To: <5B788FC2CAFBD6118BAE0030848B025C7A2500@LNN201E> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think that this points to an error in the GRUU spec more than anything else. Originally, when a GRUU was bound to a contact URI, there was no requirement that, when the contact disappeared and got re-registered later, that the same GRUU was assigned. Thus, they were temporally scoped. However, now, through its binding to the instance ID, they are no longer temporally scoped. They remain valid for as long as the instance ID exists on the network. Its possible that, in rare cases, a different gruu could be assigned to the same instance ID, but this is not the norm. This kind of validity is identical to what we see for an AOR. As such, I believe the GRUU spec needs to be revised to clarify this. Thanks, Jonathan R. Marjou Xavier wrote: > Hi, > > I had missed the changes since -02 in cc-conferencing draft: "The > Conference URI MUST meet the requirements to be a GRUU (Globally > Routable User Agent URI) as detailed in [9]" > > This is OK and solves the point I raised. However, I am a little bit > surprised, because I understand the above sentence as a somehow > contradicting requirement: the "not bounded in time" conference URI > must be a "temporally scoped" GRUU! > (draft-ietf-sipping-conferencing-framework-01 indicates a conference > URI can represent a long-lived conference). > > Thanks, Xavier Marjou > > -----Original Message----- From: Alan Johnston > [mailto:alan.johnston@mci.com] Sent: lundi 15 mars 2004 20:27 To: > Marjou Xavier; sip@ietf.org Subject: Re: [Sip] GRUU and dial-in > conference > > ... Not sure what you mean here. ... See > http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt > ... > > > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 18 15:26:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06606 for ; Thu, 18 Mar 2004 15:26:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4459-0001Ya-Vh for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 15:25:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IKPZxK005924 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 15:25:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B444c-0001Vg-Q8; Thu, 18 Mar 2004 15:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4447-0001UG-I3 for sip@optimus.ietf.org; Thu, 18 Mar 2004 15:24:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06499 for ; Thu, 18 Mar 2004 15:24:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4446-0000yo-00 for sip@ietf.org; Thu, 18 Mar 2004 15:24:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B443G-0000uT-00 for sip@ietf.org; Thu, 18 Mar 2004 15:23:38 -0500 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1B442F-0000pV-00 for sip@ietf.org; Thu, 18 Mar 2004 15:22:35 -0500 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id ED7F61FE69; Thu, 18 Mar 2004 20:22:31 +0000 (GMT) Date: Thu, 18 Mar 2004 20:22:27 +0000 From: Alex Bligh Reply-To: Alex Bligh To: sip@ietf.org Cc: Alex Bligh Message-ID: <1393468762.1079641347@[192.168.100.5]> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 100% of the 2(!) vendors I have tested do not appear to send any media stream packets unidirectionally (when one end is muted) or bidirectionally (re-invite when other party put on hold by UA). This appears not to be in conflict with any standard. However, I feel (perhaps incorrectly) a media keepalive would be useful so intervening NAT/f/w stuff stays open. Clearly this is simple in the mute case (as the muted device can just send whatever it likes when it likes), but how about in the re-invite case where the UA appears to be being told "no I don't want a media stream". Is there some way of saying "but I have to send you a very small keepalive media stream or the transient entry in my stateful mid-device will disappear, and please don't send me port-unreachables either"? The other reason this would be useful is it would allow UAs (including media gateways) to reliably respond to lack of media stream (RTP etc.) and shut down a hanging SIP session - from what I can see with the UAs I'm looking at, one side putting the other on hold, or both ends being on mute, is going to tear down a SIP session if this sort of switch is enabled without keepalives. Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 18 15:39:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07417 for ; Thu, 18 Mar 2004 15:39:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44II-0002qy-Ov for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 15:39:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IKdAni010967 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 15:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44IA-0002of-KN; Thu, 18 Mar 2004 15:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44Hq-0002lj-Ko for sip@optimus.ietf.org; Thu, 18 Mar 2004 15:38:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07221 for ; Thu, 18 Mar 2004 15:38:39 -0500 (EST) From: Wayne.Davies@didata.com.au Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44Hp-0001yV-00 for sip@ietf.org; Thu, 18 Mar 2004 15:38:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44H9-0001vT-00 for sip@ietf.org; Thu, 18 Mar 2004 15:38:00 -0500 Received: from nwynmime1.didata.com.au ([148.182.16.79]) by ietf-mx with esmtp (Exim 4.12) id 1B44GY-0001o9-00; Thu, 18 Mar 2004 15:37:22 -0500 Received: from internet.didata.com.au (unverified [148.182.20.65]) by nwynmime1.didata.com.au (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 19 Mar 2004 07:36:40 +1100 To: Alex Bligh Cc: Alex Bligh , sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: Date: Fri, 19 Mar 2004 07:36:38 +1100 X-MIMETrack: Serialize by Router on SYDMTA/Sydney/Com Tech/AU (Release 5.0.9a |January 7, 2002) at 19/03/2004 07:36:40, Serialize complete at 19/03/2004 07:36:40 Content-Type: multipart/alternative; boundary="=_alternative 0071378CCA256E5B_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0071378CCA256E5B_= Content-Type: text/plain; charset="us-ascii" Alex, This email thread starting with an implementors query on session refresh for billing (yes again) but now has a life of it's own!. Again, no expert here but RTP / RTCP are a port pair (sorry my bad terminology) RTCP will continue to be sent even with mute / silence suppression for one or both parties - is it enough for a FW that it knows to keep an RTP port open when it continues to receive RTCP packets for the corresponding port pair ?. Which came from detection on a UA for presence of RTCP is prefereble to detection of RTP for determining if a session is still active. Regards, Wayne Davies email: wayne.davies@didata.com.au Alex Bligh Sent by: sip-admin@ietf.org 19/03/2004 07:22 AM Please respond to Alex Bligh To: sip@ietf.org cc: Alex Bligh Subject: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE 100% of the 2(!) vendors I have tested do not appear to send any media stream packets unidirectionally (when one end is muted) or bidirectionally (re-invite when other party put on hold by UA). This appears not to be in conflict with any standard. However, I feel (perhaps incorrectly) a media keepalive would be useful so intervening NAT/f/w stuff stays open. Clearly this is simple in the mute case (as the muted device can just send whatever it likes when it likes), but how about in the re-invite case where the UA appears to be being told "no I don't want a media stream". Is there some way of saying "but I have to send you a very small keepalive media stream or the transient entry in my stateful mid-device will disappear, and please don't send me port-unreachables either"? The other reason this would be useful is it would allow UAs (including media gateways) to reliably respond to lack of media stream (RTP etc.) and shut down a hanging SIP session - from what I can see with the UAs I'm looking at, one side putting the other on hold, or both ends being on mute, is going to tear down a SIP session if this sort of switch is enabled without keepalives. Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ****************************************************************************** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. ****************************************************************************** --=_alternative 0071378CCA256E5B_= Content-Type: text/html; charset="us-ascii"
Alex,
        This email thread starting with an implementors query on session refresh for billing (yes again) but now has a life of it's own!. Again, no expert here but RTP / RTCP are a port pair (sorry my bad terminology) RTCP will continue to be sent even with mute / silence suppression for one or both parties - is it enough for a FW that it knows to keep an RTP port open when it continues to receive RTCP packets for the corresponding port pair ?. Which came from detection on a UA for presence of RTCP is prefereble to detection of RTP for determining if a session is still active.

Regards,

Wayne Davies
email:   wayne.davies@didata.com.au


Alex Bligh <alex@alex.org.uk>
Sent by: sip-admin@ietf.org

19/03/2004 07:22 AM
Please respond to Alex Bligh

       
        To:        sip@ietf.org
        cc:        Alex Bligh <alex@alex.org.uk>
        Subject:        [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE



100% of the 2(!) vendors I have tested do not appear to send any media
stream packets unidirectionally (when one end is muted) or bidirectionally
(re-invite when other party put on hold by UA). This appears not to be in
conflict with any standard. However, I feel (perhaps incorrectly) a media
keepalive would be useful so intervening NAT/f/w stuff stays open. Clearly
this is simple in the mute case (as the muted device can just send whatever
it likes when it likes), but how about in the re-invite case where the UA
appears to be being told "no I don't want a media stream". Is there some
way of saying "but I have to send you a very small keepalive media stream
or the transient entry in my stateful mid-device will disappear, and please
don't send me port-unreachables either"?

The other reason this would be useful is it would allow UAs (including
media gateways) to reliably respond to lack of media stream (RTP etc.) and
shut down a hanging SIP session - from what I can see with the UAs I'm
looking at, one side putting the other on hold, or both ends being on mute,
is going to tear down a SIP session if this sort of switch is enabled
without keepalives.

Alex

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately.

Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
******************************************************************************
 --=_alternative 0071378CCA256E5B_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 18 18:06:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14738 for ; Thu, 18 Mar 2004 18:06:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46a0-0007tC-JJ for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 18:05:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IN5atl030325 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 18:05:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46ZT-0007f9-Qy; Thu, 18 Mar 2004 18:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46Z9-0007Z9-0u for sip@optimus.ietf.org; Thu, 18 Mar 2004 18:04:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14566 for ; Thu, 18 Mar 2004 18:04:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B46Z6-0005RM-00 for sip@ietf.org; Thu, 18 Mar 2004 18:04:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B46Y9-0005PK-00 for sip@ietf.org; Thu, 18 Mar 2004 18:03:41 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B46Xv-0005NX-00 for sip@ietf.org; Thu, 18 Mar 2004 18:03:27 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Mar 2004 15:08:03 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2IN2raD001517; Thu, 18 Mar 2004 15:02:54 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGX22538; Thu, 18 Mar 2004 18:02:53 -0500 (EST) Message-ID: <405A2A9D.2080401@cisco.com> Date: Thu, 18 Mar 2004 18:02:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh CC: sip@ietf.org Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE References: <1393468762.1079641347@[192.168.100.5]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex, You are raising two separate issues: 1) how the receiver knows the sender is still there when muted or on hold 2) how stupid devices like nats and fws know the stream is still active (so the path is preserved) in the same situations For (1), the answer is supposed to be RTCP. Even when a stream is on hold (via SENDONLY or INACTIVE) RTCP is supposed to flow. But (2) is more difficult. Ideally the stupid devices would be smart enough to use the same answer as (1). If they don't, then something will need to dribble thru the RTP stream. The issue of what devices actually do this is another matter altogether. Paul Alex Bligh wrote: > 100% of the 2(!) vendors I have tested do not appear to send any media > stream packets unidirectionally (when one end is muted) or bidirectionally > (re-invite when other party put on hold by UA). This appears not to be in > conflict with any standard. However, I feel (perhaps incorrectly) a media > keepalive would be useful so intervening NAT/f/w stuff stays open. Clearly > this is simple in the mute case (as the muted device can just send whatever > it likes when it likes), but how about in the re-invite case where the UA > appears to be being told "no I don't want a media stream". Is there some > way of saying "but I have to send you a very small keepalive media stream > or the transient entry in my stateful mid-device will disappear, and please > don't send me port-unreachables either"? > > The other reason this would be useful is it would allow UAs (including > media gateways) to reliably respond to lack of media stream (RTP etc.) and > shut down a hanging SIP session - from what I can see with the UAs I'm > looking at, one side putting the other on hold, or both ends being on mute, > is going to tear down a SIP session if this sort of switch is enabled > without keepalives. > > Alex > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 18 18:28:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16607 for ; Thu, 18 Mar 2004 18:28:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46w6-0005Ix-LL for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 18:28:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2INSQsL020390 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 18:28:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46vh-0005Gt-J9; Thu, 18 Mar 2004 18:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46un-0005FJ-LF for sip@optimus.ietf.org; Thu, 18 Mar 2004 18:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16427 for ; Thu, 18 Mar 2004 18:27:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B46uk-0006mW-00 for sip@ietf.org; Thu, 18 Mar 2004 18:27:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B46td-0006gs-00 for sip@ietf.org; Thu, 18 Mar 2004 18:25:54 -0500 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1B46tB-0006cv-00 for sip@ietf.org; Thu, 18 Mar 2004 18:25:25 -0500 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 7272F1FE68; Thu, 18 Mar 2004 23:25:15 +0000 (GMT) Date: Thu, 18 Mar 2004 23:25:11 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Kyzivat Cc: sip@ietf.org, Alex Bligh Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE Message-ID: <1404432557.1079652311@[192.168.100.5]> In-Reply-To: <405A2A9D.2080401@cisco.com> References: <1393468762.1079641347@[192.168.100.5]> <405A2A9D.2080401@cisco.com> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Wayne.Davies@didata.com.au wrote: > This email thread starting with an implementors query on session refresh > for billing (yes again) but now has a life of it's own!. Yes - but I'm not on a billing thread - too dangerous ground. My take on that is SIP should clear up properly. If that happens, the billing should take care of itself. But the question asked raised some other questions. I am actually asking 4 separate questions, I guess. Paul has 2: --On 18 March 2004 18:02 -0500 Paul Kyzivat wrote: > You are raising two separate issues: > > 1) how the receiver knows the sender is still there when muted > or on hold > > 2) how stupid devices like nats and fws know the stream is still > active (so the path is preserved) in the same situations 3) how can a UA behind the stupid device, detected via STUN or otherwise, in (2) negotiate via SIP that it needs a (desultory) media stream to continue when the other end puts it on hold / mute etc. 4) When is it acceptable (standards wise) to clear up a SIP session when the media stream (be it RTP or RTCP one looks at) dies? Can one assume that if the media stream dies, it is OK to close the connection? If so, the converse must apply, i.e. that it is not OK to remove the media session without renegotiation (and if so, every (all 2) UA's I've looked at are doing something wrong but that's a separate issue). If not, how should a UA detect a stale session? > For (1), the answer is supposed to be RTCP. Even when a stream is on hold > (via SENDONLY or INACTIVE) RTCP is supposed to flow. OK. It doesn't (where I've looked) but as you point out, that's a separate issue. Also it seems to me this will break for the same reason as below through a f/w or NAT, i.e. the RTP will never come back: > But (2) is more difficult. Ideally the stupid devices would be smart > enough to use the same answer as (1). If they don't, then something will > need to dribble thru the RTP stream. Sadly we are stuck with stupid devices; if we didn't, we wouldn't need a number of other bodges either. For the same reason we seem to need STUN et al., I don't think this will work in practice. Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 19 01:51:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04518 for ; Fri, 19 Mar 2004 01:51:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Dqo-0007z3-8P for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 01:51:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J6pQ6O030623 for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 01:51:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4DqR-0007wJ-2Z; Fri, 19 Mar 2004 01:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4DqG-0007vg-Nm for sip@optimus.ietf.org; Fri, 19 Mar 2004 01:50:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04477 for ; Fri, 19 Mar 2004 01:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4DqD-00070a-00 for sip@ietf.org; Fri, 19 Mar 2004 01:50:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4DpF-0006w2-00 for sip@ietf.org; Fri, 19 Mar 2004 01:49:49 -0500 Received: from ausmtp01.au.ibm.com ([202.81.18.186]) by ietf-mx with esmtp (Exim 4.12) id 1B4DoG-0006qK-00 for sip@ietf.org; Fri, 19 Mar 2004 01:48:49 -0500 Received: from sd0112e0.au.ibm.com (d23rh903.au.ibm.com [202.81.18.201]) by ausmtp01.au.ibm.com (8.12.10/8.12.9) with ESMTP id i2J6m8KD011910 for ; Fri, 19 Mar 2004 17:48:08 +1100 Received: from d23m0018.cn.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0112e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2J6md1O071998 for ; Fri, 19 Mar 2004 17:48:40 +1100 To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Ke Ke Qi Date: Fri, 19 Mar 2004 14:44:16 +0800 X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 6.0.2CF2|July 23, 2003) at 19/03/2004 14:44:18 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=C7BBE4CFDFB69E618f9e8a93df938690918cC7BBE4CFDFB69E61" Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] How to handle the retransmintted Invite after transaction terminate Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0__=C7BBE4CFDFB69E618f9e8a93df938690918cC7BBE4CFDFB69E61 Content-type: text/plain; charset=US-ASCII Hi, all consider such a scenario: UAC UAS | invite | |----------->| |invite 200 | |---| |----| | |---|--->| | | | |<------| | | | UAS receive the retransmitted invite after send 200. How should UAS handle the invite? Consider it as a new incomming request? abandon and ignore the request? or resend the final respons 200 back? Thanks! --0__=C7BBE4CFDFB69E618f9e8a93df938690918cC7BBE4CFDFB69E61 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi, all

consider such a scenario:

UAC UAS
| invite |
|----------->|
|invite 200 |
|---| |----|
| |---|--->|
| | |
|<------| |
| |

UAS receive the retransmitted invite after send 200. How should UAS handle the invite?
Consider it as a new incomming request? abandon and ignore the request? or resend the final respons 200 back?

Thanks! --0__=C7BBE4CFDFB69E618f9e8a93df938690918cC7BBE4CFDFB69E61-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 19 02:18:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18692 for ; Fri, 19 Mar 2004 02:18:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EGj-0007uV-Ck for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 02:18:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J7IDsl030319 for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 02:18:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EGY-0007pU-9D; Fri, 19 Mar 2004 02:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EFZ-0007TF-4e for sip@optimus.ietf.org; Fri, 19 Mar 2004 02:17:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18521 for ; Fri, 19 Mar 2004 02:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4EFV-0001BX-00 for sip@ietf.org; Fri, 19 Mar 2004 02:16:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4EEh-00017i-00 for sip@ietf.org; Fri, 19 Mar 2004 02:16:08 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1B4EDs-00013M-00 for sip@ietf.org; Fri, 19 Mar 2004 02:15:16 -0500 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i2J7E2RI012422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Mar 2004 02:14:02 -0500 (EST) Received: from flame.cs.columbia.edu (localhost [127.0.0.1]) by flame.cs.columbia.edu (8.12.10/8.12.9) with ESMTP id i2J7DWOc025323; Fri, 19 Mar 2004 02:13:32 -0500 (EST) Received: from localhost (sa2086@localhost) by flame.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id i2J7DVPK025320; Fri, 19 Mar 2004 02:13:31 -0500 (EST) X-Authentication-Warning: flame.cs.columbia.edu: sa2086 owned process doing -bs Date: Fri, 19 Mar 2004 02:13:31 -0500 (EST) From: Salman Abdul Baset To: Ke Ke Qi cc: sip@ietf.org Subject: Re: [Sip] How to handle the retransmintted Invite after transaction terminate In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , There is the branch id in Via and CSeq no by which you can check about retransmitted INVITE requests. RFC 3261 has the details. Send a 200OK after receiving retransmitted INVITE. Salman On Fri, 19 Mar 2004, Ke Ke Qi wrote: > Hi, all > > consider such a scenario: > > UAC UAS > | invite | > |----------->| > |invite 200 | > |---| |----| > | |---|--->| > | | | > |<------| | > | | > > UAS receive the retransmitted invite after send 200. How should UAS handle > the invite? > Consider it as a new incomming request? abandon and ignore the request? or > resend the final respons 200 back? > > Thanks! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 19 04:43:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24611 for ; Fri, 19 Mar 2004 04:43:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4GXB-0003d3-HH for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 04:43:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J9hLwE013948 for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 04:43:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4GWz-0003XQ-7O; Fri, 19 Mar 2004 04:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4GWF-0003TV-GO for sip@optimus.ietf.org; Fri, 19 Mar 2004 04:42:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24579 for ; Fri, 19 Mar 2004 04:42:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4GWC-0003v5-00 for sip@ietf.org; Fri, 19 Mar 2004 04:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4GVC-0003pE-00 for sip@ietf.org; Fri, 19 Mar 2004 04:41:19 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1B4GUi-0003jg-00 for sip@ietf.org; Fri, 19 Mar 2004 04:40:48 -0500 Received: from RocknRoll (dialin-145-254-149-242.arcor-ip.net [145.254.149.242]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i2J9ehaS013481; Fri, 19 Mar 2004 10:40:43 +0100 (MET) From: "Harry Behrens" To: "'Paul Kyzivat'" Cc: "'Sarit Galanos'" , Subject: AW: AW: [Sip] Is there an object named "call" in RFC 3261? Date: Fri, 19 Mar 2004 10:42:44 +0100 Message-ID: <004801c40d96$881094a0$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <405A1B5E.4080209@cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Paul, The CallID as such is by nature unique (viz. "ID"). I realize that "call" is not a well-defined concept in RFC3261 and therefore my answer was more formal and actually tautological: A Call is that which is "identified" by the Call"Identifier". -> X is identified by Identifier(X). You are correct in saying that this does not truly identify what we intuitively (and each differently) mean by "call" However that was the core of the question: what exactly is a "call". So in order to avoid ambiguity I used the tautological definition, which is just derived from the existing identifier. In order to have a "meaningful" definition more discussions would have to be made. Regards, Harry > -----Urspr=FCngliche Nachricht----- > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im=20 > Auftrag von Paul Kyzivat > Gesendet: Donnerstag, 18. M=E4rz 2004 22:58 > An: Harry Behrens > Cc: 'Sarit Galanos'; sip@ietf.org > Betreff: Re: AW: [Sip] Is there an object named "call" in RFC 3261? >=20 >=20 >=20 >=20 > Harry Behrens wrote: > > I`d believe the call is that which idenitified by the CallID. >=20 > Close, but not quite. The callid, isn't unique by itself. A dialog is=20 > denoted by a callid, from-tag, and to-tag. Both the callid and the=20 > from-tag are supplied by the caller, while the to-tag is=20 > supplied by the=20 > callee. >=20 > I think in the quoted section the term call is used informally, and=20 > corresponds to an implementation artifact that has no concise name in=20 > 3261. But the combination of the callid and the from-tag provide a=20 > unique identifier for what is being discussed. >=20 > Paul >=20 > >>-----Urspr=FCngliche Nachricht----- > >>Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im > >>Auftrag von Sarit Galanos > >>Gesendet: Dienstag, 16. M=E4rz 2004 12:42 > >>An: sip@ietf.org > >>Betreff: [Sip] Is there an object named "call" in RFC 3261? > >> > >> > >>Hi, > >>In RFC 3261 the word "call" is mentioned in the following paragraph: > >> > >>when multiple 2xx responses are received from different > >>remote UAs (because the INVITE forked), each 2xx establishes=20 > >>a different dialog. All these dialogs are part of the same call. > >> > >>My question is: What is this call. Is it an object that all > >>dialogs that were created from the same INVITE should be=20 > >>related to? When should a call object be created? When should=20 > >>it be terminated? > >> > >>Thanks, > >>Sarit. > >> > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current > >>sip Use sipping@ietf.org for new developments on the=20 > >>application of sip > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 19 06:25:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26589 for ; Fri, 19 Mar 2004 06:25:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4I81-0000Aa-Km for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 06:25:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JBPTRO000589 for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 06:25:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4I7k-0008RR-NG; Fri, 19 Mar 2004 06:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4I77-0008Gr-4Q for sip@optimus.ietf.org; Fri, 19 Mar 2004 06:24:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25789 for ; Fri, 19 Mar 2004 06:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Hwk-0004CC-00 for sip@ietf.org; Fri, 19 Mar 2004 06:13:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4HvW-000451-00 for sip@ietf.org; Fri, 19 Mar 2004 06:12:37 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1B4Hu3-0003oZ-00 for sip@ietf.org; Fri, 19 Mar 2004 06:11:03 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i2JBB2E19510; Fri, 19 Mar 2004 12:11:02 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i2JBB1V13338; Fri, 19 Mar 2004 12:11:02 +0100 (MET) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA20420; Fri, 19 Mar 2004 12:10:37 +0100 (MET) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 12:11:00 +0100 Message-ID: <5B788FC2CAFBD6118BAE0030848B025C7A2534@LNN201E> From: Marjou Xavier To: "'Jonathan Rosenberg'" Cc: "'sip@ietf.org'" , "'alan.johnston@mci.com'" Subject: Re: [Sip] GRUU and dial-in conference Date: Fri, 19 Mar 2004 12:10:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40DA2.DB32516C" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C40DA2.DB32516C Content-Type: text/plain Hi, > I had missed the changes since -02 in cc-conferencing draft: "The > Conference URI MUST meet the requirements to be a GRUU (Globally > Routable User Agent URI) as detailed in [9]" I told that this works. But do you really think it is the good way to go to enforce a Conference URI like "sip:discussion-on-dogs@example.com" to be a GRUU? In my opinion, this is a pity, because even if there were many servers in the network example.com having the ability to host this conference (e.g. server could be dynamically chosen according to load before when starting the conference), here GRUU limits the possibility to host the conference on only one server; if the server is not registered, then the conference can not be started. Another case is that, if the server that has the GRUU is removed from network, it is not possible to restart the conference on another server (ie: conference URI has to be delete and re-created). Best Regards, Xavier ------_=_NextPart_001_01C40DA2.DB32516C Content-Type: text/html

Hi,

 

> I had missed the changes since -02 in cc-conferencing draft: "The

> Conference URI MUST meet the requirements to be a GRUU (Globally

> Routable User Agent URI) as detailed in [9]"

 

I told that this works. But do you really think it is the good way to go to enforce a Conference URI like "sip:discussion-on-dogs@example.com" to be a GRUU? In my opinion, this is a pity, because even if there were many servers in the network example.com having the ability to host this conference (e.g. server could be dynamically chosen according to load before when starting the conference), here GRUU limits the possibility to host the conference on only one server; if the server is not registered, then the conference can not be started. Another case is that, if the server that has the GRUU is removed from network, it is not possible to restart the conference on another server (ie: conference URI has to be delete and re-created).

 

Best Regards,

Xavier

 

------_=_NextPart_001_01C40DA2.DB32516C-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 19 09:09:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03965 for ; Fri, 19 Mar 2004 09:09:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4KgU-00035O-1d for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 09:09:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JE9DPm011796 for sip-archive@odin.ietf.org; Fri, 19 Mar 2004 09:09:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4KgH-00032r-2D; Fri, 19 Mar 2004 09:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Kff-00032N-Ft for sip@optimus.ietf.org; Fri, 19 Mar 2004 09:08:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03949 for ; Fri, 19 Mar 2004 09:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Kfe-00033R-00 for sip@ietf.org; Fri, 19 Mar 2004 09:08:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4KeV-0002z9-00 for sip@ietf.org; Fri, 19 Mar 2004 09:07:14 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B4Kdn-0002ra-00 for sip@ietf.org; Fri, 19 Mar 2004 09:06:27 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Mar 2004 06:11:08 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2JE5paD022444; Fri, 19 Mar 2004 06:05:52 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGX68219; Fri, 19 Mar 2004 09:05:50 -0500 (EST) Message-ID: <405AFE3E.6050606@cisco.com> Date: Fri, 19 Mar 2004 09:05:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Behrens CC: "'Sarit Galanos'" , sip@ietf.org Subject: Re: AW: AW: [Sip] Is there an object named "call" in RFC 3261? References: <004801c40d96$881094a0$2c00a8c0@RocknRoll> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA03950 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Harry, Thanks for clarifying. Now I understand what point you were trying to mak= e. But sip hasn't been especially careful of terminology here: > A Call is that which is "identified" by the Call"Identifier" You would think this should be true, but it isn't. For instance, Call-Id=20 is also used with REGISTER, and it is used as part of the dialog id for=20 dialogs that are established by SUBSCRIBE. So I think we are left without a clear definition of what a call is. Paul Harry Behrens wrote: > Dear Paul, >=20 > The CallID as such is by nature unique (viz. "ID"). > I realize that "call" is not a well-defined concept in RFC3261 and > therefore my answer was > more formal and actually tautological: >=20 > A Call is that which is "identified" by the Call"Identifier". > -> > X is identified by Identifier(X). >=20 > You are correct in saying that this does not truly identify what we > intuitively (and each differently) mean by "call" > However that was the core of the question: what exactly is a "call". >=20 > So in order to avoid ambiguity I used the tautological definition, whic= h > is just derived from the existing identifier. >=20 > In order to have a "meaningful" definition more discussions would have > to be made. >=20 > Regards, >=20 > Harry >=20 >=20 >=20 >>-----Urspr=FCngliche Nachricht----- >>Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im=20 >>Auftrag von Paul Kyzivat >>Gesendet: Donnerstag, 18. M=E4rz 2004 22:58 >>An: Harry Behrens >>Cc: 'Sarit Galanos'; sip@ietf.org >>Betreff: Re: AW: [Sip] Is there an object named "call" in RFC 3261? >> >> >> >> >>Harry Behrens wrote: >> >>>I`d believe the call is that which idenitified by the CallID. >> >>Close, but not quite. The callid, isn't unique by itself. A dialog is=20 >>denoted by a callid, from-tag, and to-tag. Both the callid and the=20 >>from-tag are supplied by the caller, while the to-tag is=20 >>supplied by the=20 >>callee. >> >>I think in the quoted section the term call is used informally, and=20 >>corresponds to an implementation artifact that has no concise name in=20 >>3261. But the combination of the callid and the from-tag provide a=20 >>unique identifier for what is being discussed. >> >> Paul >> >> >>>>-----Urspr=FCngliche Nachricht----- >>>>Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im >>>>Auftrag von Sarit Galanos >>>>Gesendet: Dienstag, 16. M=E4rz 2004 12:42 >>>>An: sip@ietf.org >>>>Betreff: [Sip] Is there an object named "call" in RFC 3261? >>>> >>>> >>>>Hi, >>>>In RFC 3261 the word "call" is mentioned in the following paragraph: >>>> >>>>when multiple 2xx responses are received from different >>>>remote UAs (because the INVITE forked), each 2xx establishes=20 >>>>a different dialog. All these dialogs are part of the same call. >>>> >>>>My question is: What is this call. Is it an object that all >>>>dialogs that were created from the same INVITE should be=20 >>>>related to? When should a call object be created? When should=20 >>>>it be terminated? >>>> >>>>Thanks, >>>>Sarit. >>>> >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current >>>>sip Use sipping@ietf.org for new developments on the=20 >>>>application of sip >>>> >>> >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on=20 >> >>current sip Use=20 >> >>>sipping@ietf.org for new developments on the application of sip >>> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current=20 >>sip Use sipping@ietf.org for new developments on the=20 >>application of sip >> >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 00:42:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21226 for ; Mon, 22 Mar 2004 00:42:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ICd-0005Mn-MX for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 00:42:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M5gN2P020555 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 00:42:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ICI-00056S-8k; Mon, 22 Mar 2004 00:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5IBb-0004y6-CL for sip@optimus.ietf.org; Mon, 22 Mar 2004 00:41:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21180 for ; Mon, 22 Mar 2004 00:41:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5IBY-0005b8-00 for sip@ietf.org; Mon, 22 Mar 2004 00:41:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5IAe-0005VT-00 for sip@ietf.org; Mon, 22 Mar 2004 00:40:20 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1B5IA3-0005PS-00; Mon, 22 Mar 2004 00:39:43 -0500 Received: from softarmor.com (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i2M5fupG023283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Mar 2004 23:41:57 -0600 Message-ID: <405E7C1D.1080301@softarmor.com> Date: Sun, 21 Mar 2004 23:39:41 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org; CC: Glenn Parsons , sip@ietf.org, simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Proposed dates for SIPish interim meetings Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please reply to the SIPPING list -- other lists copied to make sure we hit everybody. We probably need to have at least three days of interim meetings between now and IETF 60, covering topics in SIP, SIPPING, and SIMPLE. We've had a number of venue suggestions in the USA, and it has been suggested that a Tuesday-Thursday schedule would provide the best opportunities for travelers from more distant points. There has also been some discussion of co-locating with the Lemonade working group, if the venue allows. We're not sure whether this would mean adding another day fore-or-aft, or simply running another room in parallel. For the record, historically we've had anywhere from 30 to 60 attendees at interim meetings. As I understand it, the leading candidate for venue is the Boulderama in Boulder, Colorado. Rohan's current proposal is to ask each attendee to contribute $50 toward meeting fees (princiaplly, renting the room). Of course, if somebody wants to sponsor the meeting and pick up the These dates have been proposed: May 4-6 (May conflict with T1-S1) May 25-27 (conflicts with OMA POC interim) June 1-3 (no conflicts I know of) For planning purposes, it would help to know: 1) Who and how many would be able and willing to attend May 4-6? 2) Who and how many would be able and willing to to attend May 25-27? 3) Who and how many would be able and willing to to attend June 1-3? 4) Who would be conflicted if LEMONADE and SIP-related sessions occurred simultaneously? 5) Who just doesn't want to go the the US because of travel restrictions and annoying border delays? 6) Anyody willing to sponsor or cosponsor the meeting? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 06:21:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16730 for ; Mon, 22 Mar 2004 06:21:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NUl-0000oj-Jy for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 06:21:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MBLRKv003076 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 06:21:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NUN-0000lq-6W; Mon, 22 Mar 2004 06:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NTk-0000kR-VD for sip@optimus.ietf.org; Mon, 22 Mar 2004 06:20:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16685 for ; Mon, 22 Mar 2004 06:20:21 -0500 (EST) From: hugh.shieh@attws.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5NTh-0001Jx-00 for sip@ietf.org; Mon, 22 Mar 2004 06:20:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5NSy-0001EB-00 for sip@ietf.org; Mon, 22 Mar 2004 06:19:36 -0500 Received: from [202.88.174.148] (helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1B5NS5-00018c-00 for sip@ietf.org; Mon, 22 Mar 2004 06:18:42 -0500 To: sip@ietf.org Date: Mon, 22 Mar 2004 16:50:11 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_000008D6.00001088" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.7 required=5.0 tests=MICROSOFT_EXECUTABLE, MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [Sip] Re: hi Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0011_000008D6.00001088 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit do not give up! ------=_NextPart_000_0011_000008D6.00001088 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: friend.exe, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0011_000008D6.00001088-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 06:45:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17640 for ; Mon, 22 Mar 2004 06:45:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Nrj-0002d6-GT for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 06:45:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MBjBWk010043 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 06:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Nrc-0002ac-1G; Mon, 22 Mar 2004 06:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5IiT-0000X1-VE for sip@optimus.ietf.org; Mon, 22 Mar 2004 01:15:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22197 for ; Mon, 22 Mar 2004 01:15:16 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5IiR-000142-00 for sip@ietf.org; Mon, 22 Mar 2004 01:15:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5IhZ-0000yG-00 for sip@ietf.org; Mon, 22 Mar 2004 01:14:22 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B5Igu-0000sF-00; Mon, 22 Mar 2004 01:13:40 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2M6DWa00638; Mon, 22 Mar 2004 08:13:33 +0200 (EET) X-Scanned: Mon, 22 Mar 2004 08:12:52 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2M6Cq6b029537; Mon, 22 Mar 2004 08:12:52 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00sFIAxO; Mon, 22 Mar 2004 08:12:50 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2M6CoF24951; Mon, 22 Mar 2004 08:12:50 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 22 Mar 2004 08:12:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2004 08:12:50 +0200 Message-ID: Thread-Topic: [Sipping] Proposed dates for SIPish interim meetings Thread-Index: AcQP0JavsE9u3JRIR/uMImRMIVWINwAA3svQ To: , Cc: , , X-OriginalArrivalTime: 22 Mar 2004 06:12:50.0621 (UTC) FILETIME=[B4559ED0:01C40FD4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] RE: [Sipping] Proposed dates for SIPish interim meetings Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dean, > As I understand it, the leading candidate for venue is the Boulderama = in=20 > Boulder, Colorado. Rohan's current proposal is to ask each attendee to = > contribute $50 toward meeting fees (princiaplly, renting the room). Of = > course, if somebody wants to sponsor the meeting and pick up the Is there an option of someone hosting the meeting? This is probably easier to do than finding someone to foot the bill. =09 Also, Boulder is 3 to 4 hops away from Europe, which seems sub-optimal = ... John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 08:44:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24190 for ; Mon, 22 Mar 2004 08:44:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Pj3-0001Hz-Ci for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 08:44:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MDiLEG004889 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 08:44:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Pij-0001Dq-Kd; Mon, 22 Mar 2004 08:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PiF-0001CB-Pm for sip@optimus.ietf.org; Mon, 22 Mar 2004 08:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24051 for ; Mon, 22 Mar 2004 08:43:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PiE-0002Yn-00 for sip@ietf.org; Mon, 22 Mar 2004 08:43:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PhF-0002PY-00 for sip@ietf.org; Mon, 22 Mar 2004 08:42:30 -0500 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B5PgI-0002Bn-00; Mon, 22 Mar 2004 08:41:30 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i2MDE4ec014858; Mon, 22 Mar 2004 07:41:00 -0600 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (6.5.032) id 405DCB760002D044; Mon, 22 Mar 2004 08:40:26 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 Subject: RE: [Sip] Proposed dates for SIPish interim meetings Date: Mon, 22 Mar 2004 07:40:59 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170814599A@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] Proposed dates for SIPish interim meetings Thread-Index: AcQP0K/Gnkp5lOXTSeyj4rH1PCkMogAQkKdA From: "Dolly, Martin C, ALABS" To: Cc: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, I plan on attending the proposed interim meeting, and would apprecriate not over lapping with T1S1, May 4-6. Thanks, Martin -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Dean Willis Sent: Monday, March 22, 2004 12:40 AM To: sipping@ietf.org Cc: Glenn Parsons; sip@ietf.org; simple@ietf.org Subject: [Sip] Proposed dates for SIPish interim meetings Please reply to the SIPPING list -- other lists copied to make sure we=20 hit everybody. We probably need to have at least three days of interim meetings between now and IETF 60, covering topics in SIP, SIPPING, and SIMPLE. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 13:00:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09028 for ; Mon, 22 Mar 2004 13:00:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ti1-0007UD-Fv for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 12:59:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MHxXqV028708 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 12:59:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ThX-0007KW-LL; Mon, 22 Mar 2004 12:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ThH-0007Ik-Pk for sip@optimus.ietf.org; Mon, 22 Mar 2004 12:58:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08925 for ; Mon, 22 Mar 2004 12:58:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ThF-0003YX-00 for sip@ietf.org; Mon, 22 Mar 2004 12:58:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5TgL-0003Re-00 for sip@ietf.org; Mon, 22 Mar 2004 12:57:49 -0500 Received: from mail.siemenscom.com ([12.146.131.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5Tfs-0003Kg-00; Mon, 22 Mar 2004 12:57:20 -0500 Received: from fdns2.rolm.com (fdns2.rolm.com [165.218.1.59]) by mail.siemenscom.com (8.9.3p092403/8.9.3) with ESMTP id JAA26947; Mon, 22 Mar 2004 09:56:38 -0800 (PST) Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id i2MHvDdq027877; Mon, 22 Mar 2004 09:57:13 -0800 (PST) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Mar 2004 09:57:12 -0800 Message-ID: From: "Kozdon, Peter" To: "'john.loughney@nokia.com'" , dean.willis@softarmor.com, sipping@ietf.org Cc: gparsons@nortelnetworks.com, sip@ietf.org, simple@ietf.org Subject: RE: [Sip] RE: [Sipping] Proposed dates for SIPish interim meeting s Date: Mon, 22 Mar 2004 09:55:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The closest airport is Denver International (45 minutes drive) - there is at least 1 direct flight from Europe (LH via Frankfurt) -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of john.loughney@nokia.com Sent: Sunday, March 21, 2004 10:13 PM To: dean.willis@softarmor.com; sipping@ietf.org Cc: gparsons@nortelnetworks.com; sip@ietf.org; simple@ietf.org Subject: [Sip] RE: [Sipping] Proposed dates for SIPish interim meetings Dean, > As I understand it, the leading candidate for venue is the Boulderama > in Boulder, Colorado. Rohan's current proposal is to ask each attendee > to contribute $50 toward meeting fees (princiaplly, renting the room). > Of course, if somebody wants to sponsor the meeting and pick up the Is there an option of someone hosting the meeting? This is probably easier to do than finding someone to foot the bill. Also, Boulder is 3 to 4 hops away from Europe, which seems sub-optimal ... John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 13:38:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11160 for ; Mon, 22 Mar 2004 13:38:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5UJd-0002Ey-O9 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 13:38:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MIcPZT008544 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 13:38:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5UJH-000294-Ba; Mon, 22 Mar 2004 13:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5UIB-0001pp-SU for sip@optimus.ietf.org; Mon, 22 Mar 2004 13:37:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11089 for ; Mon, 22 Mar 2004 13:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5UI7-0000mE-00 for sip@ietf.org; Mon, 22 Mar 2004 13:36:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5UH3-0000hD-00 for sip@ietf.org; Mon, 22 Mar 2004 13:35:46 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B5UGX-0000bf-00; Mon, 22 Mar 2004 13:35:14 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2MIY9gL015160; Mon, 22 Mar 2004 13:34:10 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2MIY6gL015070; Mon, 22 Mar 2004 13:34:06 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Sipping] Proposed dates for SIPish interim meetings X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 22 Mar 2004 20:35:08 +0200 Message-ID: Thread-Topic: [Sip] RE: [Sipping] Proposed dates for SIPish interim meetings Thread-Index: AcQQN6TjZtVpGUDETLyUk9NXeQleaAABKYVw From: "Romascanu, Dan (Dan)" To: "Kozdon, Peter" , , , Cc: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable British Airways is another company that I am aware about, operating = daily flights from London, Heathrow to Denver and return. Regards, Dan > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf=20 > Of Kozdon, Peter > Sent: 22 March, 2004 7:55 PM > To: 'john.loughney@nokia.com'; dean.willis@softarmor.com;=20 > sipping@ietf.org > Cc: gparsons@nortelnetworks.com; sip@ietf.org; simple@ietf.org > Subject: RE: [Sip] RE: [Sipping] Proposed dates for SIPish=20 > interim meetings >=20 >=20 > The closest airport is Denver International (45 minutes=20 > drive) - there is > at least 1 direct flight from Europe (LH via Frankfurt)=20 >=20 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > john.loughney@nokia.com > Sent: Sunday, March 21, 2004 10:13 PM > To: dean.willis@softarmor.com; sipping@ietf.org > Cc: gparsons@nortelnetworks.com; sip@ietf.org; simple@ietf.org > Subject: [Sip] RE: [Sipping] Proposed dates for SIPish=20 > interim meetings >=20 > Dean, >=20 > > As I understand it, the leading candidate for venue is the=20 > Boulderama=20 > > in Boulder, Colorado. Rohan's current proposal is to ask=20 > each attendee=20 > > to contribute $50 toward meeting fees (princiaplly, renting=20 > the room).=20 > > Of course, if somebody wants to sponsor the meeting and pick up the >=20 > Is there an option of someone hosting the meeting? This is probably > easier to do than finding someone to foot the bill. =09 >=20 > Also, Boulder is 3 to 4 hops away from Europe, which seems=20 > sub-optimal ... >=20 > John >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 14:14:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13377 for ; Mon, 22 Mar 2004 14:14:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Urg-00059m-7e for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 14:13:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJDaSf019821 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 14:13:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ur9-0004vR-LK; Mon, 22 Mar 2004 14:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Uqr-0004sC-TE for sip@optimus.ietf.org; Mon, 22 Mar 2004 14:12:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13337 for ; Mon, 22 Mar 2004 14:12:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Uqp-0005Mh-00 for sip@ietf.org; Mon, 22 Mar 2004 14:12:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Upt-0005Gv-00 for sip@ietf.org; Mon, 22 Mar 2004 14:11:46 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5UpM-000597-00; Mon, 22 Mar 2004 14:11:12 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2004 11:15:22 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2MJAbaD002631; Mon, 22 Mar 2004 11:10:38 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA01726; Mon, 22 Mar 2004 11:10:36 -0800 (PST) Message-Id: <4.3.2.7.2.20040322130812.02701008@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Mar 2004 13:10:45 -0600 To: From: "James M. Polk" Subject: RE: [Sip] RE: [Sipping] Proposed dates for SIPish interim meetings Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 08:35 PM 3/22/2004 +0200, Romascanu, Dan (Dan) wrote: >British Airways is another company that I am aware about, operating daily >flights from London, Heathrow to Denver and return. Denver is a big United Airlines hub - they probably fly to somewhere in Europe as well (likely London). Boulder is a ~ 45 minutes drive from Denver Airport (with no traffic that is ;-) >Regards, > >Dan > > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > > Of Kozdon, Peter > > Sent: 22 March, 2004 7:55 PM > > To: 'john.loughney@nokia.com'; dean.willis@softarmor.com; > > sipping@ietf.org > > Cc: gparsons@nortelnetworks.com; sip@ietf.org; simple@ietf.org > > Subject: RE: [Sip] RE: [Sipping] Proposed dates for SIPish > > interim meetings > > > > > > The closest airport is Denver International (45 minutes > > drive) - there is > > at least 1 direct flight from Europe (LH via Frankfurt) > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > john.loughney@nokia.com > > Sent: Sunday, March 21, 2004 10:13 PM > > To: dean.willis@softarmor.com; sipping@ietf.org > > Cc: gparsons@nortelnetworks.com; sip@ietf.org; simple@ietf.org > > Subject: [Sip] RE: [Sipping] Proposed dates for SIPish > > interim meetings > > > > Dean, > > > > > As I understand it, the leading candidate for venue is the > > Boulderama > > > in Boulder, Colorado. Rohan's current proposal is to ask > > each attendee > > > to contribute $50 toward meeting fees (princiaplly, renting > > the room). > > > Of course, if somebody wants to sponsor the meeting and pick up the > > > > Is there an option of someone hosting the meeting? This is probably > > easier to do than finding someone to foot the bill. > > > > Also, Boulder is 3 to 4 hops away from Europe, which seems > > sub-optimal ... > > > > John > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 15:01:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15724 for ; Mon, 22 Mar 2004 15:01:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Vbd-0003FS-SF for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 15:01:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MK12JC012246 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 15:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VaO-0001Lm-Ok; Mon, 22 Mar 2004 14:59:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VZX-0001Jd-26 for sip@optimus.ietf.org; Mon, 22 Mar 2004 14:58:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15630 for ; Mon, 22 Mar 2004 14:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5VZT-0002WX-00 for sip@ietf.org; Mon, 22 Mar 2004 14:58:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VYZ-0002Qf-00 for sip@ietf.org; Mon, 22 Mar 2004 14:57:56 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B5VY5-0002JL-00 for sip@ietf.org; Mon, 22 Mar 2004 14:57:26 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2004 12:04:10 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2MJumUk014403; Mon, 22 Mar 2004 14:56:48 -0500 (EST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGZ54623; Mon, 22 Mar 2004 14:56:46 -0500 (EST) Message-ID: <405F44FE.8010601@cisco.com> Date: Mon, 22 Mar 2004 14:56:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh CC: sip@ietf.org Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE References: <1393468762.1079641347@[192.168.100.5]> <405A2A9D.2080401@cisco.com> <1404432557.1079652311@[192.168.100.5]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > 4) When is it acceptable (standards wise) to clear up a SIP session when > the media stream (be it RTP or RTCP one looks at) dies? Can one assume > that if the media stream dies, it is OK to close the connection? If so, > the converse must apply, i.e. that it is not OK to remove the media > session without renegotiation (and if so, every (all 2) UA's I've > looked at are doing something wrong but that's a separate issue). If not, > how should a UA detect a stale session? It is *always* acceptable to close the connection, whether the media stream is operational or not. (You can hangup whenever you like.) Converses don't always follow, but I think it is true that you must not remove a media session without first either terminating the session or else renegotiating the session to remove the media stream. As a result, I think a non-functional media stream is indicative that something is wrong with the call. I do think there should be some standardized handling of error conditions in order to further interoperability in the face of errors. This is important so that fault tolerance can be achieved in heterogeneous systems. For instance, if an endpoint detects a problem with a media stream, it should probably test the signaling path and other endpoint by sending a reinvite. (This will not only test the path, but it provides an opportunity for kicking a fault tolerant backup into action.) If the reinvite fails, it is appropriate to terminate the connection. If it succeeds, but problems with the media stream persist, then further actions may be required - e.g. changing the media termination parameters at one or both ends. Right now this is hard, because the two ends don't necessarily have the same understanding of what the current status is, and there isn't any standard way of saying this particular reinvite is for the purpose of fixing media problems. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 15:45:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19866 for ; Mon, 22 Mar 2004 15:45:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WId-0007KD-Cy for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 15:45:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MKjVR0028156 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 15:45:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WIB-0007Cq-4x; Mon, 22 Mar 2004 15:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WHZ-0007BG-0E for sip@optimus.ietf.org; Mon, 22 Mar 2004 15:44:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19703; Mon, 22 Mar 2004 15:44:22 -0500 (EST) Message-Id: <200403222044.PAA19703@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 22 Mar 2004 15:44:22 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-03.txt Pages : 32 Date : 2004-3-22 This document defines two new SIP header fields for communications resource priority, namely 'Resource-Priority' and 'Accept-Resource- Priority'. The Resource-Priority header field can influence the behavior of SIP UAs, such as GSTN gateways, and SIP proxies. It does not directly influence the forwarding behavior of IP routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-resource-priority-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-22151404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-22151404.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 22 16:06:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21785 for ; Mon, 22 Mar 2004 16:06:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Wcb-0000Rv-LM for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 16:06:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ML69AD001723 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 16:06:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WcU-0000QU-TX; Mon, 22 Mar 2004 16:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WbW-0000O1-1m for sip@optimus.ietf.org; Mon, 22 Mar 2004 16:05:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21468 for ; Mon, 22 Mar 2004 16:04:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5WbU-0003lQ-00 for sip@ietf.org; Mon, 22 Mar 2004 16:05:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5WZa-0003I0-00 for sip@ietf.org; Mon, 22 Mar 2004 16:03:04 -0500 Received: from host-208-9-212-207.guardent.com ([208.9.212.207] helo=pro1wnexc01.guardent.com) by ietf-mx with esmtp (Exim 4.12) id 1B5WXJ-0002WA-00; Mon, 22 Mar 2004 16:00:41 -0500 Received: by pro1wnexc01.guardent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Mar 2004 15:59:58 -0500 Message-ID: <6A8CA21E339F634E96E13AB97D7322757FF2F1@pro1wnexc01.guardent.com> From: "Hannigan, Martin" To: "'jmpolk@cisco.com'" , "'sipping@ietf.org'" Cc: "'sip@ietf.org'" , "'simple@ietf.org'" Subject: Re: [Sip] RE: [Sipping] Proposed dates for SIPish interim meeting s Date: Mon, 22 Mar 2004 15:59:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hotels should run abot 100 US mostly clean motel style. Boulder has cabs and some public trans. Not great if you are in a remote area. The airport code is DIA. Adjacent towns are Westminster and Louisville. Personally, I'd suggest Boston or VA. Boulder works for me as well. --- Martin Hannigan F:617-456-0500 Verisign, Inc. C:617-388-2663 Operations & Infrastructure W:703-948-7018 Engineer IV http://www.verisign.com/ -----Original Message----- From: James M. Polk To: sipping@ietf.org CC: sip@ietf.org ; simple@ietf.org Sent: Mon Mar 22 11:10:45 2004 Subject: RE: [Sip] RE: [Sipping] Proposed dates for SIPish interim meetings At 08:35 PM 3/22/2004 +0200, Romascanu, Dan (Dan) wrote: >British Airways is another company that I am aware about, operating daily >flights from London, Heathrow to Denver and return. Denver is a big United Airlines hub - they probably fly to somewhere in Europe as well (likely London). Boulder is a ~ 45 minutes drive from Denver Airport (with no traffic that is ;-) >Regards, > >Dan > > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > > Of Kozdon, Peter > > Sent: 22 March, 2004 7:55 PM > > To: 'john.loughney@nokia.com'; dean.willis@softarmor.com; > > sipping@ietf.org > > Cc: gparsons@nortelnetworks.com; sip@ietf.org; simple@ietf.org > > Subject: RE: [Sip] RE: [Sipping] Proposed dates for SIPish > > interim meetings > > > > > > The closest airport is Denver International (45 minutes > > drive) - there is > > at least 1 direct flight from Europe (LH via Frankfurt) > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > john.loughney@nokia.com > > Sent: Sunday, March 21, 2004 10:13 PM > > To: dean.willis@softarmor.com; sipping@ietf.org > > Cc: gparsons@nortelnetworks.com; sip@ietf.org; simple@ietf.org > > Subject: [Sip] RE: [Sipping] Proposed dates for SIPish > > interim meetings > > > > Dean, > > > > > As I understand it, the leading candidate for venue is the > > Boulderama > > > in Boulder, Colorado. Rohan's current proposal is to ask > > each attendee > > > to contribute $50 toward meeting fees (princiaplly, renting > > the room). > > > Of course, if somebody wants to sponsor the meeting and pick up the > > > > Is there an option of someone hosting the meeting? This is probably > > easier to do than finding someone to foot the bill. > > > > Also, Boulder is 3 to 4 hops away from Europe, which seems > > sub-optimal ... > > > > John > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 23 15:48:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27732 for ; Tue, 23 Mar 2004 15:48:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sp3-0003jr-6F for sip-archive@odin.ietf.org; Tue, 23 Mar 2004 15:48:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKmTtM014369 for sip-archive@odin.ietf.org; Tue, 23 Mar 2004 15:48:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5soc-0003eZ-TL; Tue, 23 Mar 2004 15:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5snn-0003RZ-Oi for sip@optimus.ietf.org; Tue, 23 Mar 2004 15:47:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27388; Tue, 23 Mar 2004 15:47:09 -0500 (EST) Message-Id: <200403232047.PAA27388@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 Mar 2004 15:47:08 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-referredby-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : The SIP Referred-By Mechanism Author(s) : R. Sparks Filename : draft-ietf-sip-referredby-05.txt Pages : 25 Date : 2004-3-23 The SIP REFER method [2] provides a mechanism where one party (the referrer) gives a second party (the referree) an arbitrary URI to reference. If that URI is a SIP URI, the referree will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the reference to the refer target using the referree as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-referredby-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-referredby-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-23155713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-referredby-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-referredby-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-23155713.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 23 16:49:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04625 for ; Tue, 23 Mar 2004 16:49:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tlq-000278-UM for sip-archive@odin.ietf.org; Tue, 23 Mar 2004 16:49:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NLnEAT008090 for sip-archive@odin.ietf.org; Tue, 23 Mar 2004 16:49:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tld-000251-Np; Tue, 23 Mar 2004 16:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tkn-00021t-9t for sip@optimus.ietf.org; Tue, 23 Mar 2004 16:48:09 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04558 for ; Tue, 23 Mar 2004 16:48:06 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B5tkI-0001zO-Ub; Tue, 23 Mar 2004 16:47:38 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , sip mailing list , sip chair , sip chair Message-Id: Date: Tue, 23 Mar 2004 16:47:38 -0500 Subject: [Sip] Protocol Action: 'The SIP Referred-By Mechanism' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has approved the following document: - 'The SIP Referred-By Mechanism ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary The SIP REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. The REFER method is specified in RFC 3515, which describes a general set of security considerations in addition to those particular to Referred-By. Working Group Summary The Working Group strongly supported the advancement of Referred-By, once it was split out of the REFER document into the present design. Protocol Quality There was a large amount of working group review of Referred-by, which resulted in its being split out of the original REFER method document and the development of this mechanism and the Authentication ID Body (under review at the same time) on which it depends. There were no dissenting comments during WG Last Call or IETF Last Call. The document was reviewed for the IESG by Allison Mankin. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 23 17:17:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06669 for ; Tue, 23 Mar 2004 17:17:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uCt-0005ay-Fm for sip-archive@odin.ietf.org; Tue, 23 Mar 2004 17:17:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NMHBHF021472 for sip-archive@odin.ietf.org; Tue, 23 Mar 2004 17:17:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uCj-0005Yq-Pk; Tue, 23 Mar 2004 17:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uCG-0005VW-JY for sip@optimus.ietf.org; Tue, 23 Mar 2004 17:16:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06654 for ; Tue, 23 Mar 2004 17:16:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uCE-0002Cn-00 for sip@ietf.org; Tue, 23 Mar 2004 17:16:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uBG-0002AL-00 for sip@ietf.org; Tue, 23 Mar 2004 17:15:31 -0500 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1B5uAk-00028C-00 for sip@ietf.org; Tue, 23 Mar 2004 17:14:58 -0500 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 677041FE66; Tue, 23 Mar 2004 22:14:54 +0000 (GMT) Date: Tue, 23 Mar 2004 22:14:45 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Kyzivat Cc: sip@ietf.org, Alex Bligh Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE Message-ID: <1832206703.1080080085@[192.168.100.5]> In-Reply-To: <405F44FE.8010601@cisco.com> References: <1393468762.1079641347@[192.168.100.5]> <405A2A9D.2080401@cisco.com> <1404432557.1079652311@[192.168.100.5]> <405F44FE.8010601@cisco.com> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 22 March 2004 14:56 -0500 Paul Kyzivat wrote: > Converses don't always follow, but I think it is true that you must not > remove a media session without first either terminating the session or > else renegotiating the session to remove the media stream. As a result, I > think a non-functional media stream is indicative that something is wrong > with the call. So, to be clear, a UA wishing to keep the call alive [SHOULD|MUST] not terminate a media stream without signaling this via renegotiation? (as otherwise it could be mistaken for a fault which the other UA and/or media proxies on the way MAY take as an indication to drop the call). IE is this is SHOULD NOT or a MUST NOT? Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 23 17:46:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08029 for ; Tue, 23 Mar 2004 17:46:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ufF-0008Mg-0h for sip-archive@odin.ietf.org; Tue, 23 Mar 2004 17:46:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NMkSI2032141 for sip-archive@odin.ietf.org; Tue, 23 Mar 2004 17:46:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ueo-0008HF-1G; Tue, 23 Mar 2004 17:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ueN-0008DA-Fu for sip@optimus.ietf.org; Tue, 23 Mar 2004 17:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07951 for ; Tue, 23 Mar 2004 17:45:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ueK-0004vZ-00 for sip@ietf.org; Tue, 23 Mar 2004 17:45:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5udN-0004rR-00 for sip@ietf.org; Tue, 23 Mar 2004 17:44:34 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5ucb-0004kB-00 for sip@ietf.org; Tue, 23 Mar 2004 17:43:45 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 14:49:20 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2NMhCGX018751; Tue, 23 Mar 2004 14:43:13 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHA78566; Tue, 23 Mar 2004 17:43:12 -0500 (EST) Message-ID: <4060BD80.6040008@cisco.com> Date: Tue, 23 Mar 2004 17:43:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh CC: sip@ietf.org Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE References: <1393468762.1079641347@[192.168.100.5]> <405A2A9D.2080401@cisco.com> <1404432557.1079652311@[192.168.100.5]> <405F44FE.8010601@cisco.com> <1832206703.1080080085@[192.168.100.5]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 22 March 2004 14:56 -0500 Paul Kyzivat wrote: > >> Converses don't always follow, but I think it is true that you must not >> remove a media session without first either terminating the session or >> else renegotiating the session to remove the media stream. As a result, I >> think a non-functional media stream is indicative that something is wrong >> with the call. > > > So, to be clear, a UA wishing to keep the call alive [SHOULD|MUST] not > terminate a media stream without signaling this via renegotiation? (as > otherwise it could be mistaken for a fault which the other UA and/or media > proxies on the way MAY take as an indication to drop the call). IE is this > is SHOULD NOT or a MUST NOT? Hmm. I don't know which would be better. I also don't know where such normative language would go. It will probably be tricky to get this right - to precisely define "terminate a media stream". The details of that are almost certainly media dependent. In case of SDP, maybe it means "stop sending SRTP". Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 24 01:35:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00573 for ; Wed, 24 Mar 2004 01:35:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yx-0002Bv-23 for sip-archive@odin.ietf.org; Wed, 24 Mar 2004 01:35:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6ZJj6008419 for sip-archive@odin.ietf.org; Wed, 24 Mar 2004 01:35:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yg-00025Y-LS; Wed, 24 Mar 2004 01:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Xi3-0006ak-P6 for sip@optimus.ietf.org; Mon, 22 Mar 2004 17:15:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28387 for ; Mon, 22 Mar 2004 17:15:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Xi1-0006ip-00 for sip@ietf.org; Mon, 22 Mar 2004 17:15:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Xh6-0006d1-00 for sip@ietf.org; Mon, 22 Mar 2004 17:14:53 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Xgm-0006X7-00; Mon, 22 Mar 2004 17:14:32 -0500 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i2MMGopF027788; Mon, 22 Mar 2004 16:16:50 -0600 Message-ID: <405F65D1.8010605@softarmor.com> Date: Mon, 22 Mar 2004 16:16:49 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org CC: sipping@ietf.org;, Glenn Parsons , sip@ietf.org, simple@ietf.org References: <405E7C1D.1080301@softarmor.com> In-Reply-To: <405E7C1D.1080301@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Oops, XCON Too! -- Was: Proposed dates for SIPish interim meetings Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Your sentience challenged scribe (that's me) forot to include XCON in the original list. It's not because I think they're not important. It's because I forgot. This MIGHT have something to do with having spent the weekend scraping old vinyl flooring loose from the concrete slab of my house, as my water heater ruptured while we were in Korea and much sogginess ensued. Or I might not have an excuse. Anyhow, topics addressed in the interim meeting will include SIP, SIPPING, SIMPLE, and XCON (where I REALLY want progress on floor control, especially after last weekend's labors!). And maybe LEMONADE, although the current drift in responses is that there is little need for co-location here. Follow-ups to SIPPING, please. -- Dean Dean Willis wrote: > Please reply to the SIPPING list -- other lists copied to make sure we > hit everybody. > > We probably need to have at least three days of interim meetings between > now and IETF 60, covering topics in SIP, SIPPING, and SIMPLE. > > We've had a number of venue suggestions in the USA, and it has been > suggested that a Tuesday-Thursday schedule would provide the best > opportunities for travelers from more distant points. > > There has also been some discussion of co-locating with the Lemonade > working group, if the venue allows. We're not sure whether this would > mean adding another day fore-or-aft, or simply running another room in > parallel. > > For the record, historically we've had anywhere from 30 to 60 attendees > at interim meetings. > > As I understand it, the leading candidate for venue is the Boulderama in > Boulder, Colorado. Rohan's current proposal is to ask each attendee to > contribute $50 toward meeting fees (princiaplly, renting the room). Of > course, if somebody wants to sponsor the meeting and pick up the > > These dates have been proposed: > > May 4-6 (May conflict with T1-S1) > May 25-27 (conflicts with OMA POC interim) > June 1-3 (no conflicts I know of) > > For planning purposes, it would help to know: > > 1) Who and how many would be able and willing to attend May 4-6? > 2) Who and how many would be able and willing to to attend May 25-27? > 3) Who and how many would be able and willing to to attend June 1-3? > 4) Who would be conflicted if LEMONADE and SIP-related sessions occurred > simultaneously? > 5) Who just doesn't want to go the the US because of travel > restrictions and annoying border delays? > 6) Anyody willing to sponsor or cosponsor the meeting? > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 24 04:20:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07647 for ; Wed, 24 Mar 2004 04:20:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64Ya-0003M2-0P for sip-archive@odin.ietf.org; Wed, 24 Mar 2004 04:20:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O9KFru012765 for sip-archive@odin.ietf.org; Wed, 24 Mar 2004 04:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64YN-0003HO-Ru; Wed, 24 Mar 2004 04:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64XP-0003FI-Dx for sip@optimus.ietf.org; Wed, 24 Mar 2004 04:19:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07597 for ; Wed, 24 Mar 2004 04:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64XM-0004gJ-00 for sip@ietf.org; Wed, 24 Mar 2004 04:19:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64WW-0004UQ-00 for sip@ietf.org; Wed, 24 Mar 2004 04:18:08 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B64Vh-0004FO-00; Wed, 24 Mar 2004 04:17:17 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2O9H4Rv011617; Wed, 24 Mar 2004 09:17:04 GMT To: "Romascanu, Dan (Dan)" cc: "Kozdon, Peter" , john.loughney@nokia.com, dean.willis@softarmor.com, sipping@ietf.org, gparsons@nortelnetworks.com, sip@ietf.org, simple@ietf.org Subject: Re: [Sip] RE: [Sipping] Proposed dates for SIPish interim meetings In-Reply-To: Message from "Romascanu, Dan (Dan)" of "Mon, 22 Mar 2004 20:35:08 +0200." Date: Wed, 24 Mar 2004 09:17:04 +0000 Message-ID: <11616.1080119824@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Can this annoying chit-chat about which airlines use Denver airport be taken somewhere else? It doesn't belong on an IETF mailing list. Thanks. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 00:39:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15172 for ; Thu, 25 Mar 2004 00:39:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6NaH-0001bp-0R for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 00:39:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P5dGiJ006180 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 00:39:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Na2-0001Vx-39; Thu, 25 Mar 2004 00:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62mv-0006zN-Es for sip@optimus.ietf.org; Wed, 24 Mar 2004 02:26:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26863 for ; Wed, 24 Mar 2004 02:26:54 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62mr-0003CM-00 for sip@ietf.org; Wed, 24 Mar 2004 02:26:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62lr-000317-00 for sip@ietf.org; Wed, 24 Mar 2004 02:25:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1B62l2-0002pH-00; Wed, 24 Mar 2004 02:25:00 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2O7Ox402295; Wed, 24 Mar 2004 09:24:59 +0200 (EET) X-Scanned: Wed, 24 Mar 2004 09:25:10 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2O7PAcd017927; Wed, 24 Mar 2004 09:25:10 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00XUaFoK; Wed, 24 Mar 2004 09:25:07 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2O7NSF26283; Wed, 24 Mar 2004 09:23:28 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 Mar 2004 09:23:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2004 09:23:08 +0200 Message-ID: Thread-Topic: [Sip] RE: [Sipping] Proposed dates for SIPish interim meetings Thread-Index: AcQQN6TjZtVpGUDETLyUk9NXeQleaAABKYVwAE0BZvA= To: , Cc: , X-OriginalArrivalTime: 24 Mar 2004 07:23:08.0726 (UTC) FILETIME=[DB58DD60:01C41170] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] [Sipping] Proposed dates for SIPish interim meetings Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Sorry for starting this mail thread - I suggest that we don't reply any more with respect to flight info, etc. Direct, personal email works best. Anyhow, my main point was that looking at flights from Expedia gave me a couple of choices - flights that were only two hops were much more expensive than flights that were 3 to 4 hops. Add to that a 45 minute drive after a 12+ hour flight, made Boulder seem suboptimal to me. Anyhow, I'm not a key contributor here, so maybe this is not a critical issue. =20 John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 05:04:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12108 for ; Thu, 25 Mar 2004 05:04:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RiL-0006bQ-Ci for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 05:03:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PA3ruE025377 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 05:03:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RhP-0006Gv-7X; Thu, 25 Mar 2004 05:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rb3-0005f1-U9 for sip@optimus.ietf.org; Thu, 25 Mar 2004 04:56:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11682 for ; Thu, 25 Mar 2004 04:56:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Rb0-0004ED-00 for sip@ietf.org; Thu, 25 Mar 2004 04:56:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6RZy-00046S-00 for sip@ietf.org; Thu, 25 Mar 2004 04:55:15 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B6RZK-0003yZ-00 for sip@ietf.org; Thu, 25 Mar 2004 04:54:34 -0500 Received: from dynamicsoft.com ([63.113.46.8]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2P9sINr023947; Thu, 25 Mar 2004 04:54:18 -0500 (EST) Message-ID: <4062AC3E.5020009@dynamicsoft.com> Date: Thu, 25 Mar 2004 04:54:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarit Galanos CC: sip@ietf.org Subject: Re: [Sip] Is there an object named "call" in RFC 3261? References: <10DA2C035FE3BC4FA8D73EC55FC43D9B149437@rvil-mail.radvision.com> In-Reply-To: <10DA2C035FE3BC4FA8D73EC55FC43D9B149437@rvil-mail.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sarit Galanos wrote: > Hi, In RFC 3261 the word "call" is mentioned in the following > paragraph: > > when multiple 2xx responses are received from different remote UAs > (because the INVITE forked), each 2xx establishes a different dialog. > All these dialogs are part of the same call. > > My question is: What is this call. Is it an object that all dialogs > that were created from the same INVITE should be related to? When > should a call object be created? When should it be terminated? Originally, in 2543, a call had a definition, and indeed the call-id was associated with the call: Call: A call consists of all participants in a conference invited by a common source. A SIP call is identified by a globally unique call-id (Section 6.12). Thus, if a user is, for example, invited to the same multicast session by several people, each of these invitations will be a unique call. A point-to-point Internet telephony conversation maps into a single SIP call. In a multiparty conference unit (MCU) based call-in conference, each participant uses a separate call to invite himself to the MCU. This definition proved to ill defined for many reasons. As such, in RFC 3261, there is no formal definition of a call. The text you refer to, as Paul indicates, talks about a call informally. It is suggesting a usage that would mean, "all the dialogs resulting from this call attempt". However, since its not a formal protocol object, it has no defined lifetimes or processing associated with it. An implementation can use its judgement in deciding what it wishes to label as a call. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 05:04:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12125 for ; Thu, 25 Mar 2004 05:04:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RiL-0006bP-CZ for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 05:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PA3rKe025378 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 05:03:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RhI-0006CP-DJ; Thu, 25 Mar 2004 05:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RTq-0005Hd-7m for sip@optimus.ietf.org; Thu, 25 Mar 2004 04:48:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11447 for ; Thu, 25 Mar 2004 04:48:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6RTn-0003WQ-00 for sip@ietf.org; Thu, 25 Mar 2004 04:48:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6RSw-0003Rk-00 for sip@ietf.org; Thu, 25 Mar 2004 04:47:58 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B6RSK-0003LB-00 for sip@ietf.org; Thu, 25 Mar 2004 04:47:20 -0500 Received: from dynamicsoft.com ([63.113.46.8]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2P9ksNr023941; Thu, 25 Mar 2004 04:46:54 -0500 (EST) Message-ID: <4062AA7E.3010804@dynamicsoft.com> Date: Thu, 25 Mar 2004 04:46:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh CC: Paul Kyzivat , sip@ietf.org Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE References: <1393468762.1079641347@[192.168.100.5]> <405A2A9D.2080401@cisco.com> <1404432557.1079652311@[192.168.100.5]> In-Reply-To: <1404432557.1079652311@[192.168.100.5]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Some comments inline. Alex Bligh wrote: > > Wayne.Davies@didata.com.au wrote: > >> This email thread starting with an implementors query on session refresh >> for billing (yes again) but now has a life of it's own!. > > > Yes - but I'm not on a billing thread - too dangerous ground. My take on > that is SIP should clear up properly. If that happens, the billing should > take care of itself. But the question asked raised some other questions. > > I am actually asking 4 separate questions, I guess. Paul has 2: > > --On 18 March 2004 18:02 -0500 Paul Kyzivat wrote: > >> You are raising two separate issues: >> >> 1) how the receiver knows the sender is still there when muted >> or on hold As Paul poitned out, RTCP is indeed for this purpose. This is discussed in RFC 3263, for example: For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. which I think is clear that RTCP is still sent in the sendonly and recvonly cases. >> >> 2) how stupid devices like nats and fws know the stream is still >> active (so the path is preserved) in the same situations Now, this is a good question. One option is to not actually signal hold using sendonly/recvonly/inactive. Rather, if I put you on hold, I change codecs so that the only media I'll accept is the comfort noise payload, or the more recently proposed RTP no-op payload which was defined for this purpose. Or, even more extreme, don't signal anything - implement hold as purely a local UI operation. In both cases, the other side may not properly determine that you've put them on hold (one can debate whether that is important). The latter approach will work off the shelf today and not require any kind of new protocol support from the other end of the call. Another option is ICE, which uses STUN to do connectivity checks. It makes sense to continue those checks during the session, for the purposes of keeping the bindings active, and checking, in fact, that they have not changed. The benefit here is that you can still signal hold using sendonly/sendrecv/inactive; the checks using ICE would occur no matter what the value of these attributes. Currently, ICE doesnt do mid-session keepalives, but that is easily changed. > > > 3) how can a UA behind the stupid device, detected via STUN or otherwise, > in (2) negotiate via SIP that it needs a (desultory) media stream to > continue when the other end puts it on hold / mute etc. That is addressed above. ICE has its own SDP attributes that signal its usage. > > 4) When is it acceptable (standards wise) to clear up a SIP session when > the media stream (be it RTP or RTCP one looks at) dies? Can one assume > that if the media stream dies, it is OK to close the connection? If so, > the converse must apply, i.e. that it is not OK to remove the media > session without renegotiation (and if so, every (all 2) UA's I've > looked at are doing something wrong but that's a separate issue). If not, > how should a UA detect a stale session? If the media session dies, and one end detects this, it should send a BYE rather than just giving up. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 09:10:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21819 for ; Thu, 25 Mar 2004 09:10:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VYh-0007BI-GM for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEABit027576 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXO-0006VT-Gb; Thu, 25 Mar 2004 09:08:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Sbj-00027Q-86 for sip@optimus.ietf.org; Thu, 25 Mar 2004 06:01:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14695 for ; Thu, 25 Mar 2004 06:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Sbf-0003Bm-00 for sip@ietf.org; Thu, 25 Mar 2004 06:01:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Saj-00035B-00 for sip@ietf.org; Thu, 25 Mar 2004 06:00:06 -0500 Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx with smtp (Exim 4.12) id 1B6Sa8-0002xn-00 for sip@ietf.org; Thu, 25 Mar 2004 05:59:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Date: Thu, 25 Mar 2004 10:59:30 -0000 Message-ID: Thread-Topic: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE thread-index: AcQSUywvRPYGL4+sSaK74Q3i9sLmrAAAuL7A From: "Steve Langstaff" To: "Jonathan Rosenberg" , "Alex Bligh" Cc: "Paul Kyzivat" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Some comments inline. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 25 March 2004 09:47 > To: Alex Bligh > Cc: Paul Kyzivat; sip@ietf.org > Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold > etc, & SIP INVITE >=20 >=20 > Some comments inline. >=20 > Alex Bligh wrote: >=20 > >=20 > > Wayne.Davies@didata.com.au wrote: > >=20 > >> This email thread starting with an implementors query on=20 > session refresh > >> for billing (yes again) but now has a life of it's own!. > >=20 > >=20 > > Yes - but I'm not on a billing thread - too dangerous=20 > ground. My take on > > that is SIP should clear up properly. If that happens, the=20 > billing should > > take care of itself. But the question asked raised some=20 > other questions. > >=20 > > I am actually asking 4 separate questions, I guess. Paul has 2: > >=20 > > --On 18 March 2004 18:02 -0500 Paul Kyzivat=20 > wrote: > >=20 > >> You are raising two separate issues: > >> > >> 1) how the receiver knows the sender is still there when muted > >> or on hold >=20 > As Paul poitned out, RTCP is indeed for this purpose. This is=20 > discussed=20 > in RFC 3263, for example: >=20 > For recvonly and sendrecv streams, the port number and address in the > offer indicate where the offerer would like to receive the media > stream. For sendonly RTP streams, the address and port number > indirectly indicate where the offerer wants to receive=20 > RTCP reports. > Unless there is an explicit indication otherwise, reports=20 > are sent to > the port number one higher than the number indicated. >=20 > which I think is clear that RTCP is still sent in the sendonly and=20 > recvonly cases. >=20 > >> > >> 2) how stupid devices like nats and fws know the stream is still > >> active (so the path is preserved) in the same situations >=20 > Now, this is a good question. >=20 > One option is to not actually signal hold using=20 > sendonly/recvonly/inactive. Rather, if I put you on hold, I change=20 > codecs so that the only media I'll accept is the comfort=20 > noise payload,=20 > or the more recently proposed RTP no-op payload which was defined for=20 > this purpose. Or, even more extreme, don't signal anything -=20 > implement=20 > hold as purely a local UI operation. In both cases, the other=20 > side may=20 > not properly determine that you've put them on hold (one can debate=20 > whether that is important). The latter approach will work off=20 > the shelf=20 > today and not require any kind of new protocol support from the other=20 > end of the call. Could sendonly/recvonly/inactive be modified so that they (can) = periodically send no-op or CNG payloads to keep the NAT/Firewall happy, = or do these RTP states preclude the sending of ANY RTP?=20 With hindsight, should RTCP have used the same port pair as the = associated RTP? Implementing hold as a local UI operation would mean that the (held) = source is still using bandwidth. If I'm at the end of a narrow pipe I'd = probably not want my bandwidth used up by audio that I know is going to = be junked, if at all possible. > Another option is ICE, which uses STUN to do connectivity checks. It=20 > makes sense to continue those checks during the session, for the=20 > purposes of keeping the bindings active, and checking, in fact, that=20 > they have not changed. The benefit here is that you can still signal=20 > hold using sendonly/sendrecv/inactive; the checks using ICE=20 > would occur=20 > no matter what the value of these attributes. >=20 > Currently, ICE doesnt do mid-session keepalives, but that is=20 > easily changed. >=20 >=20 > >=20 > >=20 > > 3) how can a UA behind the stupid device, detected via STUN=20 > or otherwise, > > in (2) negotiate via SIP that it needs a (desultory)=20 > media stream to > > continue when the other end puts it on hold / mute etc. >=20 > That is addressed above. ICE has its own SDP attributes that=20 > signal its=20 > usage. >=20 > >=20 > > 4) When is it acceptable (standards wise) to clear up a SIP=20 > session when > > the media stream (be it RTP or RTCP one looks at) dies?=20 > Can one assume > > that if the media stream dies, it is OK to close the=20 > connection? If so, > > the converse must apply, i.e. that it is not OK to remove=20 > the media > > session without renegotiation (and if so, every (all 2) UA's I've > > looked at are doing something wrong but that's a separate=20 > issue). If not, > > how should a UA detect a stale session? >=20 > If the media session dies, and one end detects this, it should send a=20 > BYE rather than just giving up. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 -- Steve Langstaff. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 09:10:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21823 for ; Thu, 25 Mar 2004 09:10:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VYh-0007BM-GM for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEABZD027577 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXd-0006ga-O9; Thu, 25 Mar 2004 09:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6T8d-0004Pq-95 for sip@optimus.ietf.org; Thu, 25 Mar 2004 06:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15630 for ; Thu, 25 Mar 2004 06:35:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6T8Z-00067f-00 for sip@ietf.org; Thu, 25 Mar 2004 06:35:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6T7c-00061u-00 for sip@ietf.org; Thu, 25 Mar 2004 06:34:04 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1B6T6q-0005wE-00 for sip@ietf.org; Thu, 25 Mar 2004 06:33:16 -0500 Received: from RocknRoll (pD9E0DB01.dip.t-dialin.net [217.224.219.1]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i2PBXAkS011312; Thu, 25 Mar 2004 12:33:10 +0100 (MET) From: "Harry Behrens" To: "'Jonathan Rosenberg'" , "'Sarit Galanos'" Cc: Subject: AW: [Sip] Is there an object named "call" in RFC 3261? Date: Thu, 25 Mar 2004 12:35:15 +0100 Message-ID: <003801c4125d$40893990$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4062AC3E.5020009@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jonathan, thanks. I believe now we got it summarized. For me the summary is: A: >An implementation can use=20 > its judgement in deciding what it wishes to label as a call. B: RFC2543 (obsoleted) stated > A SIP call is identified by a=20 > globally unique > call-id=20 C: Formal Logic seems to support this: X is 'ident'ified by 'ident'ifier(X) =3D=3D=3D> .."its judgement".. =3D=3D> for the time being we should assume that at least some implementations identify a call by its callID. This is relevant for accounting purposes, btw... -h > -----Urspr=FCngliche Nachricht----- > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im=20 > Auftrag von Jonathan Rosenberg > Gesendet: Donnerstag, 25. M=E4rz 2004 10:54 > An: Sarit Galanos > Cc: sip@ietf.org > Betreff: Re: [Sip] Is there an object named "call" in RFC 3261? >=20 >=20 >=20 >=20 > Sarit Galanos wrote: >=20 > > Hi, In RFC 3261 the word "call" is mentioned in the following > > paragraph: > >=20 > > when multiple 2xx responses are received from different remote UAs=20 > > (because the INVITE forked), each 2xx establishes a=20 > different dialog. =20 > > All these dialogs are part of the same call. > >=20 > > My question is: What is this call. Is it an object that all dialogs=20 > > that were created from the same INVITE should be related to? When=20 > > should a call object be created? When should it be terminated? >=20 > Originally, in 2543, a call had a definition, and indeed the=20 > call-id was=20 > associated with the call: >=20 > Call: A call consists of all participants in a conference invited by > a common source. A SIP call is identified by a=20 > globally unique > call-id (Section 6.12). Thus, if a user is, for=20 > example, invited > to the same multicast session by several people,=20 > each of these > invitations will be a unique call. A point-to-point Internet > telephony conversation maps into a single SIP call. In a > multiparty conference unit (MCU) based call-in=20 > conference, each > participant uses a separate call to invite himself=20 > to the MCU. >=20 > This definition proved to ill defined for many reasons. As=20 > such, in RFC=20 > 3261, there is no formal definition of a call. The text you=20 > refer to, as=20 > Paul indicates, talks about a call informally. It is=20 > suggesting a usage=20 > that would mean, "all the dialogs resulting from this call attempt".=20 > However, since its not a formal protocol object, it has no defined=20 > lifetimes or processing associated with it. An implementation can use=20 > its judgement in deciding what it wishes to label as a call. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 09:40:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25202 for ; Thu, 25 Mar 2004 09:40:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W1z-0005wS-Pm for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:40:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEeRK2022836 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:40:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W1q-0005rQ-6R; Thu, 25 Mar 2004 09:40:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W1D-0005lM-RW for sip@optimus.ietf.org; Thu, 25 Mar 2004 09:39:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25005 for ; Thu, 25 Mar 2004 09:39:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6W1C-0002Ql-00 for sip@ietf.org; Thu, 25 Mar 2004 09:39:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6W07-0002Eb-00 for sip@ietf.org; Thu, 25 Mar 2004 09:38:32 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Vxt-0001f7-00 for sip@ietf.org; Thu, 25 Mar 2004 09:36:13 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2004 06:40:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2PEZcKl020413; Thu, 25 Mar 2004 06:35:40 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHC16055; Thu, 25 Mar 2004 09:35:37 -0500 (EST) Message-ID: <4062EE39.4030507@cisco.com> Date: Thu, 25 Mar 2004 09:35:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Langstaff CC: Jonathan Rosenberg , Alex Bligh , sip@ietf.org Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Steve Langstaff wrote: > > Could sendonly/recvonly/inactive be modified so that they (can) periodically send no-op or CNG payloads to keep the NAT/Firewall happy, or do these RTP states preclude the sending of ANY RTP? Of course they *could* be modified to permit this. But more would be needed - to negotiate whether they *should* periodically send no-ops. The alternative Jonathan proposed: >>Another option is ICE, which uses STUN to do connectivity checks. It >>makes sense to continue those checks during the session, for the >>purposes of keeping the bindings active, and checking, in fact, that >>they have not changed. The benefit here is that you can still signal >>hold using sendonly/sendrecv/inactive; the checks using ICE >>would occur >>no matter what the value of these attributes. >> >>Currently, ICE doesnt do mid-session keepalives, but that is >>easily changed. amounts to the same thing using a different sort of no-op, and different notation in SDP to negotiate it. If the problem is NATs, and ICE is needed anyway for NATs, then this may be attractive. In addition to changing ICE, this would also require further changes to RTP implementations to deal with mid-session ice messages. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 09:56:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26238 for ; Thu, 25 Mar 2004 09:56:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WHQ-0007Ru-4H for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:56:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEuOFZ028634 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:56:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WHG-0007Oa-RM; Thu, 25 Mar 2004 09:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WGk-0007KD-BK for sip@optimus.ietf.org; Thu, 25 Mar 2004 09:55:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26034 for ; Thu, 25 Mar 2004 09:55:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WGh-0003vr-00 for sip@ietf.org; Thu, 25 Mar 2004 09:55:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WFS-0003mv-00 for sip@ietf.org; Thu, 25 Mar 2004 09:54:22 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B6WEs-0003he-00 for sip@ietf.org; Thu, 25 Mar 2004 09:53:47 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2PErkqY015423 for ; Thu, 25 Mar 2004 15:53:46 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 15:53:45 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 25 Mar 2004 15:53:46 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" , Steve Langstaff Cc: Jonathan Rosenberg , Alex Bligh , sip@ietf.org Subject: RE: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE Date: Thu, 25 Mar 2004 15:53:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Mar 2004 14:53:45.0634 (UTC) FILETIME=[F9036020:01C41278] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, This the following is obvious, I guess, but just to point it out: If a stream is removed (ie not only put on hold), no RTP and no RTCP will be sent, and possible fw/nat holes may be closed. Now, since we don't have a media stream I guess that is ok (we should of course be able to open a new hole if a new stream is added), and in this case no BYE would be sent (since the signalling session is still open). Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Paul > Kyzivat > Sent: 25. maaliskuuta 2004 16:36 > To: Steve Langstaff > Cc: Jonathan Rosenberg; Alex Bligh; sip@ietf.org > Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold > etc, & SIP INVITE > > > > > Steve Langstaff wrote: > > > > Could sendonly/recvonly/inactive be modified so that they > (can) periodically send no-op or CNG payloads to keep the > NAT/Firewall happy, or do these RTP states preclude the > sending of ANY RTP? > > Of course they *could* be modified to permit this. But more would be > needed - to negotiate whether they *should* periodically send no-ops. > > The alternative Jonathan proposed: > > >>Another option is ICE, which uses STUN to do connectivity > checks. It > >>makes sense to continue those checks during the session, for the > >>purposes of keeping the bindings active, and checking, in > fact, that > >>they have not changed. The benefit here is that you can > still signal > >>hold using sendonly/sendrecv/inactive; the checks using ICE > >>would occur > >>no matter what the value of these attributes. > >> > >>Currently, ICE doesnt do mid-session keepalives, but that is > >>easily changed. > > amounts to the same thing using a different sort of no-op, > and different > notation in SDP to negotiate it. If the problem is NATs, and ICE is > needed anyway for NATs, then this may be attractive. > > In addition to changing ICE, this would also require further > changes to > RTP implementations to deal with mid-session ice messages. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 09:58:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21818 for ; Thu, 25 Mar 2004 09:10:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VYh-0007B6-GL for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEABjv027575 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXa-0006dq-Lj; Thu, 25 Mar 2004 09:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6T0q-0004AJ-OS for sip@optimus.ietf.org; Thu, 25 Mar 2004 06:27:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15399 for ; Thu, 25 Mar 2004 06:27:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6T0m-0005QI-00 for sip@ietf.org; Thu, 25 Mar 2004 06:27:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Szn-0005LP-00 for sip@ietf.org; Thu, 25 Mar 2004 06:26:00 -0500 Received: from mail.avalus.com ([195.82.114.197] helo=shed.alex.org.uk) by ietf-mx with esmtp (Exim 4.12) id 1B6SzC-0005GV-00 for sip@ietf.org; Thu, 25 Mar 2004 06:25:22 -0500 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1FC151FDCB; Thu, 25 Mar 2004 11:25:18 +0000 (GMT) Date: Thu, 25 Mar 2004 11:25:07 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Jonathan Rosenberg Cc: Paul Kyzivat , sip@ietf.org, Alex Bligh Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE Message-ID: <1966028589.1080213907@[192.168.100.5]> In-Reply-To: <4062AA7E.3010804@dynamicsoft.com> References: <1393468762.1079641347@[192.168.100.5]> <405A2A9D.2080401@cisco.com> <1404432557.1079652311@[192.168.100.5]> <4062AA7E.3010804@dynamicsoft.com> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > recently proposed RTP no-op payload that would solve most of my issues - I had missed that. > If the media session dies, and one end detects this, it should send a BYE > rather than just giving up. You are presupposing it is detectable. In order to be able to distinguish between a dead (or half dead) media session, and merely that one end has intentionally stopped streaming media, you either have to mandate the use of a no-op payload, or mandate a reinvite. The latter only partly solves the problem in that it doesn't particularly help the dumb (non-SIP inspecting) firewall/NAT in the middle. I can't help thinking though that it should be mandatory that if the underlying media stream changes (e.g. mute is pressed AND the UA no longer wants to send a media stream, or if hold is pressed and the UA no longer wants to send or receive a media stream), then a reinvite is sent, rather than unilaterally changing something which has been negotiated by SIP. Then we just have the issue of whether a keepalive no-op media stream is better than none at all (which is more a media issue than a SIP issue per se). Whether a UA uses "the recently proposed no-op payload" (haven't seen that) or (if the other end doesn't support it), merely sends the occasional packet of (in audio terms) silence using a supported CODEC, would be down to implementation. Alex _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 10:52:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02386 for ; Thu, 25 Mar 2004 10:52:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X8x-0003t8-OU for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 10:51:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFphpu014922 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 10:51:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X8l-0003kX-Mq; Thu, 25 Mar 2004 10:51:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X8c-0003jt-D0 for sip@optimus.ietf.org; Thu, 25 Mar 2004 10:51:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02338 for ; Thu, 25 Mar 2004 10:51:18 -0500 (EST) From: Deepak.Pant@utstar.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6X8Z-0001yn-00 for sip@ietf.org; Thu, 25 Mar 2004 10:51:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6X7o-0001vQ-00 for sip@ietf.org; Thu, 25 Mar 2004 10:50:32 -0500 Received: from quartz.utstar.com ([216.37.120.24]) by ietf-mx with esmtp (Exim 4.12) id 1B6X7C-0001ov-00 for sip@ietf.org; Thu, 25 Mar 2004 10:49:54 -0500 Received: from gypsum.mw.3com.com ([216.37.120.50]) by quartz.utstar.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id i2PFu9XM029006 for ; Thu, 25 Mar 2004 07:56:09 -0800 (PST) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2PFoMi0020810 for ; Thu, 25 Mar 2004 07:50:22 -0800 (PST) To: sip@ietf.org Date: Thu, 25 Mar 2004 09:49:23 -0600 Message-ID: X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 03/25/2004 09:49:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Status of SIP MIB Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Is the SIP MIB in it's present form expired or is this about to become an RFC. Thanks Deepak _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 11:36:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05457 for ; Thu, 25 Mar 2004 11:36:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Xq5-00010J-Cr for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 11:36:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PGaH0h003858 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 11:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Xpq-0000vr-JO; Thu, 25 Mar 2004 11:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Xp9-0000rN-21 for sip@optimus.ietf.org; Thu, 25 Mar 2004 11:35:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05361 for ; Thu, 25 Mar 2004 11:35:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Xp7-0005UX-00 for sip@ietf.org; Thu, 25 Mar 2004 11:35:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XoB-0005RY-00 for sip@ietf.org; Thu, 25 Mar 2004 11:34:19 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B6XnL-0005Nr-00 for sip@ietf.org; Thu, 25 Mar 2004 11:33:27 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Mar 2004 08:40:47 -0800 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PGWsbj012891; Thu, 25 Mar 2004 11:32:54 -0500 (EST) Received: from cisco.com ([64.101.175.145]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AXZ48298; Thu, 25 Mar 2004 08:32:53 -0800 (PST) Message-ID: <406309B4.3050205@cisco.com> Date: Thu, 25 Mar 2004 11:32:52 -0500 From: Kevin Lingle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Deepak.Pant@utstar.com CC: sip@ietf.org Subject: Re: [Sip] Status of SIP MIB References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit deepak, rev 07 is technically expired, but rev 08 is in the works. the draft is in wglc (2nd time) and rev 08 should be the result. the expectation is that rev 08 will be what we submit to iesg. becoming an RFC is not imminent by any means... as we've not submitted it to iesg yet. we also don't have a lot of control over how long that process will take. myself and jean-francios mule (cablelabs) are the only contributing authors to the draft these days. we've worked through a significant number of the comments from our wglc reviewers, but simply have not been able to find the time in either of our schedules to wrap it up and get wglc approval on rev 08. we've set a few target dates but other priorities have come into play to thwart those efforts :( my sense has been all along that there isn't a ground swell of immediate need for the SIP MIBs as of yet across the sip community. kevin Deepak.Pant@utstar.com wrote: > Is the SIP MIB in it's present form expired or is this about to > become an RFC. > > Thanks > Deepak > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 12:27:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09227 for ; Thu, 25 Mar 2004 12:27:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Y6q-0002oB-79 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 11:54:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PGrPmh010700 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 11:53:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Y5M-0002g7-JM; Thu, 25 Mar 2004 11:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Y4k-0002cl-EA for sip@optimus.ietf.org; Thu, 25 Mar 2004 11:51:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06278 for ; Thu, 25 Mar 2004 11:51:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Y4j-0006Va-00 for sip@ietf.org; Thu, 25 Mar 2004 11:51:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Y3p-0006Rl-00 for sip@ietf.org; Thu, 25 Mar 2004 11:50:30 -0500 Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Y37-0006PK-00 for sip@ietf.org; Thu, 25 Mar 2004 11:49:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Status of SIP MIB Date: Thu, 25 Mar 2004 11:49:45 -0500 Message-ID: Thread-Topic: [Sip] Status of SIP MIB Thread-Index: AcQSh1qD7dLpmlRmReybIRu51vTp2QAAOtYQ From: "Bob Natale" To: "Kevin Lingle" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Kevin, > my sense has been all along that there isn't a ground swell of immediate=20 > need for the SIP MIBs as of yet across the sip community. Perhaps. But good MIBs tend to beget good (SNMP[v3]-based) management applications, not the other way around. And the absence of good MIBs for otherwise good technology (e.g., SIP) virtually guarantees that other management solutions will be deployed, increasingly lowering the sense of (but not the reality of) need for those good MIBs. Cheers, BobN _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 14:00:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13860 for ; Thu, 25 Mar 2004 14:00:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6a4x-0001sR-QY for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 13:59:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PIxlVX007214 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 13:59:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6a4i-0001qK-DT; Thu, 25 Mar 2004 13:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6a2d-0001mE-KO for sip@optimus.ietf.org; Thu, 25 Mar 2004 13:57:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13767 for ; Thu, 25 Mar 2004 13:57:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6a2b-00005R-00 for sip@ietf.org; Thu, 25 Mar 2004 13:57:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6a1e-00002y-00 for sip@ietf.org; Thu, 25 Mar 2004 13:56:23 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B6a0l-000008-00 for sip@ietf.org; Thu, 25 Mar 2004 13:55:27 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 25 Mar 2004 11:02:48 -0800 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2PIstRQ008565; Thu, 25 Mar 2004 13:54:55 -0500 (EST) Received: from cisco.com ([64.101.175.145]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AXZ60921; Thu, 25 Mar 2004 10:54:53 -0800 (PST) Message-ID: <40632AFD.9000904@cisco.com> Date: Thu, 25 Mar 2004 13:54:53 -0500 From: Kevin Lingle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Natale CC: sip@ietf.org Subject: Re: [Sip] Status of SIP MIB References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit bob, agreed. and i think about the need to move the draft forward almost all the time. the issue, for me personally, has been product development priorities. working on this mib is by no means my main job ;) i think i speak for my co-author as well. i alluded to this being the _2nd wglc_ for this draft. that was a result of us pausing, after the 1st wglc was concluded, and taking the extra step to migrate the mibs to be aligned with the 2nd rfc for sip (rfc3261). the release of rfc3261 came about in the same timeframe. so in that sense we are trying to provide the due diligence to make the mibs better. an rfc would probably exist if we had not taken this step. but it was the right thing to do. my comments about no ground swell relate to: 1) the fact that we, over the life of this draft [which is waaaayyyy too long], we've not gotten any sense of urgency to get the mibs done. i expect/hope this will change as sip becomes more and more mainstream. i may have been able to justify more of my time for the draft work had there been a more vocal response from the sip community wrt the need for MIBs to be in place sooner than later. 2) our ability to solicit interest from the sip community to review the various drafts has also consistently been a problem. to the point where sometimes i felt we were offering candidate mib objects in a vaccum. having 2 last call reviews has helped this issue though. it is also a case of most folks being very interested in the protocol but not really being "MIB folk" ;) we will eventually get there with the draft (hopefully sooner than later ;). kevin Bob Natale wrote: > Hi Kevin, > > >>my sense has been all along that there isn't a ground swell of > > immediate > >>need for the SIP MIBs as of yet across the sip community. > > > Perhaps. But good MIBs tend to beget good (SNMP[v3]-based) management > applications, not the other way around. And the absence of good MIBs > for otherwise good technology (e.g., SIP) virtually guarantees that > other management solutions will be deployed, increasingly lowering the > sense of (but not the reality of) need for those good MIBs. > > Cheers, > BobN > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 15:57:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22422 for ; Thu, 25 Mar 2004 15:57:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bue-0007OZ-EG for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 15:57:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PKvGcm028426 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 15:57:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6buQ-0007Mi-6p; Thu, 25 Mar 2004 15:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bu5-0007Lo-MS for sip@optimus.ietf.org; Thu, 25 Mar 2004 15:56:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22311 for ; Thu, 25 Mar 2004 15:56:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6bu4-0000Ze-00 for sip@ietf.org; Thu, 25 Mar 2004 15:56:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6btJ-0000Sc-00 for sip@ietf.org; Thu, 25 Mar 2004 15:55:54 -0500 Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx with esmtp (Exim 4.12) id 1B6brY-0000Cv-00 for sip@ietf.org; Thu, 25 Mar 2004 15:54:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Status of SIP MIB Date: Thu, 25 Mar 2004 15:54:01 -0500 Message-ID: Thread-Topic: [Sip] Status of SIP MIB Thread-Index: AcQSmq14hjUJWmajRzWWF7V6j36QAQAD/4Ng From: "Bob Natale" To: "Kevin Lingle" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Kevin, Thanks...I understand...didn't mean to put more pressure on you or the other authors personally...I'd like to help (I was until recently in a role that kept me from being involved in these efforts)...would it be helpful for me to review the -07 version at this point or should I wait for the -08 version? (Or "neither"! :-) Cheers, BobN > -----Original Message----- > From: Kevin Lingle [mailto:klingle@cisco.com] > Sent: Thursday, March 25, 2004 1:55 PM > To: Bob Natale > Cc: sip@ietf.org > Subject: Re: [Sip] Status of SIP MIB >=20 > bob, >=20 > agreed. and i think about the need to move the > draft forward almost all the time. the issue, for > me personally, has been product development priorities. > working on this mib is by no means my main job ;) > i think i speak for my co-author as well. >=20 > i alluded to this being the _2nd wglc_ for this draft. > that was a result of us pausing, after the 1st wglc > was concluded, and taking the extra step to migrate the > mibs to be aligned with the 2nd rfc for sip (rfc3261). > the release of rfc3261 came about in the same timeframe. > so in that sense we are trying to provide the due diligence > to make the mibs better. an rfc would probably exist > if we had not taken this step. but it was the right > thing to do. >=20 > my comments about no ground swell relate to: > 1) the fact that we, over the life of this draft > [which is waaaayyyy too long], we've not gotten > any sense of urgency to get the mibs done. > i expect/hope this will change as sip becomes more and > more mainstream. i may have been able to > justify more of my time for the draft work > had there been a more vocal response from the > sip community wrt the need for MIBs to be in > place sooner than later. >=20 > 2) our ability to solicit interest from the sip > community to review the various drafts has also > consistently been a problem. to the point where > sometimes i felt we were offering candidate mib > objects in a vaccum. having 2 last call reviews > has helped this issue though. it is also a case > of most folks being very interested in the protocol > but not really being "MIB folk" ;) >=20 >=20 > we will eventually get there with the draft (hopefully > sooner than later ;). >=20 > kevin >=20 > Bob Natale wrote: > > Hi Kevin, > > > > > >>my sense has been all along that there isn't a ground swell of > > > > immediate > > > >>need for the SIP MIBs as of yet across the sip community. > > > > > > Perhaps. But good MIBs tend to beget good (SNMP[v3]-based) management > > applications, not the other way around. And the absence of good MIBs > > for otherwise good technology (e.g., SIP) virtually guarantees that > > other management solutions will be deployed, increasingly lowering the > > sense of (but not the reality of) need for those good MIBs. > > > > Cheers, > > BobN > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 18:22:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02397 for ; Thu, 25 Mar 2004 18:22:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eB8-00057b-46 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 18:22:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PNMQCv019684 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 18:22:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eAj-00055p-FO; Thu, 25 Mar 2004 18:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eAJ-000513-Om for sip@optimus.ietf.org; Thu, 25 Mar 2004 18:21:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02310 for ; Thu, 25 Mar 2004 18:21:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6eAG-0003aW-00 for sip@ietf.org; Thu, 25 Mar 2004 18:21:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6e9N-0003YV-00 for sip@ietf.org; Thu, 25 Mar 2004 18:20:38 -0500 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx with esmtp (Exim 4.12) id 1B6e95-0003WO-00 for sip@ietf.org; Thu, 25 Mar 2004 18:20:19 -0500 Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2PNKBlb010976; Thu, 25 Mar 2004 18:20:11 -0500 (EST) Received: from aura.cs.bell-labs.com (aura.cs.bell-labs.com [135.104.8.15]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2PNK4RG008672; Thu, 25 Mar 2004 18:20:04 -0500 (EST) Received: from lucent.com (gokul3.lra.lucent.com [135.255.24.45]) by aura.cs.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2PNK07n007101; Thu, 25 Mar 2004 18:20:01 -0500 (EST) Message-ID: <406368D4.B8248DC4@lucent.com> Date: Thu, 25 Mar 2004 18:18:44 -0500 From: gokul X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Lingle CC: Deepak.Pant@utstar.com, sip@ietf.org Subject: Re: [Sip] Status of SIP MIB References: <406309B4.3050205@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit can someone give a ptr for SIP MIB? I would be very interested in the defn. Thanks, Gokul Kevin Lingle wrote: > > deepak, > > rev 07 is technically expired, but rev 08 is in the works. > the draft is in wglc (2nd time) and rev 08 should be the result. > the expectation is that rev 08 will be what we submit to iesg. > > becoming an RFC is not imminent by any means... as we've > not submitted it to iesg yet. we also don't have a lot of > control over how long that process will take. > > myself and jean-francios mule (cablelabs) are the only > contributing authors to the draft these days. we've worked > through a significant number of the comments from our wglc > reviewers, but simply have not been able to find the time in > either of our schedules to wrap it up and get wglc approval > on rev 08. we've set a few target dates but other priorities > have come into play to thwart those efforts :( > > my sense has been all along that there isn't a ground swell > of immediate need for the SIP MIBs as of yet across the > sip community. > > kevin > > Deepak.Pant@utstar.com wrote: > > Is the SIP MIB in it's present form expired or is this about to > > become an RFC. > > > > Thanks > > Deepak > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Mar 25 18:34:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02979 for ; Thu, 25 Mar 2004 18:34:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eMV-0005yZ-Ub for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 18:34:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PNYB5g022969 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 18:34:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eML-0005wy-MD; Thu, 25 Mar 2004 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eM5-0005vD-NZ for sip@optimus.ietf.org; Thu, 25 Mar 2004 18:33:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02956 for ; Thu, 25 Mar 2004 18:33:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6eM2-0004Xo-00 for sip@ietf.org; Thu, 25 Mar 2004 18:33:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6eLA-0004UQ-00 for sip@ietf.org; Thu, 25 Mar 2004 18:32:49 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B6eKP-0004ME-00 for sip@ietf.org; Thu, 25 Mar 2004 18:32:01 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 Mar 2004 15:31:17 -0800 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2PNVQRQ020882; Thu, 25 Mar 2004 18:31:26 -0500 (EST) Received: from cisco.com ([64.101.175.145]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AXZ86291; Thu, 25 Mar 2004 15:31:25 -0800 (PST) Message-ID: <40636BCD.20901@cisco.com> Date: Thu, 25 Mar 2004 18:31:25 -0500 From: Kevin Lingle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Natale CC: sip@ietf.org Subject: Re: [Sip] Status of SIP MIB References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit bob, you are welcome to review -07 and comment just as anyone else is. we have a set of "official" reviewers (4-5 iirc) from which we've fielded 90+ individual comments. we've addressed (as in read, corresponded about, given some thought to, and have a response/solution) a majority of those comments. the solution - in terms of changes to the mib is not done in many cases (minor changes are typically done, but others are larger changes across the mib). as with most things, it's just a matter of finding the time to work these changes and work through the remaining comments not yet addressed. on one hand i'd love more review of the draft. on the other hand more comments to address will delay things more (potentially). considering that i want -08 to be the wglc approved revision we take to iesg, i'd say you should review -07. do you ever get involved as a mib doctor type or expert reviewer of mib drafts that have been submitted to iesg? kevin Bob Natale wrote: > Hi Kevin, > > Thanks...I understand...didn't mean to put more pressure on you or the > other authors personally...I'd like to help (I was until recently in a > role that kept me from being involved in these efforts)...would it be > helpful for me to review the -07 version at this point or should I wait > for the -08 version? (Or "neither"! :-) > > Cheers, > BobN > > >>-----Original Message----- >>From: Kevin Lingle [mailto:klingle@cisco.com] >>Sent: Thursday, March 25, 2004 1:55 PM >>To: Bob Natale >>Cc: sip@ietf.org >>Subject: Re: [Sip] Status of SIP MIB >> >>bob, >> >>agreed. and i think about the need to move the >>draft forward almost all the time. the issue, for >>me personally, has been product development priorities. >>working on this mib is by no means my main job ;) >>i think i speak for my co-author as well. >> >>i alluded to this being the _2nd wglc_ for this draft. >>that was a result of us pausing, after the 1st wglc >>was concluded, and taking the extra step to migrate the >>mibs to be aligned with the 2nd rfc for sip (rfc3261). >>the release of rfc3261 came about in the same timeframe. >>so in that sense we are trying to provide the due diligence >>to make the mibs better. an rfc would probably exist >>if we had not taken this step. but it was the right >>thing to do. >> >>my comments about no ground swell relate to: >>1) the fact that we, over the life of this draft >> [which is waaaayyyy too long], we've not gotten >> any sense of urgency to get the mibs done. >> i expect/hope this will change as sip becomes more and >> more mainstream. i may have been able to >> justify more of my time for the draft work >> had there been a more vocal response from the >> sip community wrt the need for MIBs to be in >> place sooner than later. >> >>2) our ability to solicit interest from the sip >> community to review the various drafts has also >> consistently been a problem. to the point where >> sometimes i felt we were offering candidate mib >> objects in a vaccum. having 2 last call reviews >> has helped this issue though. it is also a case >> of most folks being very interested in the protocol >> but not really being "MIB folk" ;) >> >> >>we will eventually get there with the draft (hopefully >>sooner than later ;). >> >>kevin >> >>Bob Natale wrote: >> >>>Hi Kevin, >>> >>> >>> >>>>my sense has been all along that there isn't a ground swell of >>> >>>immediate >>> >>> >>>>need for the SIP MIBs as of yet across the sip community. >>> >>> >>>Perhaps. But good MIBs tend to beget good (SNMP[v3]-based) >> > management > >>>applications, not the other way around. And the absence of good >> > MIBs > >>>for otherwise good technology (e.g., SIP) virtually guarantees that >>>other management solutions will be deployed, increasingly lowering >> > the > >>>sense of (but not the reality of) need for those good MIBs. >>> >>>Cheers, >>>BobN >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 26 08:38:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19469 for ; Fri, 26 Mar 2004 08:38:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rXU-0004UK-Fa for sip-archive@odin.ietf.org; Fri, 26 Mar 2004 08:38:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QDcONJ017247 for sip-archive@odin.ietf.org; Fri, 26 Mar 2004 08:38:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rX8-0004PM-6p; Fri, 26 Mar 2004 08:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rWE-00048T-D3 for sip@optimus.ietf.org; Fri, 26 Mar 2004 08:37:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19412 for ; Fri, 26 Mar 2004 08:37:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6rWD-0003Qd-00 for sip@ietf.org; Fri, 26 Mar 2004 08:37:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6rVI-0003JI-00 for sip@ietf.org; Fri, 26 Mar 2004 08:36:08 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1B6rUP-0003DR-00 for sip@ietf.org; Fri, 26 Mar 2004 08:35:14 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i2QDZCK16934 for ; Fri, 26 Mar 2004 14:35:12 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i2QDZC021442 for ; Fri, 26 Mar 2004 14:35:12 +0100 (MET) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA25605 for ; Fri, 26 Mar 2004 14:35:43 +0100 (MET) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Mar 2004 14:35:11 +0100 Message-ID: From: Schmidt Christian To: sip@ietf.org Date: Fri, 26 Mar 2004 14:35:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41337.28BC1D84" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] SIP IPv4 only - terminal behaviour Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41337.28BC1D84 Content-Type: text/plain For Interworking scenario IPv6-IPv4 we need information, concerning the general behaviour of IPv4 only SIP terminals. Imagine an INVITE with a SDP, pointing to an IPv6 remote address for media - Is it correct, that an IPv4 only SIP terminal would reject the call with 400 (client error: bad request) and warn-code 300 (incompatible network protocol)? - What other situation could lead to this response? Thank you for your assistence. Best Regards, Christian Schmidt ------_=_NextPart_001_01C41337.28BC1D84 Content-Type: text/html Content-Transfer-Encoding: quoted-printable SIP IPv4 only - terminal behaviour

For Interworking scenario IPv6-IPv4 we = need information, concerning the general behaviour of IPv4 only SIP = terminals.

Imagine an INVITE with a SDP, pointing = to an IPv6 remote address for media

- Is it correct, that an IPv4 only SIP = terminal would reject the call with 400 (client error: bad request) and = warn-code 300 (incompatible network protocol)?

- What other situation could lead to = this response?

Thank you for your assistence.

Best Regards,
Christian Schmidt

------_=_NextPart_001_01C41337.28BC1D84-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 26 11:33:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00236 for ; Fri, 26 Mar 2004 11:33:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uGi-0006eu-0v for sip-archive@odin.ietf.org; Fri, 26 Mar 2004 11:33:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QGXGaS025573 for sip-archive@odin.ietf.org; Fri, 26 Mar 2004 11:33:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uGT-0006cV-S4; Fri, 26 Mar 2004 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uFc-0006bi-A5 for sip@optimus.ietf.org; Fri, 26 Mar 2004 11:32:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00175 for ; Fri, 26 Mar 2004 11:32:05 -0500 (EST) From: dromasca@avaya.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6uFb-0001T9-00 for sip@ietf.org; Fri, 26 Mar 2004 11:32:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6uEd-0001QQ-00 for sip@ietf.org; Fri, 26 Mar 2004 11:31:08 -0500 Received: from dsl-200-67-150-243.prod-empresarial.com.mx ([200.67.150.243] helo=administrador.com) by ietf-mx with smtp (Exim 4.12) id 1B6uDi-0001No-00 for sip@ietf.org; Fri, 26 Mar 2004 11:30:11 -0500 Date: Fri, 26 Mar 2004 10:29:19 -0600 To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rarawnxmqrbxlhhratul" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_20_30,HTML_MESSAGE, MIME_HTML_ONLY,NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] Encrypted document Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , ----------rarawnxmqrbxlhhratul Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Find the white rabbit.


----------rarawnxmqrbxlhhratul Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: Info.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ----------rarawnxmqrbxlhhratul-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Mar 26 11:51:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01101 for ; Fri, 26 Mar 2004 11:51:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uY0-0008RM-Tt for sip-archive@odin.ietf.org; Fri, 26 Mar 2004 11:51:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QGp8H5032417 for sip-archive@odin.ietf.org; Fri, 26 Mar 2004 11:51:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uXv-0008P6-1Z; Fri, 26 Mar 2004 11:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uX3-0008LP-9i for sip@optimus.ietf.org; Fri, 26 Mar 2004 11:50:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01000 for ; Fri, 26 Mar 2004 11:50:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6uX2-0002Y5-00 for sip@ietf.org; Fri, 26 Mar 2004 11:50:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6uW6-0002Vu-00 for sip@ietf.org; Fri, 26 Mar 2004 11:49:11 -0500 Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx with smtp (Exim 4.12) id 1B6uVa-0002SZ-00 for sip@ietf.org; Fri, 26 Mar 2004 11:48:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Date: Fri, 26 Mar 2004 16:48:39 -0000 Message-ID: Thread-Topic: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE thread-index: AcQSdofDfTFhWfYNRQeFxG1bVlmA9gA2kTLg From: "Steve Langstaff" To: "Paul Kyzivat" Cc: "Jonathan Rosenberg" , "Alex Bligh" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Embedded. -- Steve Langstaff. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 25 March 2004 14:36 > To: Steve Langstaff > Cc: Jonathan Rosenberg; Alex Bligh; sip@ietf.org > Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold > etc, & SIP INVITE >=20 >=20 >=20 >=20 > Steve Langstaff wrote: > >=20 > > Could sendonly/recvonly/inactive be modified so that they=20 > (can) periodically send no-op or CNG payloads to keep the=20 > NAT/Firewall happy, or do these RTP states preclude the=20 > sending of ANY RTP?=20 >=20 > Of course they *could* be modified to permit this. But more would be=20 > needed - to negotiate whether they *should* periodically send no-ops. Would it need extra negotiation? A "NAT-friendly" RTP implementation could periodically send no-ops or = silence (depending on the payload types already negotiated) if it is not = sending anything else - or is this outlawed by being set to "recvonly" = or "inactive"? I suppose that it would not work for all firewalls in all situations, = but I doubt that the signalling endpoints would be in any better a = position to know what session timeout parameters the firewalls were = using anyway? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Mar 28 03:46:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07381 for ; Sun, 28 Mar 2004 03:46:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Vw3-0005Zy-Q8 for sip-archive@odin.ietf.org; Sun, 28 Mar 2004 03:46:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2S8kRPw021412 for sip-archive@odin.ietf.org; Sun, 28 Mar 2004 03:46:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Vvf-0005XX-II; Sun, 28 Mar 2004 03:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Vv1-0005Uz-Ju for sip@optimus.ietf.org; Sun, 28 Mar 2004 03:45:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07292 for ; Sun, 28 Mar 2004 03:45:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Vuy-0004nz-00 for sip@ietf.org; Sun, 28 Mar 2004 03:45:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Vu0-0004hK-00 for sip@ietf.org; Sun, 28 Mar 2004 03:44:20 -0500 Received: from bay10-f102.bay10.hotmail.com ([64.4.37.102] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B7Vsz-0004Va-00 for sip@ietf.org; Sun, 28 Mar 2004 03:43:17 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 28 Mar 2004 00:42:48 -0800 Received: from 80.74.106.2 by by10fd.bay10.hotmail.msn.com with HTTP; Sun, 28 Mar 2004 08:42:48 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [johnyjsmith1970@hotmail.com] X-Sender: johnyjsmith1970@hotmail.com From: "John Smith" To: sip@ietf.org Date: Sun, 28 Mar 2004 08:42:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Mar 2004 08:42:48.0671 (UTC) FILETIME=[A61196F0:01C414A0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Subject: [Sip] Session-Expires and Min-SE values Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, Section 7.1 in draft-ietf-sip-session-timer-14.txt says: "If a Min-SE header is included in the initial session refresh request, the value of the Session-Expires MUST be equal to the value in Min-SE." I have the following questions: (1) What is purpose of this rule? (2) A quotation from Section 9 is: " If the UAS wishes to accept the request, it copies the value of the Session-Expires header field from the request into the 2xx response. The UAS response MAY reduce its value, but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request..." - How can it be possible if the Session-Expires MUST be equal to the value in Min-SE? The UAS would never be able to reduce the Session-Expires value. (3) Down below section 9 says: "The UAS MUST NOT increase the value of the Session-Expires header field." Regarding the top most quotation we can assume that the UAS will always respond with the same value in Session-Expires and Min-SE headers. Will the Session-Expires and Min-SE values ever differ? If they won't, maybe one of them is redundant... Thanks in advance, John. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Mar 28 09:32:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18642 for ; Sun, 28 Mar 2004 09:32:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7bKl-0007Pl-LJ for sip-archive@odin.ietf.org; Sun, 28 Mar 2004 09:32:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SEWJvv028498 for sip-archive@odin.ietf.org; Sun, 28 Mar 2004 09:32:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7bKT-0007Na-N1; Sun, 28 Mar 2004 09:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7bK2-0007MJ-Tc for sip@optimus.ietf.org; Sun, 28 Mar 2004 09:31:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18599 for ; Sun, 28 Mar 2004 09:31:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7bK1-0000q4-00 for sip@ietf.org; Sun, 28 Mar 2004 09:31:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7bJ2-0000il-00 for sip@ietf.org; Sun, 28 Mar 2004 09:30:33 -0500 Received: from exodus.cs.ccu.edu.tw ([140.123.103.6] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B7bI3-0000Vw-00 for sip@ietf.org; Sun, 28 Mar 2004 09:29:31 -0500 Received: from linuxtnb0bt4f7 (Autumn.cs.ccu.edu.tw [140.123.105.35]) (authenticated bits=0) by exodus.cs.ccu.edu.tw (8.12.9p2/8.12.9) with ESMTP id i2SESQOq009111 for ; Sun, 28 Mar 2004 22:28:26 +0800 (CST) (envelope-from raypeng@exodus.cs.ccu.edu.tw) Message-Id: <200403281428.i2SESQOq009111@exodus.cs.ccu.edu.tw> From: "Jen-Ruie Peng" To: Date: Sun, 28 Mar 2004 22:25:12 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C41513.89FE8FE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQU0Hr/XGuyjb1ET2GdWzSHWQ8SQw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_FACE_BAD,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Subject: [Sip] How to implement Session Mobility using SIP ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C41513.89FE8FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, If I want to study "Session Mobility using SIP" in detail, which documents should I read? In the paper "Application-layer mobility using SIP", which written by Henning Schulzrinne, was proposed that "REFER method" and "Third party call control" could achieve the session mobility. Are there any other documents proposed the mechanism about "Session mobility using SIP"? Thanks in advance. Jen-Ruie Peng ------=_NextPart_000_0000_01C41513.89FE8FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

    If I want to study = “Session Mobility using SIP” in detail, which documents should I = read?

In the paper = “Application-layer mobility using = SIP”, which = written by Henning Schulzrinne,

was proposed that “REFER method” and “Third party call control” could achieve the = session mobility.

Are there any other documents proposed the = mechanism about “Session mobility using SIP”?=

 

Thanks in = advance.

Jen-Ruie = Peng

=
------=_NextPart_000_0000_01C41513.89FE8FE0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Mar 28 20:18:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15728 for ; Sun, 28 Mar 2004 20:18:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lPx-0005GS-0q for sip-archive@odin.ietf.org; Sun, 28 Mar 2004 20:18:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T1IKLv020199 for sip-archive@odin.ietf.org; Sun, 28 Mar 2004 20:18:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lPd-0005CP-Vj; Sun, 28 Mar 2004 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lPY-0005Aa-T9 for sip@optimus.ietf.org; Sun, 28 Mar 2004 20:17:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15667 for ; Sun, 28 Mar 2004 20:17:54 -0500 (EST) From: dromasca@avaya.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7lPW-0007lK-00 for sip@ietf.org; Sun, 28 Mar 2004 20:17:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7lOa-0007cg-00 for sip@ietf.org; Sun, 28 Mar 2004 20:16:56 -0500 Received: from [203.238.25.3] (helo=your-li0dokp1n6) by ietf-mx with smtp (Exim 4.12) id 1B7lNe-0007TI-00 for sip@ietf.org; Sun, 28 Mar 2004 20:15:59 -0500 Date: Mon, 29 Mar 2004 10:15:55 +0900 To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------537558246574254" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=MICROSOFT_EXECUTABLE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , ----------537558246574254 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----------537558246574254 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: oadpynlnre.exe, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ----------537558246574254-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 29 19:42:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06176 for ; Mon, 29 Mar 2004 19:42:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87Kl-00025r-DX for sip-archive@odin.ietf.org; Mon, 29 Mar 2004 19:42:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U0gRVt008043 for sip-archive@odin.ietf.org; Mon, 29 Mar 2004 19:42:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87KL-00021j-JB; Mon, 29 Mar 2004 19:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87K9-00020K-KD for sip@optimus.ietf.org; Mon, 29 Mar 2004 19:41:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06124 for ; Mon, 29 Mar 2004 19:41:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B87K7-0005Ee-00 for sip@ietf.org; Mon, 29 Mar 2004 19:41:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B87JH-00057R-00 for sip@ietf.org; Mon, 29 Mar 2004 19:40:56 -0500 Received: from exodus.cs.ccu.edu.tw ([140.123.103.6] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B87Ik-0004zf-00 for sip@ietf.org; Mon, 29 Mar 2004 19:40:22 -0500 Received: from linuxtnb0bt4f7 (Autumn.cs.ccu.edu.tw [140.123.105.35]) (authenticated bits=0) by exodus.cs.ccu.edu.tw (8.12.9p2/8.12.9) with ESMTP id i2U0crOq022213 for ; Tue, 30 Mar 2004 08:38:53 +0800 (CST) (envelope-from raypeng@exodus.cs.ccu.edu.tw) Message-Id: <200403300038.i2U0crOq022213@exodus.cs.ccu.edu.tw> From: "Jen-Ruie Peng" To: Date: Tue, 30 Mar 2004 08:36:03 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C41632.09775D50" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQV7vrf23G7JSekRsKlrxfCVF6Irw== X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_FACE_BAD,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Subject: [Sip] Session Mobility using SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C41632.09775D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, If I want to study "Session Mobility using SIP" in detail, which documents should I read? In the paper "Application-layer mobility using SIP", which written by Henning Schulzrinne, was proposed that "REFER method" and "Third party call control" could achieve the session mobility. Are there any other documents proposed the mechanism about "Session mobility using SIP"? Thanks in advance. Jen-Ruie Peng ------=_NextPart_000_000A_01C41632.09775D50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

    If I want to study “Session Mobility using SIP” in detail, which = documents should I read?

In the paper = “Application-layer = mobility using SIP”, which written by Henning Schulzrinne,

was proposed = that “REFER method” and = “Third party call control” = could achieve the session mobility.

Are there any = other documents proposed the mechanism about “Session mobility using = SIP&#= 8221;?

 

Th= anks in advance.

Je= n-Ruie Peng

=

 

------=_NextPart_000_000A_01C41632.09775D50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Mar 29 21:18:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09575 for ; Mon, 29 Mar 2004 21:18:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B88pY-0008MS-UO for sip-archive@odin.ietf.org; Mon, 29 Mar 2004 21:18:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U2IKMs032114 for sip-archive@odin.ietf.org; Mon, 29 Mar 2004 21:18:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B88pF-0008Jf-V1; Mon, 29 Mar 2004 21:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B88oh-0008Hr-5h for sip@optimus.ietf.org; Mon, 29 Mar 2004 21:17:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09514 for ; Mon, 29 Mar 2004 21:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B88oe-0002oL-00 for sip@ietf.org; Mon, 29 Mar 2004 21:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B88nb-0002aB-00 for sip@ietf.org; Mon, 29 Mar 2004 21:16:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B88mE-0002D8-00 for sip@ietf.org; Mon, 29 Mar 2004 21:14:54 -0500 Received: from mx04.263.net ([211.150.96.24] helo=smtp.263.net) by mx2.foretec.com with esmtp (Exim 4.24) id 1B88Xb-00059Z-BX for sip@ietf.org; Mon, 29 Mar 2004 20:59:47 -0500 Received: by smtp.263.net (Postfix, from userid 500) id 8A90D1BB98; Tue, 30 Mar 2004 09:59:03 +0800 (CST) From: =?gb2312?B?bmFtZQ==?= To: sip@ietf.org Date: Tue, 30 Mar 2004 09:59:02 +0800 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 X-Mailer: XMail-1.0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 Message-Id: <20040330015903.8A90D1BB98@smtp.263.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MIME_BASE64_TEXT,MIME_HTML_ONLY,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Sip] SIP AAA Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 PGh0bWw+PHByZT48UFJFPmhlbGxvIEFsbCw8L1BSRT48UFJFPkkgYW0gcmVhZHkgdG8gc3Rh cnQgbXkgbWFzdGVyIHJlc2VhcmNoLHRoZSBzdHVkeSB0b3BpYyBpcyBhYm91dCAiIHNpcCBh bmQgQUFBKEF1dGhlbnRpY2F0aW9uIEF1dGhvcml6YWl0b24gYW5kIEFjY291bnRpbmcpIjwv UFJFPjxQUkU+d2hlcmUgZG8gaSBzaG91bGQgc3RhcnQgZnJvbT88L1BSRT48UFJFPkNhbiB5 b3UgZ2l2ZSBtZSBzb21lIGFkdmljZXMuSSBhbSBhcHByZWNpYXRlIGl0LjwvUFJFPjxQUkU+ Jm5ic3A7PC9QUkU+PC9wcmU+PC9odG1sPg0KDQoNCg0KDQoNCj09PT09PT09PT09PT09PT09 PT09PT09PT09DQoyNjO159fT08q8/qOt0MXAtdPK19TXqNK1DQo= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 03:03:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06292 for ; Tue, 30 Mar 2004 03:03:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ED7-0007N1-UI for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 03:03:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U8313V028251 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 03:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ECA-0007AV-GT; Tue, 30 Mar 2004 03:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EBL-0006wR-Ke for sip@optimus.ietf.org; Tue, 30 Mar 2004 03:01:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06160 for ; Tue, 30 Mar 2004 03:01:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EBH-0005Yw-00 for sip@ietf.org; Tue, 30 Mar 2004 03:01:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8EAI-0005QJ-00 for sip@ietf.org; Tue, 30 Mar 2004 03:00:07 -0500 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1B8E9a-00058Y-00 for sip@ietf.org; Tue, 30 Mar 2004 02:59:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP AAA Date: Tue, 30 Mar 2004 09:58:48 +0200 Message-ID: Thread-Topic: [Sip] SIP AAA Thread-Index: AcQV/WpnF4Hr4gOCQpOw9lD+noDCvgALotbg From: "Fevzi Konduk" To: "name" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello here are some links that might help you, good luck with your = master thesis.=20 RFC: 3261 (SIP: Session Initiation Protocol) http://www.ietf.org/rfc/rfc3261.txt?number=3D3261 RFC: 3665 (Session Initiation Protocol (SIP) Basic Call Flow Examples) http://www.ietf.org/rfc/rfc3665.txt?number=3D3665 RFC: 3702 (Authentication, Authorization, and Accounting; Requirements = for the Session Initiation Protocol (SIP) ) http://www.ietf.org/rfc/rfc3702.txt?number=3D3702 /Fevzi ------------------------------------------------- Fevzi Konduk Hotsip AB > hello All, > I am ready to start my master research,the study topic is about " sip = and AAA(Authentication=20 > Authorizaiton and Accounting)" > where do i should start from? > Can you give me some advices.I am appreciate it. =A0 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 11:33:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27362 for ; Tue, 30 Mar 2004 11:33:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MAI-0007RI-HZ for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 11:32:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UGWcJb028595 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 11:32:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8M9h-0007JJ-Jm; Tue, 30 Mar 2004 11:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8M9R-0007Eh-Dp for sip@optimus.ietf.org; Tue, 30 Mar 2004 11:31:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27327 for ; Tue, 30 Mar 2004 11:31:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8M9Q-0005Dt-00 for sip@ietf.org; Tue, 30 Mar 2004 11:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8M8d-00054H-00 for sip@ietf.org; Tue, 30 Mar 2004 11:30:55 -0500 Received: from web41811.mail.yahoo.com ([66.218.93.145]) by ietf-mx with smtp (Exim 4.12) id 1B8M7p-0004rz-00 for sip@ietf.org; Tue, 30 Mar 2004 11:30:05 -0500 Message-ID: <20040330162930.7685.qmail@web41811.mail.yahoo.com> Received: from [63.158.252.52] by web41811.mail.yahoo.com via HTTP; Tue, 30 Mar 2004 08:29:30 PST Date: Tue, 30 Mar 2004 08:29:30 -0800 (PST) From: CAITR Reply-To: info@caitr.org To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-628231385-1080664170=:6676" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] Internetworking 2004: May 13-14, 2004, Las Vegas Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-628231385-1080664170=:6676 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27328 Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Internetworking 2004=20 May 13-14, 2004 Las Vegas Convention Center, Las Vegas, Nevada http://www.caitr.org/internetworking04/index.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Internetworking 2004, for the first time collocated with NetWorld+Interop= , aims to address some of the main issues of concern within IP networking= and the Internet. This exclusive leading-edge technology program covers = innovative solutions for Enterprises, Service Providers, networking equip= ment manufacturers, government and others.=20 =20 The Internetworking 2004 conference, comprised of comprehensive technical= sessions, panels, and case studies for real operational networks, is int= ended as a forum for technical discussions on topics including:=20 =20 =95 Voice over IP (VoIP) and Convergence =95 Multiservice Network Design and Planning =95 Virtual Private Networks (VPNs) =95 Routing: Unicast & Multicast=20 =95 Wireless Internet=20 =95 Next Generation Mobile Networks=20 =95 Quality of Service (QoS) =95 Network Security=20 =95 Network Processors=20 =95 Service Integration=20 =95 Operational Support Systems=20 =95 Network Survivability and Fault Management=20 =95 Internetworking IP and Optical Networks=20 ***EXCLUSIVE ALUMNI DISCOUNT*** We are pleased to extend a special alumni discount for the 2-day Internet= working 2004 Pass. Purchase the pass for $595.00, a $500.00 savings off t= he regular price. Visit for Priority Code and registration details.=20 We look forward to seeing you at the only end-to-end networking and commu= nications event. =20 Sincerely, The NetWorld+Interop Team http://www.interop.com/ --0-628231385-1080664170=:6676 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27328 Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /DIV>
Internetworking 2004
May 13-14, 2004
Las Vegas Convention Cen= ter, Las Vegas, Nevada
http://www.caitr.org/internetworking04/index.htm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /DIV>
 
Internetworking 2004, for the first time collocated with NetWorld+In= terop, aims to address some of the main issues of concern within IP netwo= rking and the Internet. This exclusive leading-edge technology program co= vers innovative solutions for Enterprises, Service Providers, networking = equipment manufacturers, government and others.
 
The Internetworking 2004 conference, comprised of comprehensive tech= nical sessions, panels, and case studies for real operational networks, i= s intended as a forum for technical discussions on topics including:
 
=95 Voice over IP (VoIP) and Convergence
=95 Multiservice Network= Design and Planning
=95 Virtual Private Networks (VPNs)
=95 Routin= g: Unicast & Multicast
=95 Wireless Internet
=95 Next Generat= ion Mobile Networks
=95 Quality of Service (QoS)
=95 Network Secur= ity
=95 Network Processors
=95 Service Integration
=95 Operat= ional Support Systems
=95 Network Survivability and Fault Management =
=95 Internetworking IP and Optical Networks
***EXCLUSIVE ALUMNI DISCOUNT***
We are pleased to extend a s= pecial alumni discount for the 2-day Internetworking 2004 Pass. Purchase = the pass for $595.00, a $500.00 savings off the regular price. Visit= <= http://www.caitr.org/internetworking04/registration.htm> for Prior= ity Code and registration details.

We look forward to seeing you at the only end-to-end networking = and communications event.
 
Sincerely,
The NetWorld+Interop Team
http://www.interop.com/
--0-628231385-1080664170=:6676-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 17:05:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15629 for ; Tue, 30 Mar 2004 17:05:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RMG-0003uV-QB for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:05:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UM5Kx6015002 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:05:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RLx-0003j9-Ue; Tue, 30 Mar 2004 17:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RLT-0003gl-Qp for sip@optimus.ietf.org; Tue, 30 Mar 2004 17:04:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15557 for ; Tue, 30 Mar 2004 17:04:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8RLR-0003FL-00 for sip@ietf.org; Tue, 30 Mar 2004 17:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8RKT-0003DZ-00 for sip@ietf.org; Tue, 30 Mar 2004 17:03:30 -0500 Received: from bay2-f9.bay2.hotmail.com ([65.54.247.9] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B8RJa-0003BW-00 for sip@ietf.org; Tue, 30 Mar 2004 17:02:35 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Mar 2004 14:02:04 -0800 Received: from 194.237.142.7 by by2fd.bay2.hotmail.msn.com with HTTP; Tue, 30 Mar 2004 22:02:04 GMT X-Originating-IP: [194.237.142.7] X-Originating-Email: [ismolcic@hotmail.com] X-Sender: ismolcic@hotmail.com From: "Ivan Smolcic" To: sip@ietf.org Date: Tue, 30 Mar 2004 22:02:04 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Mar 2004 22:02:04.0819 (UTC) FILETIME=[A2FC8E30:01C416A2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] SIP mesages with XML Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Has there been any work done with encoding SIP messages with XML? If there has, please tell me where I can find out more about it. What are the advantages of XML encoding instead of plain text? _________________________________________________________________ Check out MSN PC Safety & Security to help ensure your PC is protected and safe. http://specials.msn.com/msn/security.asp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:42:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04472 for ; Tue, 30 Mar 2004 18:42:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj7-0006WI-05 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEPvAe012141 for sip-archive@odin.ietf.org; Thu, 25 Mar 2004 09:25:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vno-000359-JC; Thu, 25 Mar 2004 09:25:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VlN-00028F-Oi for sip@optimus.ietf.org; Thu, 25 Mar 2004 09:23:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23309 for ; Thu, 25 Mar 2004 09:23:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VlC-0007gr-00 for sip@ietf.org; Thu, 25 Mar 2004 09:23:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VkO-0007an-00 for sip@ietf.org; Thu, 25 Mar 2004 09:22:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6VjN-0007Rc-00 for sip@ietf.org; Thu, 25 Mar 2004 09:21:13 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2004 06:25:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PEKeUe003382; Thu, 25 Mar 2004 06:20:41 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHC14822; Thu, 25 Mar 2004 09:20:39 -0500 (EST) Message-ID: <4062EAB7.4070302@cisco.com> Date: Thu, 25 Mar 2004 09:20:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Alex Bligh , sip@ietf.org Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE References: <1393468762.1079641347@[192.168.100.5]> <405A2A9D.2080401@cisco.com> <1404432557.1079652311@[192.168.100.5]> <4062AA7E.3010804@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >> 4) When is it acceptable (standards wise) to clear up a SIP session when >> the media stream (be it RTP or RTCP one looks at) dies? Can one assume >> that if the media stream dies, it is OK to close the connection? If so, >> the converse must apply, i.e. that it is not OK to remove the media >> session without renegotiation (and if so, every (all 2) UA's I've >> looked at are doing something wrong but that's a separate issue). If >> not, >> how should a UA detect a stale session? > > > If the media session dies, and one end detects this, it should send a > BYE rather than just giving up. I agree that just giving up is bad, and that sending BYE is a better alternative. But it isn't the only one. In this situation it makes some sense to try to diagnose and possibly repair the situation. For diagnosis, one thing to do is to test the signaling path by sending a reinvite or update. If the reinvite succeeds, and didn't change the media descriptions, and media still doesn't flow, then it might help to try changing things in the media path. This is all stuff that will happen implicitly if you send a BYE and then one of the users retries the call, which is a common action when your phone call goes dead or is unexpectedly disconnected. Doing it automatically would provide a better user experience. Reinviting has another potential benefit: if the far end is redundant, the reinvite might trigger a failover to the backup, and therefore fix a call that wouldn't otherwise be fixed. I think this is preferable to sending BYE because it does no harm. Automatically sending BYE may kill a call that might have eventually recovered. It removes a degree of choice from the user. The user always has the option to hangup (hence send BYE) when he gets tired of listening to nothing. (This assumes there is a user controlling the UA. If it is an automated device the choices should be different.) Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:45:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04955 for ; Tue, 30 Mar 2004 18:45:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006ZK-QF for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFP9Nb032219 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:25:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTZR-0008LI-5b; Wed, 18 Feb 2004 10:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTZ3-0008FU-2v for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:24:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20196 for ; Wed, 18 Feb 2004 10:24:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTZ0-00017B-00 for sip@ietf.org; Wed, 18 Feb 2004 10:24:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTXs-0000uy-00 for sip@ietf.org; Wed, 18 Feb 2004 10:23:29 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtTWk-0000dM-00 for sip@ietf.org; Wed, 18 Feb 2004 10:22:18 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1IFLhuA013088; Wed, 18 Feb 2004 07:21:43 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGD18368; Wed, 18 Feb 2004 10:21:41 -0500 (EST) Message-ID: <40338305.5050801@cisco.com> Date: Wed, 18 Feb 2004 10:21:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , Cullen Jennings , Brian Stucker , sip@ietf.org Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers requirements References: <40325949.10908@softarmor.com> <4032F0D9.204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >> 4) Selection of a specific instance in an initial request: We have a >> request that we wish to reach one specific instance of a contact >> associated with an AoR. > > My proposal of using a callee capabilities parameter for instance ID > would accomplish that. However, I am not sure that its really useful, to > be honest. How would the caller know the instance ID ahead of time? Any > kind of mechanism that can transfer the instance ID could transfer the > GRUU instead, and a GRUU will be much, much, much better. Well, since we have said that GRUUs may not be stable over long periods of time, there may be value in using callerprefs with instance id when setting up a relationship that is supposed to be essentially permanent. This then becomes a form of static configuration of relationships. I agree this may be a bit of a stretch. But it is a nice side effect. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:45:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04996 for ; Tue, 30 Mar 2004 18:45:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006ZK-A9 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08FbOBs023628 for sip-archive@odin.ietf.org; Thu, 8 Jan 2004 10:37:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecDV-0005sm-VY; Thu, 08 Jan 2004 10:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecCc-0005mD-43 for sip@optimus.ietf.org; Thu, 08 Jan 2004 10:36:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28213 for ; Thu, 8 Jan 2004 10:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecCU-0001ni-00 for sip@ietf.org; Thu, 08 Jan 2004 10:35:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aec5q-0001UD-00 for sip@ietf.org; Thu, 08 Jan 2004 10:29:07 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly04a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1Aec0r-0001BV-00 for sip@ietf.org; Thu, 08 Jan 2004 10:23:57 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly04a.srv.mailcontrol.com (MailControl) with SMTP id i08FMwXv015962; Thu, 8 Jan 2004 15:22:58 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Thu, 8 Jan 2004 15:22:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] 1xx Provisional Responses Date: Thu, 8 Jan 2004 15:22:58 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE01E22F94@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] 1xx Provisional Responses Thread-Index: AcPV+fFE6Kt4ZIUNTh6SdSPcsV1+zgAAU6ng From: "Chris Boulton" To: , Cc: "edNET Telco" X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16,OFFERS_ETC autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Have you looked at RFC 3262. Chris. >-----Original Message----- >From: Suha Cubukcuoglu [mailto:suhac@nplusone.net] >Sent: 08 January 2004 15:06 >To: sip@ietf.org >Cc: edNET Telco >Subject: [Sip] 1xx Provisional Responses > >Hi, > >In the RFC for SIP (#3261) it is stated that 1xx provisional responses >are not transmitted reliably and never cause the client to send an ACK >message. SIP clients use UDP to send messages across networks. >Therefore, for example, '180 Ringing' message may or may reach the >calling party without the called party recognizing whether the message >has reached its destination. This has adverse effects in terms of call >setup and usability. If the 180 Ringing message is lost in the network >while the called party is ringing, the calling party will have no idea >what state the call is in at any time (e.g. one could think they dialed >a wrong number, or its taking too long to contact the other end, etc.). >'180 Ringing' message, in our opinion, should be treated as a critical >message just like INVITE and 200 OK or the called party must send >multiple '180 Ringing' messages, instead of just one, to make sure the >other end will receive the message one way or other. > >Could you please tell us your comments about this? > >Thanks very much. > >Regards, > >Suha Cubukcuoglu >nplusone >t: +44 131 514 2000 >d: +44 131 514 4037 > >-- > >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 sender. Any >offers or quotation of service are subject to formal specification. >Errors and omissions excepted. Please note that any views or opinions >presented in this email are solely those of the author and do not >necessarily represent those of edNET or lightershade ltd. Finally, the >recipient should check this email and any attachments for the presence of >viruses. edNET and lightershade ltd accepts no liability for any damage >caused by any virus transmitted by this email. > >-- >-- >Virus scanned by edNET. > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:45:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05032 for ; Tue, 30 Mar 2004 18:45:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj4-0006ZK-68 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IM0t2S003267 for sip-archive@odin.ietf.org; Thu, 18 Mar 2004 17:00:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45Ye-0000h7-Ap; Thu, 18 Mar 2004 17:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45YJ-0000fF-AQ for sip@optimus.ietf.org; Thu, 18 Mar 2004 16:59:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11105 for ; Thu, 18 Mar 2004 16:59:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B45YH-0000NY-00 for sip@ietf.org; Thu, 18 Mar 2004 16:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B45XM-0000KC-00 for sip@ietf.org; Thu, 18 Mar 2004 16:58:48 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B45Wz-0000GY-00 for sip@ietf.org; Thu, 18 Mar 2004 16:58:25 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2004 13:57:10 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2ILvqUm017221; Thu, 18 Mar 2004 16:57:54 -0500 (EST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGX15823; Thu, 18 Mar 2004 16:57:51 -0500 (EST) Message-ID: <405A1B5E.4080209@cisco.com> Date: Thu, 18 Mar 2004 16:57:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Behrens CC: "'Sarit Galanos'" , sip@ietf.org Subject: Re: AW: [Sip] Is there an object named "call" in RFC 3261? References: <00bc01c40b77$ea1f4c70$2c00a8c0@RocknRoll> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA11106 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Harry Behrens wrote: > I`d believe the call is that which idenitified by the CallID. Close, but not quite. The callid, isn't unique by itself. A dialog is=20 denoted by a callid, from-tag, and to-tag. Both the callid and the=20 from-tag are supplied by the caller, while the to-tag is supplied by the=20 callee. I think in the quoted section the term call is used informally, and=20 corresponds to an implementation artifact that has no concise name in=20 3261. But the combination of the callid and the from-tag provide a=20 unique identifier for what is being discussed. Paul >>-----Urspr=FCngliche Nachricht----- >>Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im=20 >>Auftrag von Sarit Galanos >>Gesendet: Dienstag, 16. M=E4rz 2004 12:42 >>An: sip@ietf.org >>Betreff: [Sip] Is there an object named "call" in RFC 3261? >> >> >>Hi, >>In RFC 3261 the word "call" is mentioned in the following paragraph: >> >>when multiple 2xx responses are received from different=20 >>remote UAs (because the INVITE forked), each 2xx establishes=20 >>a different dialog. All these dialogs are part of the same call. >> >>My question is: What is this call. Is it an object that all=20 >>dialogs that were created from the same INVITE should be=20 >>related to? When should a call object be created? When should=20 >>it be terminated? >> >>Thanks, >>Sarit. >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current=20 >>sip Use sipping@ietf.org for new developments on the=20 >>application of sip >> >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:46:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05158 for ; Tue, 30 Mar 2004 18:46:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006ZK-7G for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FA30Id016809 for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 05:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ov7-000497-IJ; Mon, 15 Mar 2004 05:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oum-000485-V8 for sip@optimus.ietf.org; Mon, 15 Mar 2004 05:01:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18158 for ; Mon, 15 Mar 2004 05:01:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ouj-000309-00 for sip@ietf.org; Mon, 15 Mar 2004 05:01:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2otm-0002rr-00 for sip@ietf.org; Mon, 15 Mar 2004 05:00:42 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly06b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1B2oso-0002dR-00 for sip@ietf.org; Mon, 15 Mar 2004 04:59:42 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly06b.srv.mailcontrol.com (MailControl) with SMTP id i2F9x627031530; Mon, 15 Mar 2004 09:59:06 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Mon, 15 Mar 2004 09:59:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU issue 2: Callee caps param or not Date: Mon, 15 Mar 2004 09:59:06 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF23E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] GRUU issue 2: Callee caps param or not Thread-Index: AcQIgJ9/ZwzBWJN2Rp+6JkFhLMSm9wB82W9Q From: "Chris Boulton" To: "Jonathan Rosenberg" , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 12 March 2004 22:21 >To: sip@ietf.org >Subject: [Sip] GRUU issue 2: Callee caps param or not > >Currently, the instance attribute in the Contact header field is a >callee capabilities parameter. This is "flagged" by the presence of >+sip. as a prefix. So, a REGISTER would look like this: > >REGISTER sip:example.com >To: sip:user@example.com >Contact: sip:u1@1.2.3.4;+sip.instance=3D"hasdasdsadiasdasida" > >The alternative would be to use a new, non-callee-caps parameter: > >REGISTER sip:example.com >To: sip:user@example.com >Contact: sip:u1@1.2.3.4;instance=3D"hasdasdsadiasdasida" > >The only difference in these two approaches is that in the former case, >you can use caller preferences with the tag. That means one could >construct an INVITE request an ask for preferential routing to a device >with that instance ID. For example: > >INVITE sip:user@example.com >Accept-Contact *;+sip.instance=3D"hasdasdsadiasdasida" > >This would prefer that the INVITE be routed to a device with that >instance ID. Its important to note that this is NOT AN ALTERNATIVE for >the gruu, which would guarantee routing to the device with that instance: > >INVITE sip:hhs777asd=3D=3D000asdhnvvva8s7@example.com > >Indeed, one of the reasons we specified gruu was that caller-prefs based >routing was unreliable: > >1. there was no guarantee it was honored by a proxy >2. it would only work in cases where routing decisions were made by a >single proxy - the one that the users registered too >3. it depended on knowledge of downstream routing behaviors > >That said, there may be cases where the desired behavior is "I want to >reach this user at this aor, but would prefer this instance id". Having >the instance ID as a callee-cap parameter would allow that. > >So, the question is, what to do in the spec? callee cap or not? There >was consensus at the meeting to keep it as a callee-cap, and document >the above issues so that people would be clear when to use caller prefs, >and when to use the gruu. > >Does anyone object to this decision? [Chris Boulton] I can't think where this would be used BUT see no harm. I would leave it as a callee cap. Chris. > >Thanks, >Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:46:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05245 for ; Tue, 30 Mar 2004 18:46:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006a4-9L for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FAH6on021889 for sip-archive@odin.ietf.org; Mon, 15 Mar 2004 05:17:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2p8x-0005TW-Qc; Mon, 15 Mar 2004 05:16:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2p8R-0005OR-2v for sip@optimus.ietf.org; Mon, 15 Mar 2004 05:15:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18934 for ; Mon, 15 Mar 2004 05:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2p8N-0005IM-00 for sip@ietf.org; Mon, 15 Mar 2004 05:15:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2p6x-0004uT-00 for sip@ietf.org; Mon, 15 Mar 2004 05:14:19 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly10b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1B2p5t-0004Y4-00 for sip@ietf.org; Mon, 15 Mar 2004 05:13:13 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly10b.srv.mailcontrol.com (MailControl) with SMTP id i2FACauJ027588; Mon, 15 Mar 2004 10:12:36 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Mon, 15 Mar 2004 10:12:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU Issue 4 (last one): Reusable grid? Date: Mon, 15 Mar 2004 10:12:36 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF23F@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] GRUU Issue 4 (last one): Reusable grid? Thread-Index: AcQIkhYs16qeVYr4Q/mmG5PJD9sOuwB498lw From: "Chris Boulton" To: "Jonathan Rosenberg" , X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Seems sensible. Chris. >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 13 March 2004 00:25 >To: sip@ietf.org >Subject: [Sip] GRUU Issue 4 (last one): Reusable grid? > >The GRID URI parameter, defined by the GRUU spec, has some nice >properties associated with it. Perhaps most valuable is that it survives >proxy translations. This makes it a URI parameter that is automatically >passed from the UAC to UAS. In that regard, it can be used as a form of >"sub-addressing" - a means to identify a sub-instance within the UA >instance pointed to by the GRUU proper. > >One comment that was made at some point is that the grid parameter, as a >result of these properties, would be generally useful for SIP URIs, and >should therefore not be bound to the GRUU. The proposal was to >"generecize" it. > >My response to that was: > > 1. It is already generecized, in that its a valid URI parameter, > 2. It only makes sense in URIs that have the GRUU property. Without >that, the grid would need to be interpreted across different UA >instances, and thus it loses the sub-addressing property, which only >makes sense within a particular UA instance > 3. You can get a GRUU through non-register mechanisms > >As such, my proposal is to keep things as they are. > >Any objections? > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:46:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05416 for ; Tue, 30 Mar 2004 18:46:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj2-0006ZK-7d for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RNwfXX024054 for sip-archive@odin.ietf.org; Tue, 27 Jan 2004 18:58:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald50-0005Hu-QU; Tue, 27 Jan 2004 18:57:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al8JR-0002CX-2E for sip@optimus.ietf.org; Mon, 26 Jan 2004 10:06:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08188 for ; Mon, 26 Jan 2004 10:06:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al8JP-00024v-00 for sip@ietf.org; Mon, 26 Jan 2004 10:06:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al8IV-00022y-00 for sip@ietf.org; Mon, 26 Jan 2004 10:05:08 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Al8I9-00020M-00 for sip@ietf.org; Mon, 26 Jan 2004 10:04:45 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2004 07:09:19 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i0QF49Kf027459; Mon, 26 Jan 2004 07:04:12 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFN33203; Mon, 26 Jan 2004 10:04:08 -0500 (EST) Message-ID: <40152C68.8030802@cisco.com> Date: Mon, 26 Jan 2004 10:04:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] querying the current event state of a publication References: <4012E741.5000809@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TAG_BALANCE_BODY autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Comment inline. Paul Jonathan Rosenberg wrote: > In draft-ietf-sip-publish-02, section 5.7 proposes a way to query a > specific published event state. It recommends subscribing to the AOR to > learn it. However, it gives this caveat: > > Note that a subscription to the event package will likely deliver > results of the event composition process of the state agent, which > may be a subset or a superset of the current published event > state. > > which is another way of saying, that subscribing to the aor doesnt > really allow you to query for a specific published event state. > > If we want this functionality, I have an idea for an alternative > approach that works much better, triggered by some conversations I had > with Ben C. recently. That's a big IF. Do we really want to mandate that every compositor must be prepared to provide this? It certainly puts contraints on the implementations, and in most cases I think publishers can be constructed so that they don't need this capability. I think the only time you might need this event state is when partial publication is in use and the publisher has forgotten the full state, or when a backup publisher is trying to pick up from another one. In the former case, there is no real advantage over simply transmitting the full state as a refresh - same amount of data is required. The advisability of supporting the latter case seems questionable to me. There is a lot of work in providing a real failover backup, and it might as well include remembering the state locally. If this capability is provided we run the risk of abetting the construction of dualing endpoints competing to publish particular event state. But, if in the end there is a good argument for this capability, then the proposal for how to do it seems reasonable. > In the response to a PUBLISH request, the ESC returns a URI that > identifies that particular event state publication (effectively, a URI > that is bound to the AOR+event+etag of a publication). This URI is > basically a GRUU. If a user wishes to learn the state of this particular > event state, they merely subscribe to that URI. Indeed, a particularly > interestinig way to do this is to define sIP etags as URIs, rather than > reusing the definition from http. I think that having an etag as a URI > is far more elegant, as it would allow for things like this function in > a natural way. The alternative would be to possibly use the Contact > header field, as the meaning is the same as in a 2xx to INVITE - > identifying the specific *instance* to which you were connected when you > contacted the AOR. This makes sense if you think of the event state > publication URI as a GRUU. > > Indeed, one might even then PUBLISH to that URI, and it would have the > exact result you would expect - that particular event state is updated. > In such a case the server woould NOT return an etag or another URI in > the response. > > So, as an example, if I want to publish for sip:jdrosen@dynamicsoft.com: > > PUBLISH sip:jdrosen@dynamicsoft.com > Event: presence > > > > > the server responds: > > SIP 200 oK > SIP-Etag: sip:9adjsss=9888sdahhsd77fggld@dynamicsoft.com > > > now, I have a handle for the specific event state. To update it: > > PUBLISH sip:9adjsss=9888sdahhsd77fggld@dynamicsoft.com > Event: presence > > > > > This would mean we wouldnt need the SIP-If-match. > > Another alternative is to say that we are simply too far along in > PUBLISH, and the time has passed for major changes as this would be. > > Thoughts? > > -Jonathan R. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:47:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05446 for ; Tue, 30 Mar 2004 18:47:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj2-0006WI-Cd for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C7fjx8020745 for sip-archive@odin.ietf.org; Thu, 12 Feb 2004 02:41:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBTB-0005EY-Sb; Thu, 12 Feb 2004 02:41:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBS9-0004rL-9S for sip@optimus.ietf.org; Thu, 12 Feb 2004 02:40:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12558 for ; Thu, 12 Feb 2004 02:40:02 -0500 (EST) From: Matthew.Gardiner@aculab.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBS5-0001M1-00 for sip@ietf.org; Thu, 12 Feb 2004 02:40:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBRM-0001Gi-00 for sip@ietf.org; Thu, 12 Feb 2004 02:39:17 -0500 Received: from [213.249.233.131] (helo=mx0.aculab.com) by ietf-mx with esmtp (Exim 4.12) id 1ArBQT-00019i-00 for sip@ietf.org; Thu, 12 Feb 2004 02:38:21 -0500 Received: from localhost (io.aculab.com [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id 332D14057; Thu, 12 Feb 2004 07:45:50 +0000 (GMT) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12809-08; Thu, 12 Feb 2004 07:45:46 +0000 (GMT) Received: from saturn.aculab.com (unknown [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 17A343FF0; Thu, 12 Feb 2004 07:45:46 +0000 (GMT) Received: by saturn.aculab.com with Internet Mail Service (5.5.2655.55) id <1S9PW38G>; Thu, 12 Feb 2004 07:39:01 -0000 Message-ID: <8C9A566C643ED6119E8900A0C9DE297A01F8645C@saturn.aculab.com> To: cthakker@ipnetfusion.com Cc: sip@ietf.org Subject: RE: [Sip] Record-Route and Contact Date: Thu, 12 Feb 2004 07:38:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F13B.44D155C0" X-Aculab-Com-Scanned: by amavisd-new-20030616-p5 (Debian) at aculab.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,CLICK_BELOW,HTML_20_30, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F13B.44D155C0 Content-Type: text/plain; charset="iso-8859-1" It's my understanding that Record-Route headers take precedence over the IP/FQDN in the contact header of the response, as they (Record-Route headers) are inserted by specifically by the proxies in order to influence the route that subsequent messaging takes. They influence, not only the route taken by the ACK, furthermore that taken by any subsequent requests. -----Original Message----- From: cthakker [mailto:cthakker@ipnetfusion.com] Sent: 11 February 2004 21:05 To: sip@ietf.org Subject: [Sip] Record-Route and Contact Hi all, If a UAC generates a request in Dialog (say an ACK for 200 it received), If the 200 had a Record-Route with loose routing and also a Contact header where should it route the request ? Can it route it directly to the IP/FQDN specified in the uri of Contact ? Does any header take precedence over other when generating a subsequent request in a Dialog ? Is the significance of Contact header end-to-end or between UAs. For the example given in the RFC 3261 (alice and bob), can the intermediate proxies modify the value of the Contact header in the response sent by Alice to Bob ? Thank you, Chintan ipNetFusion Inc, Dallas, Tx - 75080 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip For Aculab's privacy policy and E-Mail disclaimer, Click Here : http://www.aculab.com/company/legal_notice.htm. ------_=_NextPart_001_01C3F13B.44D155C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Record-Route and Contact

It's my understanding that Record-Route headers take = precedence over the IP/FQDN in the contact header of the response, as = they (Record-Route headers) are inserted by specifically by the proxies = in order to influence the route that subsequent messaging takes. They = influence, not only the route taken by the ACK, furthermore that taken = by any subsequent requests.

-----Original Message-----
From: cthakker [mailto:cthakker@ipnetfusion.com= ]
Sent: 11 February 2004 21:05
To: sip@ietf.org
Subject: [Sip] Record-Route and Contact


Hi all,
 If a UAC generates a request in Dialog (say an = ACK for 200 it received),
 
 If the 200 had a Record-Route with loose = routing and also a Contact
header where should it route the request ? Can it = route it directly to
the IP/FQDN specified in the uri of Contact ? Does = any header take
precedence over other when generating a subsequent = request in a Dialog ?
 Is the significance of Contact header = end-to-end or between UAs. For
the example given in the RFC 3261 (alice and bob), = can the intermediate
proxies modify the value of the Contact header in = the response sent by
Alice to Bob ?

 Thank you,

 Chintan
 ipNetFusion Inc,
 Dallas, Tx - 75080



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP = Protocol
Use sip-implementors@cs.columbia.edu for questions = on current sip
Use sipping@ietf.org for new developments on the = application of sip


For Aculab's privacy policy and E-Mail disclaimer, = Click Here : http://www.aculab.com/company/legal_notice.htm. =


------_=_NextPart_001_01C3F13B.44D155C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:47:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05575 for ; Tue, 30 Mar 2004 18:47:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006a4-W7 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239RCm6007238 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 04:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyScW-00019Z-PZ; Wed, 03 Mar 2004 04:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRql-0004rP-Fv for sip@optimus.ietf.org; Wed, 03 Mar 2004 03:35:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10997 for ; Wed, 3 Mar 2004 03:35:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRqP-0005yi-00 for sip@ietf.org; Wed, 03 Mar 2004 03:35:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRpQ-0005pQ-00 for sip@ietf.org; Wed, 03 Mar 2004 03:34:09 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRoW-0005Zj-00 for sip@ietf.org; Wed, 03 Mar 2004 03:33:12 -0500 Received: from softarmor.com (tx-dwillis.wireless.ietf59.or.kr [218.37.227.108]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i238X8sb008316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2004 02:33:10 -0600 Message-ID: <40459811.6000701@softarmor.com> Date: Wed, 03 Mar 2004 02:32:17 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Cullen Jennings , Brian Stucker , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers requirements References: <40452BCC.6080108@softarmor.com> <40458EE2.9000105@cisco.com> In-Reply-To: <40458EE2.9000105@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > If everyone followed your approach then there would be no need for gruus > to be assigned by REGISTER. Not at all. The truly magical bit about a GRUU is that it provides for a routing element to apply its allegedly greater level of topology information to provide a translation between the device's idea of its AoR and another AoR which provides superior reachability. GRUU, in this aspect, is based on the idea that information known to the registrar and that communicated to the UA can augment the request-routing function. The Instance ID concept, however, is based on the idea that information known to the UA and communicated to the registrar can also augment the request-routing function. I've pointed out here that other information known to the routing element, but not communicated to the user agent, can also augment the request-routing function, and that it does so sufficiently to meet the requirements established by the given use-case WITHOUT requiring any SIP extensions. GRUU and IntanceID overlap in part, as each results in an effectively unique contact value for each device associated with an AOR, such that each device can be appropriately targeted in those operations that require selecting one particular UA from the set of UAs associated with a given AOR. Clearly the same result can be applied by simply giving each UA associated with an AOR its own unique AOR. Dynamically-associated subaddressing of the sort proposed in both GRUU and Instance ID is simply an optimization of convenience. > The approach is somewhat attractive to me, > but I have a feeling it won't catch on. For one thing it has more > administrative cost, as well as some added hassle factor. (If I > already > have my personal AoR, I can fire up a new phone or soft phone, or > whatever and have it working without getting involved with the > bureaucracy that assigns new AoRs. Ah yes, but using this technique I can route my calls without getting involved with the bureacracy that assigns registration authority and allowable identities for registration. For example, this exact technique allows me to divert calls originally targeting my US desk phone number to my SIP AOR, and to then retarget those requests to my Korean mobile, without requiring the participation of my US phone operator or the Korean mobile provider. If I had to persuade my operator-issued 3GPP Rel 5 phone (if I had one) to register with an arbitrary third-party registrar, I suspect I'd have a problem. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:47:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05630 for ; Tue, 30 Mar 2004 18:47:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006ZK-AI for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T7MKXt016788 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 02:22:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLH4-0004D8-QU; Sun, 29 Feb 2004 02:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLGh-00040u-UF for sip@optimus.ietf.org; Sun, 29 Feb 2004 02:21:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09794 for ; Sun, 29 Feb 2004 02:21:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxLGe-0007XX-00 for sip@ietf.org; Sun, 29 Feb 2004 02:21:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxLFk-0007Rq-00 for sip@ietf.org; Sun, 29 Feb 2004 02:20:45 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxLEr-0007HF-01 for sip@ietf.org; Sun, 29 Feb 2004 02:19:50 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2004 23:31:10 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1T7JO4U029452; Sat, 28 Feb 2004 23:19:24 -0800 (PST) Received: from [172.16.37.243] (sjc-vpn3-75.cisco.com [10.21.64.75]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT64793; Sat, 28 Feb 2004 23:19:22 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 29 Feb 2004 05:45:09 +0900 Subject: Re: [Sip] draft-khartabil-sip-auth-analysis-00.txt From: Cullen Jennings To: , CC: Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797789@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/19/04 2:28 AM, "hisham.khartabil@nokia.com" wrote: > At this stage, the user should be prompted to enter new username/password. My > objection is to the text quoted below from RFC3261: > > " A service provider that pre-configures UAs with credentials for its > realm should be aware that users will not have the opportunity to > present their own credentials for this realm when challenged at a > pre-configured device". > > I think the users should have the opportunity. Just for arguments sake, let's say I agreed that users should have the opportunity. I really don't know what needs to change in the SIP stuff. Users are welcome to buy UA that give them this opportunity. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:48:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05668 for ; Tue, 30 Mar 2004 18:48:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006WI-LL for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T7MI0a016711 for sip-archive@odin.ietf.org; Sun, 29 Feb 2004 02:22:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLH8-0004Er-Mg; Sun, 29 Feb 2004 02:22:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLGj-00041D-55 for sip@optimus.ietf.org; Sun, 29 Feb 2004 02:21:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09797 for ; Sun, 29 Feb 2004 02:21:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxLGf-0007Xm-00 for sip@ietf.org; Sun, 29 Feb 2004 02:21:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxLFm-0007S5-00 for sip@ietf.org; Sun, 29 Feb 2004 02:20:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxLEs-0007HF-00 for sip@ietf.org; Sun, 29 Feb 2004 02:19:50 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2004 23:31:13 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1T7JR1m018251; Sat, 28 Feb 2004 23:19:27 -0800 (PST) Received: from [172.16.37.243] (sjc-vpn3-75.cisco.com [10.21.64.75]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT64796; Sat, 28 Feb 2004 23:19:24 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 29 Feb 2004 05:58:08 +0900 Subject: Re: [Sip] Query on sip-diversion draft From: Cullen Jennings To: Ajay Gupta , , CC: Steve Levy Message-ID: In-Reply-To: <20040121003049.18463.qmail@web20728.mail.yahoo.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3160916366_3881526" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3160916366_3881526 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The current version of levy-sip-diversion-07 and is in the internet drafts directory. The 08 version in my directory is identical to the 07 version in the internets draft directory and a mistake on my part naming it 08. You can search in the mailing list archives for previous threads on the status of this draft and history. Cullen On 1/20/04 4:30 PM, "Ajay Gupta" wrote: > Hi All, > > There was a draft-levy-sip-diversion-06.txt for diversion header processing > which had expired and has been removed from the IETF site. A new version of > the same draft draft-levy-sip-diversion-08.txt is available from > > www.employees.org/~fluffy/ietf/draft-levy-sip-diversion-08.txt > > but not on the IETF draft site. > > Moreover, as per one of the mail threads from the archives, it seems that > "History-Info header" is the way to go instead of "Diversion header". So, is > the "Diversion header" approach being dropped in favour of "History-Info > header" and what is the status of the "Diversion header" draft. Can anybody > provide information on these aspects. > > Thanks > > Ajay > > > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > 82/*http://hotjobs.sweepstakes.yahoo.com/signingbonus> --B_3160916366_3881526 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Sip] Query on sip-diversion draft
The current version of levy-sip-diversion-07 and is in the internet drafts = directory. The 08 version in my directory is identical to the 07 version in = the internets draft directory and a mistake on my part naming it 08.

You can search in the mailing list archives for previous threads on the sta= tus of this draft and history.

Cullen


On 1/20/04 4:30 PM, "Ajay Gupta" <agyml@yahoo.com> wrote:
Hi All,

There was a draft-levy-sip-diversion-06.txt for diversion header processing= which had expired and has been removed from the IETF site. A new version of= the same draft draft-levy-sip-diversion-08.txt is available from

www.employees.org/~fluffy/ietf/draft-levy-sip-diversion-08.txt

but not on the IETF draft site.

Moreover, as per one of the mail threads from the archives, it seems that &= quot;History-Info header" is the way to go instead of "Diversion h= eader". So, is the "Diversion header" approach being dropped = in favour of "History-Info header" and what is the status of the &= quot;Diversion header" draft. Can anybody provide information on these = aspects.

Thanks

Ajay

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes <http://pa.yahoo.co= m/*http://us.rd.yahoo.com/hotjobs/mail_footer_email/evt=3D21482/*http://hotjob= s.sweepstakes.yahoo.com/signingbonus>

--B_3160916366_3881526-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:48:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05790 for ; Tue, 30 Mar 2004 18:48:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006WI-4I for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HILJ7c019939 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 13:21:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9qI-00057m-P3; Tue, 17 Feb 2004 13:21:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9pq-000544-GC for sip@optimus.ietf.org; Tue, 17 Feb 2004 13:20:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24113 for ; Tue, 17 Feb 2004 13:20:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9po-00071i-00 for sip@ietf.org; Tue, 17 Feb 2004 13:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9ox-0006s8-00 for sip@ietf.org; Tue, 17 Feb 2004 13:19:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1At9nu-0006bq-00 for sip@ietf.org; Tue, 17 Feb 2004 13:18:42 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2004 10:27:38 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1HII94U016178; Tue, 17 Feb 2004 10:18:09 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC54759; Tue, 17 Feb 2004 13:18:08 -0500 (EST) Message-ID: <40325ADF.30508@cisco.com> Date: Tue, 17 Feb 2004 13:18:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org References: <402FF85F.4020202@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-resource-priority-02 - Table 2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning, Regarding changes to Table 2, some things still seem wrong: - Now that Resource-Priority is optional in all requests, shouldn't Accept-Resource-Priority be permitted in 420 responses to all the same messages? - Shouldn't the R-P be optional in responses to any request where it was permitted? - If A-R-P is mandatory in 417 responses to SUB, NOT, and MSG, shouldn't it also be mandatory (rather than optional) in 417 response to INVITE? And by logic just above, shouldn't it be mandatory in responses to any message where R-P is optional? - So I think the table probably ought to look like: Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Resource-Priority R amd o o o o o o o Resource-Priority 200 - o o o o o o o Accept-Resource-Priority 200 - o o o o o o o Accept-Resource-Priority 417 - m m m m m m m Accept-Resource-Priority 420 - o o o o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Resource-Priority R amd o o o o o o o Resource-Priority 200 - o o o o o o o Accept-Resource-Priority 200 - o o o o o o o Accept-Resource-Priority 417 - m m m m m m m Accept-Resource-Priority 420 - o o o o o o o In section 4.1, why do you single out INVITE, MESSAGE, UPDATE, SUBSCRIBE and NOTIFY, but omit ACK and PRACK? If INVITE is important, then ACK and PRACK must be important too. This probably isn't an issue in a UAS, because it considers those to be part of the INVITE. But it could make a difference in a proxy. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:48:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05918 for ; Tue, 30 Mar 2004 18:48:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006ZK-09 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1P3jP023191 for sip-archive@odin.ietf.org; Sat, 28 Feb 2004 20:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgv-0005lF-Kw; Sat, 28 Feb 2004 20:24:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFOo-0004NV-NS for sip@optimus.ietf.org; Sat, 28 Feb 2004 20:05:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13824 for ; Sat, 28 Feb 2004 20:05:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFOm-0002JS-00 for sip@ietf.org; Sat, 28 Feb 2004 20:05:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFNm-0002Co-00 for sip@ietf.org; Sat, 28 Feb 2004 20:04:39 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFNI-00025B-00 for sip@ietf.org; Sat, 28 Feb 2004 20:04:08 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1T13Zr16232 for ; Sat, 28 Feb 2004 19:03:36 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CK11GG>; Sun, 29 Feb 2004 01:03:34 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B3EF7B2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Gonzalo Camarillo'" , "'Tom Taylor'" Cc: "'Christer Holmberg (JO/LMF)'" , "'sip'" , "'Rohan Mahy'" , "'Dean Willis'" Subject: RE: [Sip] Re: INFO Documentation (was Re: Defining new requests) Date: Sun, 29 Feb 2004 01:03:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is an revision requirement to INFO, not to an interworking specification, so it should be in SIP, not in SIPPING. It is the core INFO RFC that is itself not complete enough in this area. Note that part of that revision should also be to update the RFC 2543 references to RFC 3261. regards Keith > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 26 February 2004 12:26 > To: Tom Taylor > Cc: Christer Holmberg (JO/LMF); sip; Rohan Mahy; Dean Willis > Subject: [Sip] Re: INFO Documentation (was Re: Defining new requests) > > > Tom. > > it seems that what you want is an update of the INFO spec, > rather than > fixing a few errata. I believe that we cannot meet your timeframe. In > any event, it would be great we could start working on a solution for > INFO in SIPPING, so that the ITU could reference it in the future. > > Thanks, > > Gonzalo > > Tom Taylor wrote: > > > Q.1912.5 is in the process of final approval. Logging > errata may be > > satisfactory -- I'd have to check. It would certainly be more > > comfortable than reproducing the RFC with modifications in the ITU > > document. If the IETF acts within the next two weeks we > should be able > > to remove the Annex from the Recommendation. > > > > Here is the current list of changes as reported at the > beginning of the > > Annex. > > > > "The SIP INFO method is documented in RFC 2976. However, > that RFC refers > > to RFC 2543, the previous version of the SIP specification, > rather than > > to RFC 3261. The text of this Annex reproduces RFC 2976 > with changes to > > reflect the updated reference. > > > > "The changes made are as follows: > > > > "Paragraph C.3.2.1: The references to the tables of RFC2543 > were changed > > to reflect the new table organization in RFC 3261. > > > > "Paragraph C.3.2: The tables 1 and 2 were replaced by new > tables that > > show the header fields defined as presented in RFC3261. All > additional > > headers (additional to RFC 2543) used within RFC3261 were > here set to > > optional with two exceptions. The Reply-To (only optional for the > > INVITE) and Call-Info Header (only used for INVITE, > OPTIONS, REGISTER to > > give additional information about the caller or callee) are > not used > > with the INFO method. > > > > "Paragraph C.3.6: The reference was changed to the current SIP > > specification, RFC 3261. > > > > > > Gonzalo Camarillo wrote: > > > >> Tom, > >> > >> what is the timeframe here? As you know, we have had > discussions in > >> the past about either re-defining INFO so that it can only > carry PSTN > >> telephony signalling, or defining INFO packages. We could re-start > >> those discussions, and once we reach a conclusion, clarify > the rules > >> to send INFO from the UAS within early dialogs in the same spec... > >> > >> If the ITU is in a hurry, other solutions may be better, > like logging > >> an errata against the INFO RFC. > >> > >> Gonzalo > >> > >> Tom Taylor wrote: > >> > >>> The ITU-T (Study Group 11, to be exact) had a different > issue with > >>> INFO: that the RFC depends on RFC 2543 rather than 3261. As a > >>> result, they picked up the content of RFC 2976 as Annex > C.3 of the > >>> ISUP interworking specification Q.1912.5. If RFC 2976 ever gets > >>> updated Annex C.3 can be deprecated. In the meantime, this INFO > >>> question means we have some maintenance to perform. I > think the best > >>> solution will be to take Gonzalo's suggestion and say that INFO > >>> follows the rules for UPDATE. We already have a > normative dependency > >>> on the UPDATE RFC. > >>> > >>> Gonzalo Camarillo wrote: > >>> > >>>> Christer, > >>>> > >>>> would the ITU-T be happier if we log an errata against > the INFO RFC > >>>> saying that UASs can send INFO within early dialogs? > >>>> > >>>> Gonzalo > >>>> > >>>> Christer Holmberg (JO/LMF) wrote: > >>>> > >>>>> Hi Gonzalo, > >>>>> > >>>>> Thanks for your reply! > >>>>> > >>>>> > >>>>>> it seems that some people in the ITU-T are having some issues > >>>>>> figuring out whether or not certain requests can be > sent by the UAS > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> within an > >>>>> > >>>>>> early dialog. The confusion comes from statements like > this one > >>>>>> (taken from the INFO spec): > >>>>>> > >>>>>> " Unless stated otherwise, the protocol rules for the INFO > >>>>>> request > >>>>>> governing the usage of tags, Route and Record-Route, > >>>>>> retransmission and reliability, CSeq > incrementing and message > >>>>>> formatting follow those in [1] as defined for > the BYE request." > >>>>>> > >>>>>> Since a UAS does not send BYEs within an early dialog, but a > >>>>>> non-2xx final response instead, to terminate the > dialog, people > >>>>>> assume that > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> INFO > >>>>> > >>>>>> cannot be sent in this situation either. > >>>>>> > >>>>>> Let's try to keep this in mind and clarify this point > when/if we > >>>>>> define new SIP methods. > >>>>>> > >>>>>> In any event, the clarification to this issue can be > found in RFC > >>>>>> 3398: > >>>>>> > >>>>>> "From the callee to the caller, if a message is > received by a gateway > >>>>>> before the call has been answered (i.e., ANM is received) it > >>>>>> SHOULD be encapsulated in an INFO, provided that this > will not be > >>>>>> the first SIP message sent in the backwards direction > (in which > >>>>>> case it SHOULD be encapsulated in a provisional 1xx response)." > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The problem is that the ITU-T interworking spec doesn't > reference > >>>>> RFC3398. The spec reference the INFO RFC, and that is > also where I > >>>>> think > >>>>> the usage rules should be defined (not in another spec, > RFC3398 in > >>>>> this > >>>>> case, simply using the method). > >>>>> > >>>>> The INFO RFC, as you said, currently says that INFO > "follows the rules > >>>>> of BYE" (whatever that means is another question :), > and the rules for > >>>>> BYE specifically says that it must not be sent backward > before the > >>>>> INVITE has finished. If the INFO RFC would say "follow > the rules of > >>>>> UPDATE" we would not have this problem, since the UPDATE spec > >>>>> specifically allows the use of the method before the INVITE has > >>>>> finished. > >>>>> > >>>>> Thanks! > >>>>> > >>>>> Christer Holmberg > >>>>> Ericsson Finland > >>>> > >>>> > >>>> > >> > >> > >> This communication is confidential and intended solely for the > >> addressee(s). Any unauthorized review, use, disclosure or > distribution > >> is prohibited. If you believe this message has been sent to you in > >> error, please notify the sender by replying to this > transmission and > >> delete the message without disclosing it. Thank you. > >> > >> E-mail including attachments is susceptible to data corruption, > >> interruption, unauthorized amendment, tampering and > viruses, and we > >> only send and receive e-mails on the basis that we are not > liable for > >> any such corruption, interception, amendment, tampering or > viruses or > >> any consequences thereof. > >> > >> > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > > This communication is confidential and intended solely for > the addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has > been sent to you in error, please notify the sender by > replying to this transmission and delete the message without > disclosing it. Thank you. > > E-mail including attachments is susceptible to data > corruption, interruption, unauthorized amendment, tampering > and viruses, and we only send and receive e-mails on the > basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:50:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06288 for ; Tue, 30 Mar 2004 18:50:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj0-0006ZK-8D for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OArGhv012017 for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 06:53:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzZ6-0002yb-1m; Fri, 24 Oct 2003 06:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzY7-0002rc-IP for sip@optimus.ietf.org; Fri, 24 Oct 2003 06:52:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25037 for ; Fri, 24 Oct 2003 06:51:44 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACzXs-0001Qp-00 for sip@ietf.org; Fri, 24 Oct 2003 06:51:53 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ACzXs-0001Qm-00 for sip@ietf.org; Fri, 24 Oct 2003 06:51:52 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OAprI05372 for ; Fri, 24 Oct 2003 13:51:53 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 24 Oct 2003 13:51:53 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 13:51:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Oct 2003 13:51:45 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179731D@esebe019.ntc.nokia.com> Thread-Topic: Authentication-Info header: Who can add it to a 2xx response Thread-Index: AcOaHMwZ6eyPps2JQ7q0y/MPc0vN8w== To: X-OriginalArrivalTime: 24 Oct 2003 10:51:53.0158 (UTC) FILETIME=[D5B38660:01C39A1C] Content-Transfer-Encoding: quoted-printable Subject: [Sip] Authentication-Info header: Who can add it to a 2xx response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Can a proxy add an Authentication-info header to a 2xx response it did = not create, if it had earlier responded with a 407? If the answer is yes, then I would think that the client needs to create = a cnonce that is unique for every digest-response to a challenge, and = consequently, it must be mandated for the proxy reflect this cnonce is = the Authentication-info header. If the answer is no, then why is there allowed multiple = authentication-info headers (See ABNF)? Thanks, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:52:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07001 for ; Tue, 30 Mar 2004 18:52:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006ZK-W8 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1P3ja023190 for sip-archive@odin.ietf.org; Sat, 28 Feb 2004 20:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgy-0005nT-Ed; Sat, 28 Feb 2004 20:24:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFPa-0004OS-GU for sip@optimus.ietf.org; Sat, 28 Feb 2004 20:06:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13838 for ; Sat, 28 Feb 2004 20:06:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFPY-0002OE-00 for sip@ietf.org; Sat, 28 Feb 2004 20:06:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFOa-0002HX-00 for sip@ietf.org; Sat, 28 Feb 2004 20:05:29 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFNc-00026f-00 for sip@ietf.org; Sat, 28 Feb 2004 20:04:28 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1T13tr16428 for ; Sat, 28 Feb 2004 19:03:56 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CK11GJ>; Sun, 29 Feb 2004 01:03:54 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B3EF7B5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Rosen, Brian'" , "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] changes in session timer Date: Sun, 29 Feb 2004 01:03:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Is charging considerations within the requirements for session timer. There was considerable discussion of this issue a couple of years back, and I thought that the charging use case was eliminated from the requirements at that time. regards Keith > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 25 February 2004 13:55 > To: 'Jonathan Rosenberg'; sip@ietf.org > Subject: RE: [Sip] changes in session timer > > > > * There is now an absolute minimum session timer of 90 > > seconds. This is > > basically enough time for completion of a SIP BYE transaction > > after half > > of the session has expired. The Min-SE header field now has > a default > > value of 90 seconds when not present. This will preclude usage of > > session timer for really fine grained refreshes, say on the > > order of 5 > > to 10 seconds. I fear that some people may be trying to do > > some kind of > > nat traversal or something with session timer - this would > > rule that out > > formally (it was never the intended usage). > I know whenever we bring up billing people turn off, but one > of the things > session timer is useful for is to tear down calls that got > hosed somewhere. > Making the min 90 seconds means you could not use the > mechanism -- you would > have to have some other mechanism that didn't distort your > billing record > so much. 90 seconds is an eternity in human time. > > Somehow, precluding use for NAT binding keepalive doesn't sound like > a good enough reason to have such a high min. I frankly > don't understand > why there has to be a min at all; surely it depends on the > characteristics > of the network the session traverses. > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:52:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07067 for ; Tue, 30 Mar 2004 18:52:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006ZK-My for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RNxemf025805 for sip-archive@odin.ietf.org; Tue, 27 Jan 2004 18:59:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald6w-0006Wl-MN; Tue, 27 Jan 2004 18:59:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al9mK-00021P-NB for sip@optimus.ietf.org; Mon, 26 Jan 2004 11:40:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12272 for ; Mon, 26 Jan 2004 11:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al9mJ-0007OJ-00 for sip@ietf.org; Mon, 26 Jan 2004 11:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al9lM-0007Lf-00 for sip@ietf.org; Mon, 26 Jan 2004 11:39:01 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Al9ku-0007Is-00 for sip@ietf.org; Mon, 26 Jan 2004 11:38:32 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0QGbx9W009036; Mon, 26 Jan 2004 11:38:01 -0500 (EST) Message-ID: <40154262.9010400@dynamicsoft.com> Date: Mon, 26 Jan 2004 11:37:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: sip@ietf.org Subject: Re: [Sip] querying the current event state of a publication References: <4012E741.5000809@dynamicsoft.com> <40152C68.8030802@cisco.com> In-Reply-To: <40152C68.8030802@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: >> If we want this functionality, I have an idea for an alternative >> approach that works much better, triggered by some conversations I had >> with Ben C. recently. > > > That's a big IF. Do we really want to mandate that every compositor must > be prepared to provide this? It certainly puts contraints on the > implementations, and in most cases I think publishers can be constructed > so that they don't need this capability. The main constraint I think it introduces is that the compositor needs to keep around the presence documents from each individual source, in addition to the final result of composition. I am not sure if this is new; I don't know how it couuld do composition without keeping these around. > > I think the only time you might need this event state is when partial > publication is in use and the publisher has forgotten the full state, Yes, I agree this is one possible use case. > or > when a backup publisher is trying to pick up from another one. In the > former case, there is no real advantage over simply transmitting the > full state as a refresh - same amount of data is required. A fair point. > > The advisability of supporting the latter case seems questionable to me. > There is a lot of work in providing a real failover backup, and it might > as well include remembering the state locally. If this capability is > provided we run the risk of abetting the construction of dualing > endpoints competing to publish particular event state. I think that is a consequence of a backup takinig over publication for a primary, not a consequence of reading the current presence state or not. > > But, if in the end there is a good argument for this capability, then > the proposal for how to do it seems reasonable. My suggestion was mostly along the lines of - this is a good way to do it, rather than, we should have this feature. I recall there was a 3gpp requrement for it, and I remember asking why it was there, and I dont remember the answer, in fact. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:53:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07157 for ; Tue, 30 Mar 2004 18:53:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006ZK-AI for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PK9Ybp002393 for sip-archive@odin.ietf.org; Wed, 25 Feb 2004 15:09:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5LJ-0000ae-1b; Wed, 25 Feb 2004 15:09:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5K9-0008BD-6o for sip@optimus.ietf.org; Wed, 25 Feb 2004 15:08:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09564 for ; Wed, 25 Feb 2004 15:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5K6-0004t6-00 for sip@ietf.org; Wed, 25 Feb 2004 15:08:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5JQ-0004nr-00 for sip@ietf.org; Wed, 25 Feb 2004 15:07:20 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw5In-0004hC-00 for sip@ietf.org; Wed, 25 Feb 2004 15:06:41 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1PK6KNr009305; Wed, 25 Feb 2004 15:06:22 -0500 (EST) Message-ID: <403D0025.7070209@dynamicsoft.com> Date: Wed, 25 Feb 2004 15:05:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarit Galanos CC: sip@ietf.org Subject: Re: [Sip] RPORT and TCP References: <10DA2C035FE3BC4FA8D73EC55FC43D9B0479F9@rvil-mail.radvision.com> In-Reply-To: <10DA2C035FE3BC4FA8D73EC55FC43D9B0479F9@rvil-mail.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit responses inline. Sarit Galanos wrote: > Hi, > RFC 3581-Symmetric Response Routing specifies that the rport parameter should be used only if the transport is unreliable. > > "When a server attempts to send a response, it examines the topmost > Via header field value of that response. If the "sent-protocol" > component indicates an unreliable unicast transport protocol, such as > UDP, and there is no "maddr" parameter, but there is both a > "received" parameter and an "rport" parameter, the response MUST be > sent to the IP address listed in the "received" parameter, and the > port in the "rport" parameter. The response MUST be sent from the > same address and port that the corresponding request was received on. > This effectively adds a new processing step between bullets two and > three in Section 18.2.2 of SIP [1]." > > As I see it, the same problem that rport solves in UDP can happen in TCP. No, thats not the case. rport is addressing a very specific problem, which is that in UDP, responses are sent to the source IP of the request, but to the port in the Via. This odd mix of addressing is totally incompatible with NAPT. However, with TCP, "standard" connection usage applies - the response is sent on the same connection as the request. > This can happen if the connection is broken between the request and the response. > > If for example the Via header in the request is: > > Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bKkjsh77 > > and proxy.example.com was resolved to a port different then 5060, the server will not be able to > establish a new connection in order to send the response since 5060 will be used. Thats the desired behavior. The idea is that, as long as the "connection" - which includes the TCP connection, but also any NAPT binding, still exists, that gets used for the response. However, should that connection/binding fail, the response is sent using a new connection, opened to the listen port that the client is expecting new reuests to arrive on. That generally is NOT an ephemeral port, and the re-establishment would only work in absence of NAT or if there are configured port forwarding rules. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:54:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07495 for ; Tue, 30 Mar 2004 18:54:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riu-0006YH-Ew for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGgi1X028610 for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 11:42:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8vS-000786-Lw; Tue, 18 Nov 2003 11:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8vE-00077Z-PM for sip@optimus.ietf.org; Tue, 18 Nov 2003 11:41:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29550 for ; Tue, 18 Nov 2003 11:41:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8vD-0000VZ-00 for sip@ietf.org; Tue, 18 Nov 2003 11:41:47 -0500 Received: from pooh.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1AM8vD-0000VW-00 for sip@ietf.org; Tue, 18 Nov 2003 11:41:47 -0500 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id LAA11170; Tue, 18 Nov 2003 11:41:42 -0500 (EST) From: "Tolga Asveren" To: "Chong, Koan S, ALABS" , "Frank W. Miller" , "McCandless, Kevin" Cc: Subject: RE: [Sip] Sip support for TCAP queries Date: Tue, 18 Nov 2003 11:41:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01C3ADC8.EC15EC30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F0B1C3C@KCCLUST06EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C3ADC8.EC15EC30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chong, Koan S, ALABS Sent: Tuesday, November 18, 2003 11:27 AM To: Frank W. Miller; McCandless, Kevin Cc: sip@ietf.org Subject: RE: [Sip] Sip support for TCAP queries A couple specific questions: What is the recommendation on how a SIP network element can access the callers' name databases (CNAM in US) in PSTN after the SIP element has determined that the called parties have subscribed to Caller ID? [TOLGA]Is this really a problem to be addressed by SIP? IMO, that an entity has a SIP interface does not mean, that any of it needs should be addressed by SIP. I would think you just use TCAP(with or without SIGTRAN) or use any other protocol, the name database is capable of understanding. How about interworking with CLASS Auto-Recall/Callback (CCBS in ITU?) procedures? Assume TCAP over SIGTRAN is a bit long long term.... [TOLGA]Why? M3UA/M2UA are already RFC and M2PA/SUA are close to be RFC. Koan Koan S.Chong AT&T 1-732-420-4557 -----Original Message----- From: Frank W. Miller [mailto:fmiller@sentito.com] Sent: Monday, November 17, 2003 6:18 PM To: 'McCandless, Kevin' Cc: sip@ietf.org Subject: RE: [Sip] Sip support for TCAP queries You mean other than us implementing it? No, I don't think so. I think its considered Rosemary's Baby by most. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of McCandless, Kevin Sent: Monday, November 17, 2003 4:11 PM To: sip@ietf.org Subject: [Sip] Sip support for TCAP queries Has any progress been taken on the draft by Frank Miller on Carrying TCAP in SIP messages? Are there other drafts that address SIP access to SS7 database information through TCAP or another method? Thanks, Kevin ------=_NextPart_000_00A5_01C3ADC8.EC15EC30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Chong, Koan S,=20 ALABS
Sent: Tuesday, November 18, 2003 11:27 = AM
To: Frank=20 W. Miller; McCandless, Kevin
Cc: = sip@ietf.org
Subject: RE:=20 [Sip] Sip support for TCAP queries

 
A=20 couple specific questions:
 
What is the recommendation on how a SIP network element can = access the=20 callers' name databases (CNAM in US) in PSTN after the SIP element has = determined that the called parties have subscribed to Caller ID? 
[TOLGA]Is this really a = problem to be=20 addressed by SIP? IMO, that an entity has a SIP interface = does not=20 mean, that any of it needs should be addressed by SIP. I would think = you just=20 use TCAP(with or without SIGTRAN) or use any other protocol, = the=20 name database is capable of=20 understanding.
 
How=20 about interworking with CLASS Auto-Recall/Callback (CCBS in ITU?)=20 procedures?
 
Assume TCAP over SIGTRAN is a bit long long = term.... 
[TOLGA]Why? M3UA/M2UA are=20 already RFC and M2PA/SUA are close to=20 be RFC. 
 
Koan
Koan=20 S.Chong
AT&T
1-732-420-4557
 
-----Original Message-----
From: Frank W. Miller=20 [mailto:fmiller@sentito.com]
Sent: Monday, November 17, = 2003 6:18=20 PM
To: 'McCandless, Kevin'
Cc:=20 sip@ietf.org
Subject: RE: [Sip] Sip support for TCAP=20 queries

 

You mean = other than=20 us implementing it?  No, I don’t think so.  I think = its considered=20 Rosemary’s Baby by most…

 

FM

 

 

Frank W. = Miller,=20 Ph.D.

Chief = Technical=20 Officer

sentitO = Networks,=20 Inc.

fmiller@sentito.com

 

-----Original=20 Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of McCandless,=20 Kevin
Sent: = Monday,=20 November 17, 2003 4:11 PM
To: sip@ietf.org
Subject: [Sip] Sip support = for TCAP=20 queries

 

Has any progress been = taken on=20 the draft by Frank Miller on Carrying TCAP in SIP messages?  = Are there=20 other drafts that address SIP access to SS7 database information = through=20 TCAP or another method?

 

Thanks,

 

Kevin=20

------=_NextPart_000_00A5_01C3ADC8.EC15EC30-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:55:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07716 for ; Tue, 30 Mar 2004 18:55:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006WI-CA for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOFXYcD008282 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 10:33:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOIh0-0001MK-3G; Mon, 24 Nov 2003 10:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOIgA-0001Ez-CN for sip@optimus.ietf.org; Mon, 24 Nov 2003 10:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12551 for ; Mon, 24 Nov 2003 10:30:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOIg8-0006ny-00 for sip@ietf.org; Mon, 24 Nov 2003 10:31:08 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AOIg7-0006nd-00 for sip@ietf.org; Mon, 24 Nov 2003 10:31:07 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hAOFUbYb002682 for ; Mon, 24 Nov 2003 09:30:37 -0600 (CST) Received: from ericsson.com (rvi2-92-57.sw.ericsson.se [153.88.92.57]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XH3ZAF3A; Mon, 24 Nov 2003 09:30:29 -0600 Message-ID: <3FC22416.7070303@ericsson.com> Date: Mon, 24 Nov 2003 17:30:30 +0200 X-Sybari-Trust: 552bee27 6fa56f4d 0641cb9c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-rfc3312-update-00.txt References: <200311212104.QAA02564@ietf.org> In-Reply-To: <200311212104.QAA02564@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, this draft is pretty much finished. In Minneapolis, there was an agreement that this is something we overlooked when writing RFC 3312 and that it has to be fixed. This is the fix. Have a look at it and send us your comments. It is a fairly short draft. Thanks, Gonzalo Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : Interactions of Preconditions with Session Mobility in the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo > Filename : draft-ietf-sip-rfc3312-update-00.txt > Pages : 8 > Date : 2003-11-21 > > This document describes how to use SIP preconditions in situations > that involve session mobility. This document updates RFC3312, which > defines the framework for SIP preconditions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc3312-update-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-rfc3312-update-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-rfc3312-update-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:56:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07974 for ; Tue, 30 Mar 2004 18:56:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006ZK-3t for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KE7h4o023159 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 10:07:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0iBX-0002yS-V5; Sat, 20 Sep 2003 09:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ojg-0001V2-Bu for sip@optimus.ietf.org; Fri, 19 Sep 2003 13:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06751 for ; Fri, 19 Sep 2003 12:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0ByY-0000Jv-00 for sip@ietf.org; Thu, 18 Sep 2003 23:30:30 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A0Bo9-0006SK-00 for sip@ietf.org; Thu, 18 Sep 2003 23:19:45 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Sep 2003 20:16:19 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8J3JEHm004063; Thu, 18 Sep 2003 20:19:14 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALS50165; Thu, 18 Sep 2003 20:06:58 -0700 (PDT) Date: Thu, 18 Sep 2003 18:06:34 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Bob Penfield" From: Rohan Mahy In-Reply-To: <002801c37924$4868b0f0$2300000a@BPenfield> Message-Id: <83716016-EA3D-11D7-A981-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bob, Comments inline. On Friday, September 12, 2003, at 04:52 AM, Bob Penfield wrote: > ----- Original Message ----- > From: "Rosen, Brian" > >> It doesn't address dial strings, which is a big problem. >> For example >>>> Otherwise, the 'local-phone-number' (from Table 4 of >>>> 2543) should apply. >> is problematic I think. >> >> I don't have a problem with the "+" or phone context >> and user=phone implying it's equivalent to a tel uri. >> > > If we allow user=phone without the restriction that the userinfo be a > tel-URI (i.e. neither a + or a phone-context present), it would allow > the > userinfo to be a dial string (which 2543's local-phone-number allows) what is the the difference between a dial string and a a phone number? according to 2806bis, a phone-number is just 1*phonedigit . it sure seems like a dial string can be expressed in there. the only requirement then to have a valid tel-URI is to tack on a phone-context parameter. this is trivial string concatenation. > with > the assumption that the SIP server of the host/domain of the SIP-URI > knows > how to interpret it. as Dean has already demonstrated that, you don't need ;user=phone to do that. I don't see any value in having a special parameter (user=phone) unless it implies some structure. You can already send unstructured dial strings in an ordinary SIP URI with user=ip. There is no need IMO to have *two different* ways of expressing unstructured dial strings. > I believe this is the way that a lot of implementations > use user=phone now. as we've seen at SIPit and on this thread, there are implementations using every conceivable semantic for this little parameter. If we use unstructured strings we will break some other implementations. Lets pick one semantic and go forward. No matter what we will pick we will break something, so we should pick the right thing. > Having dial plans in the endpoints may not be practical > from a maintenance perspective unless there is a standard way for the > endpoint to download a dial plan. First of all, we are working on a standard mechanism to enable configuration of phones and the like, which I certainly hope will include dial plans. Even without such a mechanism, it is trivial for the endpoint to either use a SIP URI in the proper domain (use user=ip), or to generate a valid tel URI as the userinfo part and user user=phone, by tacking on a phone-context parameter after the dialed string. For example: sip:f69;phone-context=+14085264123@example.com;user=phone ... means that someone dialed *69 in the context of +14085264123 sip:*69@abc.example.com ... means that someone INVITEd *69 in the abc.example.com domain. you might want to interpret that. sip:555;phone-context=peoria-pbx.acme.com@example.net;user=phone ... means that someone dialed 555 in the context of peoria-pbx.acme.com sip:901144203456789;phone-context=rmahy,cisco.com@example.net;user=phone ... can mean that rohan dialed 9-011-44-20-345 6789 a proxy can now very easily interpret these dial plans according to the appropriate context. It can pass these URIs around to any proxy in the world without danger of accidentally misinterpreting them. Requests which go to a proxy that doesn't understand a particular context will get rejected with a 404 (this is a GOOD thing). This is a significant improvement over a misrouted request doing something really wring or unexpected by interpreting a dial string in the wrong context. > It is often more practical to have the > proxy interpret a dial string. fine. I've already demonstrated 2 ways to do that without polluting the semantics of userinfo when user=phone. > I think we need to specify user=phone in a backward compatible way that > matches the way most implementations use it today. as I said above, there is no backwards compatible solution, since everyone is using different conventions and semantics. lets just fix the problem and move on. thanks, -rohan > cheers, > (-:bob > >> Brian >> >>> -----Original Message----- >>> From: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Sent: Thursday, September 11, 2003 10:27 AM >>> To: Christer Holmberg (JO/LMF); 'Bob Penfield'; sip@ietf.org >>> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone >>> >>> >>> >>> Hi, >>> >>> So, is Bob's proposal something which could be accepted, or >>> at least worked futher on? >>> >>> Regards, >>> >>> Christer Holmberg >>> Ericsson Finland >>> >>> >>>> -----Original Message----- >>>> From: Christer Holmberg (JO/LMF) >>>> Sent: 4. syyskuuta 2003 13:14 >>>> To: 'Bob Penfield'; sip@ietf.org >>>> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone >>>> >>>> >>>> >>>> Hi, >>>> >>>> I would support Bob's proposal, saying that a "+" indicates >>>> global-phone-number, according to RFC2806(or bis). I don't >>>> think there would be any backward compability issues, because >>>> I doubt anyone is using "+" for any other purpose - at least >>>> not as the first character of the user part. Of course, nodes >>>> that really REQUIRE user=phone to be present, in order to >>>> accept the request in the first, place would have to be changed. >>>> >>>> Of course, user=tel could also be used, but I really see no >>>> use for that if the "+" rule applies. Also, user=tel COULD >>>> cause backward compability issues. >>>> >>>> Then, since there doesn't seem to be an agreement on what >>>> user=phone really means, related BOTH to the userpart syntax >>>> and the message routing, we could remove it completely. >>>> >>>> Regards, >>>> >>>> Christer Holmberg >>>> Ericsson Finland >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Bob Penfield [mailto:bpenfield@acmepacket.com] >>>>> Sent: 4. syyskuuta 2003 2:43 >>>>> To: sip@ietf.org >>>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone >>>>> >>>>> >>>>> Getting back to the problem Robert described in the >>>> original mail, the >>>>> interoperability problems are a result of that fact that what >>>>> is a valid >>>>> userinfo part of a SIP URL with a user=phone parameter has >>>>> steadily gotten >>>>> stricter without any consideration for backwards >>>>> compatibility. The specific >>>>> problem he described resulted because a SIP URL created with >>>>> 2543 rules was >>>>> rejected by a server applying 3261/2806 rules. The new >>>>> 2806bis rules are >>>>> even stricter. I have no problem with those rules for tel-URLs. >>>>> >>>>> In spite of the lack of normative text on user-phone, the >>>>> statements in 2543 >>>>> and 3261 to the effect that it is used to distinguish phone >>>>> numbers from >>>>> usernames leads one to the reasonable conclusion that when it >>>>> is present, >>>>> the 'telephone-subscriber' BNF applies. This is the >>>>> conclusion that we and a >>>>> number of our vendors and customers came to when we ran >>> into interop >>>>> problems. >>>>> >>>>> However, its not that simple since a 'telephone-subscriber' >>>>> keeps changing. >>>>> >>>>>> From some of the posting on this subject, there seems to >>>> be value in >>>>> distinguishing a telephone number from username that happens >>>>> to look like a >>>>> telephone number without requiring that the user part be a >>>>> tel-URL. What I >>>>> would propose is that while we make the rules for user=phone >>>>> clearer, they >>>>> ought to be closer to the 2543 rules which in my >>> experience a lot of >>>>> existing implementation seem to follow. If the userinfo >>>>> begins with "+" or >>>>> contains a phone-context, then it is reasonable to >>> interpret it as a >>>>> tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of >>>>> 2543) should >>>>> apply. A server which is not responsible for the domain of >>>> the SIP URL >>>>> should not reject a SIP URL because phone-context is missing. >>>>> Actually, I >>>>> believe it is reasonable to take the SIP URL host part as the >>>>> 'default' >>>>> phone-context when it is missing. >>>>> >>>>> Also, we could add 'user=tel' for userinfo that MUST be >>>>> tel-URLs. In that >>>>> case, rejecting a local number without a phone-context would >>>>> be perfectly >>>>> reasonable. >>>>> >>>>> cheers, >>>>> (-:bob >>>>> >>>>> Robert F. Penfield >>>>> Chief Software Architect >>>>> Acme Packet, Inc. >>>>> 130 New Boston Street >>>>> Woburn, MA 01801 >>>>> bpenfield@acmepacket.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the >>> application of sip >>>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:56:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08137 for ; Tue, 30 Mar 2004 18:56:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riv-0006Yx-Sq for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD7fGXu026418 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:41:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKC6K-0006r6-0a; Thu, 13 Nov 2003 02:41:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKC5r-0006hi-NP for sip@optimus.ietf.org; Thu, 13 Nov 2003 02:40:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15184 for ; Thu, 13 Nov 2003 02:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKC5n-0000Av-00 for sip@ietf.org; Thu, 13 Nov 2003 02:40:39 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKC5m-0000AW-00 for sip@ietf.org; Thu, 13 Nov 2003 02:40:38 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD7dxca016526; Thu, 13 Nov 2003 02:39:59 -0500 (EST) Message-ID: <3FB3354C.6020802@dynamicsoft.com> Date: Thu, 13 Nov 2003 02:39:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Alan Johnston'" , seancolson@yahoo.com, "'Cullen Jennings'" , sip@ietf.org, "'Paul Kyzivat'" , oritl@microsoft.com Subject: Re: [Sip] GRUU, Contacts, and privacy References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FE@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865FE@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree, and I believe this was the consensus at the meeting as well. Interestingly, the current requirements document: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-gruu-reqs-01.txt doesnt actually have any privacy requirements at all. So, there is nothing to remove :) -Jonathan R. Adam Roach wrote: > Alan Johnston [mailto:alan.johnston@mci.com] writes: > > > I agree 100%. A private Contact URI is just one small piece > > of the privacy puzzle. I think this privacy requirement should > > be removed. > > I further agree. > > /a > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:57:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08191 for ; Tue, 30 Mar 2004 18:57:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riv-0006ZK-U0 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1FeNib024285 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 10:40:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQq9k-0006IK-FN; Mon, 01 Dec 2003 10:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQq99-0006Be-QK for sip@optimus.ietf.org; Mon, 01 Dec 2003 10:39:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15204 for ; Mon, 1 Dec 2003 10:39:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQq97-0003Rc-00 for sip@ietf.org; Mon, 01 Dec 2003 10:39:33 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQq96-0003R9-00 for sip@ietf.org; Mon, 01 Dec 2003 10:39:33 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 07:41:44 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB1Fcwjq001445; Mon, 1 Dec 2003 07:38:59 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI11179; Mon, 1 Dec 2003 10:38:57 -0500 (EST) Message-ID: <3FCB6090.2060004@cisco.com> Date: Mon, 01 Dec 2003 10:38:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren CC: sip@ietf.org Subject: Re: [Sip] remote terget update References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tolga Asveren wrote: > (due to no response in sip-implementors list switching to sip list) > > If a reINVITE with target refresh rejected, should remote target > reverted back to its original value before that reINVITE is received? Yes, 3261 seems pretty clear on this. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:57:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08227 for ; Tue, 30 Mar 2004 18:57:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riv-0006Yx-Oc for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKKrKt029675 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 15:20:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1T8-0007ZI-W9; Wed, 12 Nov 2003 15:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1SY-0007T9-2B for sip@optimus.ietf.org; Wed, 12 Nov 2003 15:19:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06993 for ; Wed, 12 Nov 2003 15:19:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1SW-0005HB-00 for sip@ietf.org; Wed, 12 Nov 2003 15:19:24 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AK1SV-0005Gi-00 for sip@ietf.org; Wed, 12 Nov 2003 15:19:23 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hACKIhY11459; Wed, 12 Nov 2003 14:18:44 -0600 (CST) Received: from lucent.com (vkg.lra.lucent.com [192.11.173.158] (may be forged)) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hACKIcB26170; Wed, 12 Nov 2003 14:18:39 -0600 (CST) Message-ID: <3FB2959B.3030905@lucent.com> Date: Wed, 12 Nov 2003 14:18:35 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'sip@ietf.org'" Subject: Re: [Sip] PUBLISH message rates References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Adam Roach wrote: > To get the conversation started on the list, I'll summarize > what I heard as salient points being made at the microphone. > > - Event packages define SHOULD or MUST strength requirements > that NOTIFYs cannot be sent faster than a hard limit. > Aki's proposal can be summarized as: PUBLISH will inherit > these hard limits as maximum rates of publication. > > - It was pointed out that recipients of PUBLISH requests can > push back against excessive traffic with 5xx class responses > that have "Retry-After" headers. > > - A point was made that NOTIFY will often be subject to filtering, > in which case there is no one-to-one correlation between the > amount of information sent to an event server in PUBLISH and > the amount of information sent by an event server in NOTIFYs. One more that I was about to point out but I believe Henning also bought it out in his turn at the mic. Given that we may have many publishers contributing PUBLISH requests to the composer, does the rate limiting apply to a single device, or does it apply to all PUBLISH requests coming from the myriad devices? I think it is hard to pin a number down, if not for anything else than for the fact that the presence status of a resource is an aggregate of many devices and each device has no idea on how many others are participating. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:58:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08535 for ; Tue, 30 Mar 2004 18:58:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riu-0006Yx-6E for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACK58dM019001 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 15:05:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Ec-0004vd-Vl; Wed, 12 Nov 2003 15:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Db-0004gr-W9 for sip@optimus.ietf.org; Wed, 12 Nov 2003 15:04:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04778 for ; Wed, 12 Nov 2003 15:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1DY-0004tO-00 for sip@ietf.org; Wed, 12 Nov 2003 15:03:56 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AK1DY-0004rx-00 for sip@ietf.org; Wed, 12 Nov 2003 15:03:56 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hACK1JGd021726; Wed, 12 Nov 2003 14:01:21 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 14:01:19 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865FE@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Alan Johnston'" , seancolson@yahoo.com, "'Cullen Jennings'" , sip@ietf.org, Jonathan Rosenberg Cc: "'Paul Kyzivat'" , oritl@microsoft.com Subject: RE: [Sip] GRUU, Contacts, and privacy Date: Wed, 12 Nov 2003 14:01:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Alan Johnston [mailto:alan.johnston@mci.com] writes: > I agree 100%. A private Contact URI is just one small piece > of the privacy puzzle. I think this privacy requirement should > be removed. I further agree. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:58:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08553 for ; Tue, 30 Mar 2004 18:58:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riv-0006Yx-K4 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFQN9j021839 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:26:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jcj-0005b5-U3; Sat, 20 Sep 2003 11:26:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0igJ-0006f7-1F for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:25:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21916 for ; Fri, 19 Sep 2003 17:05:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SS7-0001Wg-00 for sip@ietf.org; Fri, 19 Sep 2003 17:06:07 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1A0SRx-0001WW-00 for sip@ietf.org; Fri, 19 Sep 2003 17:05:57 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JL4Sj09253; Fri, 19 Sep 2003 16:04:28 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 14:04:29 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B04B985@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Stastny Richard'" , "'Rosen, Brian'" , "'Rohan Mahy'" Cc: "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 14:04:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EF1.9CF7B666" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37EF1.9CF7B666 Content-Type: text/plain > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, September 19, 2003 13:55 > To: Audet, Francois [SC100:4K02:EXCH]; Rosen, Brian; Rohan Mahy > Cc: Paul Kyzivat; Bob Penfield; sip@ietf.org > Subject: AW: [Sip] SIPIT Interop problem with ;user=phone > > > Thats what I meant in my original example: > If you have a dumb phone, its sends everything to > sip:nnnn@default.proxy.com - which is a dialing string Then you need one proxy per dialing plan (munich.proxy.com, wien.proxy.com, us-west.proxy.com, cdn.proxy.com, beijing.proxy.com, etc.). The advantage of the phone-context is that you can support multiple dialing plans (like all multinational corporations do today), but you can do it without deploying multiple proxies if you don't need to. And the phone doesn't need to understand this. To make it even more obvious, one user could have extension 3756 in California, and another one the same in Chicago. sip:3756;phone-context=santaclara.proxy.com@proxy.com;user=phone is different from sip:3756;phone-context=chicago.proxy.com@proxy.com;user=phone. But there is only one proxy (proxy.com). With your mechanism, you'd need one proxy for chicago.proxy.com and another for santaclara.proxy.com. > If you have a smart UA, it translates the dialstring to > either a tel:nnn;phone-context=company.com > or a tel:+nnnn - which is a E164 number > BTW: this is preferred anyway. Correct. > If you have a very clever UA, e.g. a SNOM, > it translates the dialstring into an E.164 number, > queries ENUM, returns a sip:user@host and > we do not have any problem at all ;-) > > Richard > PS: note that ;user=phone is not needed anywhere ------_=_NextPart_001_01C37EF1.9CF7B666 Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> Sent: Friday, September 19, 2003 13:55
> To: Audet, Francois [SC100:4K02:EXCH]; Rosen, Brian; Rohan Mahy
> Cc: Paul Kyzivat; Bob Penfield; sip@ietf.org
> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
>
>
> Thats what I meant in my original example:
> If you have a dumb phone, its sends everything to
> sip:nnnn@default.proxy.com - which is a dialing string

Then you need one proxy per dialing plan (munich.proxy.com,
wien.proxy.com, us-west.proxy.com, cdn.proxy.com, beijing.proxy.com,
etc.). The advantage of the phone-context is that you can support
multiple dialing plans (like all multinational corporations do today),
but you can do it without deploying multiple proxies if you don't need
to. And the phone doesn't need to understand this.

To make it even more obvious, one user could have extension
3756 in California, and another one the same in Chicago.

sip:3756;phone-context=santaclara.proxy.com@proxy.com;user=phone is
different from sip:3756;phone-context=chicago.proxy.com@proxy.com;user=phone.

But there is only one proxy (proxy.com). With your mechanism, you'd need
one proxy for chicago.proxy.com and another for santaclara.proxy.com.

> If you have a smart UA, it translates the dialstring to
> either a tel:nnn;phone-context=company.com
> or a tel:+nnnn - which is a E164 number
> BTW: this is preferred anyway.

Correct.

> If you have a very clever UA, e.g. a SNOM,
> it translates the dialstring into an E.164 number,
> queries ENUM, returns a sip:user@host and
> we do not have any problem at all ;-)
> 
> Richard
> PS: note that ;user=phone is not needed anywhere

------_=_NextPart_001_01C37EF1.9CF7B666-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:58:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08557 for ; Tue, 30 Mar 2004 18:58:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rit-0006YH-Dx for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O9tTNc031771 for sip-archive@odin.ietf.org; Fri, 24 Oct 2003 05:55:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyet-00082b-FW; Fri, 24 Oct 2003 05:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyeN-0007ut-8w for sip@optimus.ietf.org; Fri, 24 Oct 2003 05:54:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23085 for ; Fri, 24 Oct 2003 05:54:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACyeJ-0000cf-00 for sip@ietf.org; Fri, 24 Oct 2003 05:54:27 -0400 Received: from [193.122.18.249] (helo=emily.fle.fujitsu.com) by ietf-mx with smtp (Exim 4.12) id 1ACyeJ-0000cc-00 for sip@ietf.org; Fri, 24 Oct 2003 05:54:27 -0400 Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Fri, 24 Oct 2003 10:51:18 +0100 Received: by fle2.fle.fujitsu.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Oct 2003 10:52:55 +0100 Message-ID: From: Xin Chen To: "'Dean Willis'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Question on rfc3310 Hypertext Transfer Protocol (HTTP) Digest Aut hentication Using Authentication and Key Agreement (AKA) Date: Fri, 24 Oct 2003 10:52:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6291513c-a60b-43dd-9e22-24ea934b0318" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-6291513c-a60b-43dd-9e22-24ea934b0318 Content-Type: text/plain Hi Dean, Thanks for your answer. Exactly, that the questions are from my study in 3GPP specifications. I think there is a problem in 3GPP to support multiple contact addresses in a single REGISTER. Since more likely, each contact address will be another terminal, however, only the terminal which initiates the REGISTER could be authenticated successfully and have a security association established after the registration. However, terminals representing other contact addresses do not have that SA, so if forking happens, messages to the other terminals will be unprotected or even dropped off in the network. You suggest to address this question in sip implementer, thanks. However, I am not sure this is purely an implementation issue or not. We would like to see some general guidelines on solving this problem perhaps. Hope see you again sometime in 3GPP again:-) Regards Xin Chen Mobile Network Division Fujitsu Laboratories Europe Tel: +44(0)2086064453 Mobile: +44(0)7775741020 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: 23 October 2003 20:29 To: Xin Chen Cc: 'sip@ietf.org' Subject: Re: [Sip] Question on rfc3310 Hypertext Transfer Protocol (HTTP) Digest Aut hentication Using Authentication and Key Agreement (AKA) On Thu, 2003-10-23 at 05:38, Xin Chen wrote: > Hi, > > My question is that if REGISTER procedure is used to authenticate the > user agent, then it can only authenticate the device which initiate > the REGISTER. > > > What happen if the REGISTER contains multiple contact addresses which > possibly represent multiple devices, does that mean all the other > devices are authenticated also? > > If forking happens, how to provide confidentially and integration to > the SIP messages towards the other contact addresses? > > I am not sure whether these questions are within the scope of the RFC > or not, but your comment and thoughts are appreciated. > 1) This type of question is probably better-addressed to the SIP Implementors list. Perhaps we should even include it in the FAQ? 2) In the typical case, authentication of a REGISTER request simply establishes that the request in question came from a user agent with credentials to authenticate against the address-of-record in question. It does NOT establish anything about future requests coming from that user agent, or about contacts registered by that request. Authentication of a REGISTER request does NOTHING to provide confidentiality or message protection of traffic back toward the registering UA, nor to any other UA for which a "Contact" exists. That's why we have "sips" and TLS. And the ability to authenticate EVERY request, not just REGISTER. 3GPP has done something "special" here -- during the registration transaction, they establish keying for a transport-level integrity-protected (and optionally encrypted) tunnel between the UA and its edge proxy. This tunnel then protects future messages between the two, and since the edge proxy is trusted (and every other proxy, for that matter), allows for transitive trust all the way through the system. This isn't a general case solution, but they feel it works in a telecom operator environment. This is why there are all sorts of applicability statement and scope warnings in the RFCs defining 3GPP P-headers -- if used in the outside world, the sensistive information therein would be likely to be compromised. -- Dean ------=_NextPartTM-000-6291513c-a60b-43dd-9e22-24ea934b0318 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE). ------=_NextPartTM-000-6291513c-a60b-43dd-9e22-24ea934b0318-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:59:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08661 for ; Tue, 30 Mar 2004 18:59:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rit-0006Yx-Ot for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LPKiE023378 for sip-archive@odin.ietf.org; Wed, 5 Nov 2003 16:25:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8S-0005T1-J7; Wed, 05 Nov 2003 16:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHUi2-0003wI-QZ for sip@optimus.ietf.org; Wed, 05 Nov 2003 15:56:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23398 for ; Wed, 5 Nov 2003 15:56:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHUi1-0003Aa-00 for sip@ietf.org; Wed, 05 Nov 2003 15:56:57 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AHUi0-0003AT-00 for sip@ietf.org; Wed, 05 Nov 2003 15:56:56 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hA5Ku29c020553; Wed, 5 Nov 2003 15:56:02 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 14:56:01 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865C0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , Jonathan Rosenberg Cc: Paul Kyzivat , sip@ietf.org, rohan@cisco.com Subject: RE: [Sip] GRUU Mechanism I-D Date: Wed, 5 Nov 2003 14:56:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > I do think it would be very good medicine for the protocol to > deprecate all dialog reuse. Hear, hear! > My personal preference for modifying REFER is to deprecate the > implicit subscription behavior altogether (by strengthening the > mechanisms proposed in Sean's and Rohan's drafts perhaps). I agree with this course of action, for the reasons you cite, and others. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:59:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08698 for ; Tue, 30 Mar 2004 18:59:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006Yx-PF for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFQVaP022189 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:26:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jcz-0005ks-Qe; Sat, 20 Sep 2003 11:26:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ieC-0006f7-Nc for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23183 for ; Fri, 19 Sep 2003 18:00:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0TIz-00023l-00 for sip@ietf.org; Fri, 19 Sep 2003 18:00:45 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1A0TIo-00023E-00 for sip@ietf.org; Fri, 19 Sep 2003 18:00:35 -0400 Subject: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Sat, 20 Sep 2003 00:04:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <06CF906FE3998C4E944213062009F162233858@oefeg-s02.oefeg.loc> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN+8lA2rLZ71dqiQj6O29vO5zBuQgABsxRP From: "Stastny Richard" To: "Francois Audet" , "Rosen, Brian" , "Rohan Mahy" Cc: "Paul Kyzivat" , "Bob Penfield" , Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SSB1bmRlcnN0YW5kIHlvdXIgZXhhbXBsZSwgYnV0IEkgdGhvdWdodCB3ZSBhcmUgdGFsa2luZw0K YWJvdXQgZHVuYiBVQSB3aXRob3V0IGhhdmluZyBkaWFsaW5nIHBsYW5zIGJ1aWx0IGluLg0KIA0K SG93IGRvIHlvdSB0ZWxsIHlvdXIgcGhvbmUgdG8gc2VuZCBhcHBlbmQgaW4gb25lIGNhc2UNCnNh bnRhY2xhcmEucHJveHkuY29tIGFuZCBpbiB0aGUgb3RoZXIgY2FzZQ0KY2hpY2Fnby5wcm94eS5j b20gaWYgeW91IGp1c3QgZGlhbCAzNzU2Pw0KIA0KRWl0aGVyIHlvdSB1c2UgYW4gYWNjZXNzIGNv ZGUsIGJ1dCB0aGVuIHlvdSBoYXZlDQphIGRpYWxpbmcgcGxhbiBidWlsdCBpbiwgb3IgeW91IHNl bnQgaXQgd2l0aCB0aGUNCmFjY2VzcyBjb2RlIHRvIHRoZSBkZWZhdWx0IHByb3h5IGFuZCBsZXQg aXQgZG9pbmcgdGhlIHdvcmssDQogDQpvciB5b3UgdXNlIHNlcGFyYXRlIGxpbmVzIGFuZCBzd2lj aCBiZXR3ZWVuIHRoZW0uDQogDQpSaWNoYXJkDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hy aWNodC0tLS0tIA0KCVZvbjogRnJhbmNvaXMgQXVkZXQgW21haWx0bzphdWRldEBub3J0ZWxuZXR3 b3Jrcy5jb21dIA0KCUdlc2VuZGV0OiBGciAxOS4wOS4yMDAzIDIzOjA0IA0KCUFuOiBTdGFzdG55 IFJpY2hhcmQ7ICdSb3NlbiwgQnJpYW4nOyAnUm9oYW4gTWFoeScgDQoJQ2M6ICdQYXVsIEt5eml2 YXQnOyAnQm9iIFBlbmZpZWxkJzsgJ3NpcEBpZXRmLm9yZycgDQoJQmV0cmVmZjogUkU6IFtTaXBd IFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJDQoJDQoNCg0KDQoJPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCgk+IEZyb206IFN0YXN0bnkgUmljaGFyZCBbbWFp bHRvOlJpY2hhcmQuU3Rhc3RueUBvZWZlZy5hdF0gDQoJPiBTZW50OiBGcmlkYXksIFNlcHRlbWJl ciAxOSwgMjAwMyAxMzo1NSANCgk+IFRvOiBBdWRldCwgRnJhbmNvaXMgW1NDMTAwOjRLMDI6RVhD SF07IFJvc2VuLCBCcmlhbjsgUm9oYW4gTWFoeSANCgk+IENjOiBQYXVsIEt5eml2YXQ7IEJvYiBQ ZW5maWVsZDsgc2lwQGlldGYub3JnIA0KCT4gU3ViamVjdDogQVc6IFtTaXBdIFNJUElUIEludGVy b3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lIA0KCT4gDQoJPiANCgk+IFRoYXRzIHdoYXQgSSBt ZWFudCBpbiBteSBvcmlnaW5hbCBleGFtcGxlOiANCgk+IElmIHlvdSBoYXZlIGEgZHVtYiBwaG9u ZSwgaXRzIHNlbmRzIGV2ZXJ5dGhpbmcgdG8gDQoJPiBzaXA6bm5ubkBkZWZhdWx0LnByb3h5LmNv bSAtIHdoaWNoIGlzIGEgZGlhbGluZyBzdHJpbmcgDQoNCglUaGVuIHlvdSBuZWVkIG9uZSBwcm94 eSBwZXIgZGlhbGluZyBwbGFuIChtdW5pY2gucHJveHkuY29tLCANCgl3aWVuLnByb3h5LmNvbSwg dXMtd2VzdC5wcm94eS5jb20sIGNkbi5wcm94eS5jb20sIGJlaWppbmcucHJveHkuY29tLCANCgll dGMuKS4gVGhlIGFkdmFudGFnZSBvZiB0aGUgcGhvbmUtY29udGV4dCBpcyB0aGF0IHlvdSBjYW4g c3VwcG9ydCANCgltdWx0aXBsZSBkaWFsaW5nIHBsYW5zIChsaWtlIGFsbCBtdWx0aW5hdGlvbmFs IGNvcnBvcmF0aW9ucyBkbyB0b2RheSksIA0KCWJ1dCB5b3UgY2FuIGRvIGl0IHdpdGhvdXQgZGVw bG95aW5nIG11bHRpcGxlIHByb3hpZXMgaWYgeW91IGRvbid0IG5lZWQgDQoJdG8uIEFuZCB0aGUg cGhvbmUgZG9lc24ndCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhpcy4gDQoNCglUbyBtYWtlIGl0IGV2 ZW4gbW9yZSBvYnZpb3VzLCBvbmUgdXNlciBjb3VsZCBoYXZlIGV4dGVuc2lvbiANCgkzNzU2IGlu IENhbGlmb3JuaWEsIGFuZCBhbm90aGVyIG9uZSB0aGUgc2FtZSBpbiBDaGljYWdvLiANCg0KCXNp cDozNzU2O3Bob25lLWNvbnRleHQ9c2FudGFjbGFyYS5wcm94eS5jb21AcHJveHkuY29tO3VzZXI9 cGhvbmUgaXMgDQoJZGlmZmVyZW50IGZyb20gc2lwOjM3NTY7cGhvbmUtY29udGV4dD1jaGljYWdv LnByb3h5LmNvbUBwcm94eS5jb207dXNlcj1waG9uZS4gDQoNCglCdXQgdGhlcmUgaXMgb25seSBv bmUgcHJveHkgKHByb3h5LmNvbSkuIFdpdGggeW91ciBtZWNoYW5pc20sIHlvdSdkIG5lZWQgDQoJ b25lIHByb3h5IGZvciBjaGljYWdvLnByb3h5LmNvbSBhbmQgYW5vdGhlciBmb3Igc2FudGFjbGFy YS5wcm94eS5jb20uIA0KDQoJPiBJZiB5b3UgaGF2ZSBhIHNtYXJ0IFVBLCBpdCB0cmFuc2xhdGVz IHRoZSBkaWFsc3RyaW5nIHRvIA0KCT4gZWl0aGVyIGEgdGVsOm5ubjtwaG9uZS1jb250ZXh0PWNv bXBhbnkuY29tIA0KCT4gb3IgYSB0ZWw6K25ubm4gLSB3aGljaCBpcyBhIEUxNjQgbnVtYmVyIA0K CT4gQlRXOiB0aGlzIGlzIHByZWZlcnJlZCBhbnl3YXkuIA0KDQoJQ29ycmVjdC4gDQoNCgk+IElm IHlvdSBoYXZlIGEgdmVyeSBjbGV2ZXIgVUEsIGUuZy4gYSBTTk9NLCANCgk+IGl0IHRyYW5zbGF0 ZXMgdGhlIGRpYWxzdHJpbmcgaW50byBhbiBFLjE2NCBudW1iZXIsIA0KCT4gcXVlcmllcyBFTlVN LCByZXR1cm5zIGEgc2lwOnVzZXJAaG9zdCBhbmQgDQoJPiB3ZSBkbyBub3QgaGF2ZSBhbnkgcHJv YmxlbSBhdCBhbGwgOy0pIA0KCT4gIA0KCT4gUmljaGFyZCANCgk+IFBTOiBub3RlIHRoYXQgO3Vz ZXI9cGhvbmUgaXMgbm90IG5lZWRlZCBhbnl3aGVyZSANCg0K _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:59:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08768 for ; Tue, 30 Mar 2004 18:59:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006YH-F4 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LPKLE023380 for sip-archive@odin.ietf.org; Wed, 5 Nov 2003 16:25:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8Y-0005Xh-Tg; Wed, 05 Nov 2003 16:24:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHUoE-0004AY-7e for sip@optimus.ietf.org; Wed, 05 Nov 2003 16:03:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23667 for ; Wed, 5 Nov 2003 16:03:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHUoC-0003Il-00 for sip@ietf.org; Wed, 05 Nov 2003 16:03:20 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1AHUoC-0003Ii-00 for sip@ietf.org; Wed, 05 Nov 2003 16:03:20 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.10/8.12.9) with SMTP id hA5L3K86044356 for ; Wed, 5 Nov 2003 16:03:20 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] GRUU Mechanism I-D Date: Wed, 5 Nov 2003 16:04:16 -0500 Message-ID: <001701c3a3e0$5fe8cd00$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3FA93AAE.3070804@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I would be happy if dialog reuse had never been > there. But at this point I think it is impossible > to avoid supporting it. And once the effort has > been made to support it, deprecating it in favor > of a new approach is just that much more work, > with more backwards compatibility alternatives > to consider, etc. At this point I would prefer > to live with the mistake. I agree. Dialog reuse does have some under specification problems. However I prefer to resolve the issues instead of just dropping it until GRUU gets approved, implemented, and deployed. Most of the current dialog reuse issues could be resolved by a new header which indicates a real call-id and a parameter which indicates that this is a request to establish a new call/subscription/... on this dialog. A new response is also needed to indicate that I am aware of this dialog however I am not aware of the call/subscription/... associated with the request (a 481 which doesn't release the dialog). To avoid some complexities, potentially we could also restrict the number of calls sharing a dialog to be 1 at any given time. Or potentially we could add a statement that a call cannot be originated on an already established dialog. > > I do think it would be very good medicine > > for the protocol to deprecate all dialog reuse. Fully deprecating it would mean that rfc3265 would have to be updated to remove dialog sharing among subscriptions so that GRUU would have to be used instead. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:59:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08840 for ; Tue, 30 Mar 2004 18:59:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006Yx-IR for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALE8AlJ003641 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 09:08:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBw5-0000PZ-Jk; Fri, 21 Nov 2003 09:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBvG-0000OK-Mh for sip@optimus.ietf.org; Fri, 21 Nov 2003 09:06:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13898 for ; Fri, 21 Nov 2003 09:05:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBvF-0002bH-00 for sip@ietf.org; Fri, 21 Nov 2003 09:06:09 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ANBvE-0002ai-00 for sip@ietf.org; Fri, 21 Nov 2003 09:06:08 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALE4bG13876 for ; Fri, 21 Nov 2003 08:05:02 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XJKGG>; Fri, 21 Nov 2003 14:04:36 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF1D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Pugaczewski, Jack'" , sip@ietf.org Subject: RE: [Sip] 3-way handshake bad! Date: Fri, 21 Nov 2003 14:04:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Neither of these are ISUP examples, they are DSS1. Morever, for setup in both protocols (ISUP and DSS1), the three message sequence is not a handshake (A --> B, B --> A, A --> B) and is not necessrily end to end, in most countries the ACM or CALL PROCEEDING is more likely returned link by link. For teardown, the handshake is always link by link, and in DSS1, it is not a handshake. It only has functionality in one direction (although is specified in both directions to keep it symmetrical), and it is there because of the point - multipoint interface that is allowed in DSS1. regards Keith > -----Original Message----- > From: Pugaczewski, Jack [mailto:Jack.Pugaczewski@qwest.com] > Sent: 17 November 2003 15:16 > To: Paul D.Smith; sip@ietf.org > Subject: RE: [Sip] 3-way handshake bad! > > > Question: > > Why is a 3-way handshake bad ? ISUP has used it successully for call > setup and call teardown: > > Call Setup: Setup -->; Call Proceeding <--; Connect <--- > Call Teardown: Disconnect -->; Release <--; Release Complete --> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 18:59:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08876 for ; Tue, 30 Mar 2004 18:59:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006Yx-ES for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69mqM0010307 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 04:48:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgid-0002Lm-P7; Thu, 06 Nov 2003 04:46:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHghY-0001yH-IL for sip@optimus.ietf.org; Thu, 06 Nov 2003 04:45:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01325 for ; Thu, 6 Nov 2003 04:45:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHghV-0005rC-00 for sip@ietf.org; Thu, 06 Nov 2003 04:45:13 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AHghU-0005qQ-00 for sip@ietf.org; Thu, 06 Nov 2003 04:45:12 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 29265; Thu, 06 Nov 2003 04:51:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Nov 2003 04:44:11 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F691D@zoe.office.snowshore.com> Thread-Topic: Comments on history-info Thread-Index: AcOkHCU2DO0NzkNoS+eV1xWKG0wHHA== From: "Eric Burger" To: "SIP List (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Comments on history-info Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Big question: Why don't we use multiple History-Info headers, instead of a = (potentially VERY long) single header? I would argue for multiple headers on two grounds. First, the idea of a proxy modifying history information doesn't sound = smart. If it screws up, it is hard to figure out who screwed up. Second, the index parameter frees us from worrying about header order, = which is a VERY good thing. Overview: While the motivation for History-Info is for the initiator of a request = to know what happened to a request, it is also of great use to the = recipient (End of Section 2 overview paragraph). Section 1.2: How is History-Info any different than Via w.r.t. security? Nits: Section 2.5, first paragraph, last sentence: this would like be a local this would likely be a local ^^ Appendix B, message F8, extra space before last angle-bracket in the = History-Info line. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:00:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09131 for ; Tue, 30 Mar 2004 19:00:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006Yx-P9 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOGr4UB030318 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 11:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJxO-0007rk-9v; Mon, 24 Nov 2003 11:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJwU-0007b5-1J for sip@optimus.ietf.org; Mon, 24 Nov 2003 11:52:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15624 for ; Mon, 24 Nov 2003 11:51:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJwS-0000Dv-00 for sip@ietf.org; Mon, 24 Nov 2003 11:52:04 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1AOJwS-0000Co-00 for sip@ietf.org; Mon, 24 Nov 2003 11:52:04 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Mon, 24 Nov 2003 16:51:21 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FCC6@baker.datcon.co.uk> From: "Paul D.Smith" To: "'Pugaczewski, Jack'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] 3-way handshake bad! Date: Mon, 24 Nov 2003 16:51:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Jack, As you say, a 3-way handshake per-se is not bad. In the SIP case though, I believe it can have poor characteristics during network/server congestion. Since it seemed that it had been proposed as a possible solution to certain SIP problems and possibly become the new "handshake of choice", I wanted to alert readers to the downsides. The title was a little "shocking", but was very much intended to be read within the SIP context of the mailing list. Regards, Paul DS. -----Original Message----- From: Pugaczewski, Jack [mailto:Jack.Pugaczewski@qwest.com] Sent: 21 November 2003 08:20 To: SIP (E-mail) Subject: RE: [Sip] 3-way handshake bad! Question: Why is a 3-way handshake bad ? ISUP has used it successully for call setup and call teardown: Call Setup: Setup -->; Call Proceeding <--; Connect <--- Call Teardown: Disconnect -->; Release <--; Release Complete --> -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Paul D.Smith Sent: Monday, November 17, 2003 9:01 AM To: 'sip@ietf.org' Subject: [Sip] 3-way handshake bad! All, For context, see IETF 58 minutes. There was a suggestion that the non-INVITE avalanche problem be solved by using a 3-way handshake. I just want to flag that this idea can have unfortunate consequences during congestion. Firstly, consider a server under load. The 3-way handshake requires the following. server processes request - #1 server sends response - #2 server processes request/handshake - #3. By adding the 3rd step, we have _doubled_ the number of requests to be handled by the server increasing the load and increasing the chances it becomes congested. As per my earlier e-mail, for TCP, the chances of the initial request completing can be either 1.0 or 0.0 depending on the congestion. Increasing the congestion at the server, increases the chance of requests failing. For UDP, there is a 1/x (x >= 1) chance of the request being received and processed by the server. Similarly, there is a 1/x chance of the 3rd request/handshake reaching the server. This means the chances of the 3-way handshake completing are 1/(x^2). So adding the third step greatly affects the chances of the 3-way handshake completing. Paul D.Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:01:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09149 for ; Tue, 30 Mar 2004 19:01:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006YH-OO for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9835uVM028107 for sip-archive@odin.ietf.org; Tue, 7 Oct 2003 23:05:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74dM-00079N-42; Tue, 07 Oct 2003 23:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74d4-00078j-BX for sip@optimus.ietf.org; Tue, 07 Oct 2003 23:04:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02626 for ; Tue, 7 Oct 2003 23:04:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A74cz-00073C-00 for sip@ietf.org; Tue, 07 Oct 2003 23:04:41 -0400 Received: from web20105.mail.yahoo.com ([216.136.226.42]) by ietf-mx with smtp (Exim 4.12) id 1A74cy-000739-00 for sip@ietf.org; Tue, 07 Oct 2003 23:04:41 -0400 Message-ID: <20031008030439.48413.qmail@web20105.mail.yahoo.com> Received: from [210.22.174.110] by web20105.mail.yahoo.com via HTTP; Tue, 07 Oct 2003 20:04:39 PDT Date: Tue, 7 Oct 2003 20:04:39 -0700 (PDT) From: "xiao'tong liang" Subject: Re: [Sip] Register Method To: wudeqiang Cc: sip@vovida.org, sip@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 1. Yes, an address-of-record can be registered by many entities. So, these entities belong to one logical user.(Imagine one user have Mobile UA, PC soft UA, and a Cisco 7960 phone:-) 2. Because of all these bindings belong to same logic user(same address-of-record), UA can add/delete the records(belongs to same AOR) which is not created by itself(eg. Mobile can delete or modify PC's bindings). 3. "What cause the Call-ID different?": The UA MAY be rebooted, or MAY be one UA can register several Contacts(I have not seen such equipment yet:). -- Liang xiaotong --- wudeqiang wrote: > I have a question about Register request. > rfc3261 says "one entity may be responsible for > updating the registrations associated with multiple > addresses-of-record"(in 10.3 Processing REGISTER > Requests). > I want to know whether an address-of-record can be > registered by many entities.If this is true,why an > entity can update or delete a binding which is not > created by itself. > In 10.3 Processing REGISTER Request ,rules7 > "If the Call-ID value in the existing binding > differs from the Call-ID value in the request, the > binding MUST be removed if the expiration time is > zero and updated otherwise. " What cause the Call-ID > different? > Does this mean different entity can register a > address-of-record? > > thanx ! __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:01:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09209 for ; Tue, 30 Mar 2004 19:01:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006a4-Ni for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MMXD4Q032617 for sip-archive@odin.ietf.org; Mon, 22 Mar 2004 17:33:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Xxh-0008M3-Lq; Mon, 22 Mar 2004 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5XxG-0008L7-CO for sip@optimus.ietf.org; Mon, 22 Mar 2004 17:31:34 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29567 for ; Mon, 22 Mar 2004 17:31:30 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B5Xwl-0008KS-2r; Mon, 22 Mar 2004 17:31:03 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , sip mailing list , sip chair , sip chair Message-Id: Date: Mon, 22 Mar 2004 17:31:03 -0500 Subject: [Sip] Protocol Action: 'The Session Inititation Protocol (SIP) 'Replaces' Header' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has approved the following document: - 'The Session Inititation Protocol (SIP) 'Replaces' Header ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document defines a new header for use with SIP multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that definition of these example features is non-normative. Security considerations for this Header include strong recommendation of use of the Authenticated Identity Body and the Referred-by mechanism use of it in authorization approaches. Working Group Summary The working group supported advancement of this document because of strong support for the enabling of distributed call control feature development. Protocol Quality The document was reviewed for the IESG by Allison Mankin and mid-course security reviewing was provided by Eric Rescorla. RFC Editor Note Please substute for all occurences of billybiggs.com -> billybiggs.example.com Please replace the following sentence in Section 4: OLD: Likewise in a call center environment, each call center agent could possess credentials which supervisors also have access to. NEW: Likewise in a call center environment, supervisors could have access to     the credentials of each call center agent. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:01:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09241 for ; Tue, 30 Mar 2004 19:01:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006ZK-Ou for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOGr5Se030385 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 11:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJxP-0007sP-Ta; Mon, 24 Nov 2003 11:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJwx-0007mX-B3 for sip@optimus.ietf.org; Mon, 24 Nov 2003 11:52:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15661 for ; Mon, 24 Nov 2003 11:52:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJww-0000Ef-00 for sip@ietf.org; Mon, 24 Nov 2003 11:52:34 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1AOJwv-0000De-00 for sip@ietf.org; Mon, 24 Nov 2003 11:52:33 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Mon, 24 Nov 2003 16:51:52 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FCC7@baker.datcon.co.uk> From: "Paul D.Smith" To: "'David R. Oran'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] 3-way handshake bad! Date: Mon, 24 Nov 2003 16:51:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , David, I take your point about not wishing to start a long thread on something that may not happen. I just want to clarify a couple of my assertions below as I think you may have misunderstood my reasoning. Thanks, Paul DS. Paul D.Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: 17 November 2003 15:19 To: SIP (E-mail) Subject: Re: [Sip] 3-way handshake bad! --On Monday, November 17, 2003 3:01 PM +0000 "Paul D.Smith" wrote: > All, > > For context, see IETF 58 minutes. There was a suggestion that the > non-INVITE avalanche problem be solved by using a 3-way handshake. I just > want to flag that this idea can have unfortunate consequences during > congestion. > I made that suggestion. I disagree that it has unfortunate congestion consequences. See below. Note however, that it may be unproductive to start an extended dialog on this subject since such a change to SIP may be too radical at this stage in the protocol's evolution. We need to weigh this against the efficacy-versus-radicality tradeoffs of other possible ways to ameliorate the problems. [PDS] Agreed. > Firstly, consider a server under load. The 3-way handshake requires the > following. > > server processes request - #1 > server sends response - #2 > server processes request/handshake - #3. > > By adding the 3rd step, we have _doubled_ the number of requests to be > handled by the server increasing the load and increasing the chances it > becomes congested. > Not really. The processing of an ACK transaction is not nearly as expensive as processing of the actual request. All it requires is transaction matching and state cleanup (if any). This had better be blindingly fast in any reasonable SIP server or you have a lot of worse things to worry about, including DoS attacks from legitimate authenticated/authorized sources. (Aside: I actually have a patent disclosure filed on how to do DoS prevention by SIP servers where the relative costs of transaction matching, authentication, authorization, and state-creation are taken into account). [PDS] My contention is not that ACK processing is as slow as INVITE. It is that no request, ACK or otherwise, can be processed by the SIP stack until it has been accepted by the IP layer. During congestion, and when using UDP, it is the rate at which ALL requests/responses can be processed by the SIP/IP stacks that determines the chance of an ACK (or any other SIP request or response) being accepted and processed. I therefore contend that the time taken by the SIP stack to process the ACK, which having an overall affect on the chances of any SIP request being accepted, has no bearing on the chances of the ACK even being accepted. [PDS] The only possible exception to this might be if an ACK were sufficiently smaller than any other request/response such that it might be able to be accepted when there were insufficient resources for larger datagrams to be received. I suspect that in most stacks, the relative sizes of the datagrams has little bearing. > As per my earlier e-mail, for TCP, the chances of the initial request > completing can be either 1.0 or 0.0 depending on the congestion. For a single signaling hop this is more-or-less true, but assumes a number of things, including whether the server is programmed to back-pressure the TCP connection (causing HOL blocking) or is maintaining internal request queues from which requests might get dropped on overflow. For multi-hop signaling, TCP is of little help especially when multiplexing is happening. > Increasing the congestion at the server, increases the chance of requests > failing. For UDP, there is a 1/x (x >= 1) chance of the request being > received and processed by the server. Similarly, there is a 1/x chance > of the 3rd request/handshake reaching the server. This is true only if all requests have equal costs, and if ACKs have equal costs to requests. This is demonstrably not the case. > This means the chances > of the 3-way handshake completing are > 1/(x^2). So adding the third step greatly affects the chances of the > 3-way handshake completing. > I believe this logic is flawed. Cheers, Dave. > Paul D.Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:02:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09552 for ; Tue, 30 Mar 2004 19:02:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006YH-B0 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFd4aL008282 for sip-archive@odin.ietf.org; Tue, 17 Feb 2004 10:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Id-0001mq-0s; Tue, 17 Feb 2004 10:38:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7I4-0001TE-TK for sip@optimus.ietf.org; Tue, 17 Feb 2004 10:37:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05957; Tue, 17 Feb 2004 10:37:36 -0500 (EST) Message-Id: <200402171537.KAA05957@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 17 Feb 2004 10:37:36 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-02.txt Pages : 32 Date : 2004-2-17 This document defines two new SIP header fields for communications resource priority, namely 'Resource-Priority' and 'Accept-Resource- Priority'. The Resource-Priority header field can influence the behavior of SIP UAs, such as GSTN gateways, and SIP proxies. It does not directly influence the forwarding behavior of IP routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-resource-priority-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17104605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17104605.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:03:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09640 for ; Tue, 30 Mar 2004 19:03:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006YH-7w for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALL6ASB014789 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 16:06:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANITa-0003nF-Gd; Fri, 21 Nov 2003 16:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANISe-0003Kn-Fa for sip@optimus.ietf.org; Fri, 21 Nov 2003 16:05:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02564; Fri, 21 Nov 2003 16:04:51 -0500 (EST) Message-Id: <200311212104.QAA02564@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 21 Nov 2003 16:04:50 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc3312-update-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : Interactions of Preconditions with Session Mobility in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-sip-rfc3312-update-00.txt Pages : 8 Date : 2003-11-21 This document describes how to use SIP preconditions in situations that involve session mobility. This document updates RFC3312, which defines the framework for SIP preconditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc3312-update-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-rfc3312-update-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rfc3312-update-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-21162331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc3312-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc3312-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-21162331.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:03:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09645 for ; Tue, 30 Mar 2004 19:03:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006YH-5J for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EJac3B014370 for sip-archive@odin.ietf.org; Tue, 14 Oct 2003 15:36:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Uxf-0003Rk-92; Tue, 14 Oct 2003 15:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Uwp-0003KR-L6 for sip@optimus.ietf.org; Tue, 14 Oct 2003 15:35:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26183; Tue, 14 Oct 2003 15:35:02 -0400 (EDT) Message-Id: <200310141935.PAA26183@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 14 Oct 2003 15:35:02 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-congestsafe-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : Session Initiation Protocol Extension to Assure Congestion Safety Author(s) : D. Willis, B. Campbell Filename : draft-ietf-sip-congestsafe-02.txt Pages : 12 Date : 2003-10-14 The Session Initiation Protocol allows the use of UDP for transport of SIP messages. The use of UDP inherently risks network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. This problem is aggravated by large SIP messages which fragment at the UDP level. Transport protocols in SIP are also negotiated on a per-hop basis, at the SIP level, so SIP proxies may convert from TCP to UDP and so forth. This document defines by which a SIP User Agent may require that its requests are not sent over UDP or other transports having congestion-related characteristics similar to those of UDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-congestsafe-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-congestsafe-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-14133842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-congestsafe-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-congestsafe-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-14133842.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:03:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09708 for ; Tue, 30 Mar 2004 19:03:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006ZK-7P for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFNHkj029324 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:23:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTXW-0007Uy-BH; Wed, 18 Feb 2004 10:23:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTW4-0006sl-MH for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:21:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19663; Wed, 18 Feb 2004 10:21:22 -0500 (EST) Message-Id: <200402181521.KAA19663@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 10:21:22 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-ietf-sip-connect-reuse-01.txt Pages : 14 Date : 2004-2-18 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-connect-reuse-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-connect-reuse-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18103356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18103356.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:03:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09726 for ; Tue, 30 Mar 2004 19:03:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006a4-6W for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EJacq8014373 for sip-archive@odin.ietf.org; Tue, 14 Oct 2003 15:36:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Uxh-0003SE-6e; Tue, 14 Oct 2003 15:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Uww-0003KW-8I for sip@optimus.ietf.org; Tue, 14 Oct 2003 15:35:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26202; Tue, 14 Oct 2003 15:35:08 -0400 (EDT) Message-Id: <200310141935.PAA26202@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 14 Oct 2003 15:35:08 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-12.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : Session Timers in the Session Initiation Protocol (SIP) Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-12.txt Pages : 36 Date : 2003-10-14 This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new header fields, Session- Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-timer-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-timer-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-14133850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-14133850.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:03:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09756 for ; Tue, 30 Mar 2004 19:03:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006ZK-5J for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFNHNR029164 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:23:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTXT-0007TM-4y; Wed, 18 Feb 2004 10:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTVh-0006qA-7T for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:21:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19599; Wed, 18 Feb 2004 10:20:59 -0500 (EST) Message-Id: <200402181520.KAA19599@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 10:20:58 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : An Extension to the Session Initiation Protocol for Request History Information Author(s) : M. Barnes Filename : draft-ietf-sip-history-info-02.txt Pages : 32 Date : 2004-2-18 This draft defines a standard mechanism for capturing the history information associated with a 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 draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, HistInfo, to be included in the Supported header is defined to allow UAs to indicate whether the HistInfo should be returned in responses to a request which has captured the history information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-history-info-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-history-info-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18103343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-history-info-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-history-info-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18103343.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:03:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09762 for ; Tue, 30 Mar 2004 19:03:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006YH-2D for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFOEtT030656 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:24:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTXk-0007dx-6A; Wed, 18 Feb 2004 10:23:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTWt-00072r-6I for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:22:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19813; Wed, 18 Feb 2004 10:22:14 -0500 (EST) Message-Id: <200402181522.KAA19813@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 10:22:14 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-join-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : The Session Inititation Protocol (SIP) 'Join' Header Author(s) : R. Mahy, D. Petrie Filename : draft-ietf-sip-join-03.txt Pages : 20 Date : 2004-2-18 This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Barge-In', answering-machine-style 'Message Screening' and 'Call Center Monitoring'. Note that definition of these example features is non- normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-join-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-join-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-join-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18103426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-join-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-join-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18103426.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:04:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09792 for ; Tue, 30 Mar 2004 19:04:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006a4-4Y for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFOEQG030655 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:24:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTYR-0007sT-RH; Wed, 18 Feb 2004 10:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTWy-0007AC-GO for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:22:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19858; Wed, 18 Feb 2004 10:22:28 -0500 (EST) Message-Id: <200402181522.KAA19858@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 10:22:28 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-replaces-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : The Session Inititation Protocol (SIP) 'Replaces' Header Author(s) : B. Biggs, R. Dean, R. Mahy Filename : draft-ietf-sip-replaces-05.txt Pages : 18 Date : 2004-2-18 This document defines a new header for use with SIP multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Attended Transfer' and 'Call Pickup'. Note that definition of these example features is non-normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-replaces-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-replaces-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18103444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-replaces-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-replaces-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18103444.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09831 for ; Tue, 30 Mar 2004 19:04:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006Yx-2F for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9REKjLJ026779 for sip-archive@odin.ietf.org; Mon, 27 Oct 2003 09:20:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8Dy-0006Zl-L4; Mon, 27 Oct 2003 09:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8Cz-0006FF-Cx for sip@optimus.ietf.org; Mon, 27 Oct 2003 09:19:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14563; Mon, 27 Oct 2003 09:18:49 -0500 (EST) Message-Id: <200310271418.JAA14563@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 09:18:49 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-publish-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : Session Initiation Protocol (SIP) Extension for Event State Publication Author(s) : A. Niemi Filename : draft-ietf-sip-publish-01.txt Pages : 35 Date : 2003-10-24 This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. The first application of this extension is targeted at the publication of presence information. The mechanism described in this document can be extended to support publication of any event state, for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose (FTP, HTTP, etc.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-publish-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-publish-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24161029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-publish-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-publish-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24161029.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:04:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10049 for ; Tue, 30 Mar 2004 19:04:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006a4-1w for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFNH4u029349 for sip-archive@odin.ietf.org; Wed, 18 Feb 2004 10:23:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTXY-0007WI-1w; Wed, 18 Feb 2004 10:23:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTWe-0006zA-7W for sip@optimus.ietf.org; Wed, 18 Feb 2004 10:22:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19762; Wed, 18 Feb 2004 10:21:58 -0500 (EST) Message-Id: <200402181521.KAA19762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 10:21:57 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Working Group of the IETF. Title : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-01.txt Pages : 23 Date : 2004-2-18 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server, and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18103409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18103409.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05463 for ; Tue, 30 Mar 2004 18:47:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj2-0006a4-6z for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S021ej027338 for sip-archive@odin.ietf.org; Tue, 27 Jan 2004 19:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald7J-0006gi-A1; Tue, 27 Jan 2004 18:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al9xy-0002Rv-Aa for sip@optimus.ietf.org; Mon, 26 Jan 2004 11:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12750 for ; Mon, 26 Jan 2004 11:51:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al9xx-0000Lp-00 for sip@ietf.org; Mon, 26 Jan 2004 11:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al9x1-0000J7-00 for sip@ietf.org; Mon, 26 Jan 2004 11:51:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Al9wd-0000Gx-00 for sip@ietf.org; Mon, 26 Jan 2004 11:50:39 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2004 08:52:15 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0QGo6Ie016884; Mon, 26 Jan 2004 11:50:06 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFN43119; Mon, 26 Jan 2004 11:50:04 -0500 (EST) Message-ID: <4015453B.3070902@cisco.com> Date: Mon, 26 Jan 2004 11:50:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] querying the current event state of a publication References: <4012E741.5000809@dynamicsoft.com> <40152C68.8030802@cisco.com> <40154262.9010400@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > >>> If we want this functionality, I have an idea for an alternative >>> approach that works much better, triggered by some conversations I >>> had with Ben C. recently. >> >> That's a big IF. Do we really want to mandate that every compositor >> must be prepared to provide this? It certainly puts contraints on the >> implementations, and in most cases I think publishers can be >> constructed so that they don't need this capability. > > The main constraint I think it introduces is that the compositor needs > to keep around the presence documents from each individual source, in > addition to the final result of composition. I am not sure if this is > new; I don't know how it couuld do composition without keeping these > around. I think there may be plausible implementations that separate the compositor from the PA handling subscribes and generating notifies. In that case the compositor may have the individual presence document, but the PA doesn't. I'm just concerned about layering on additional behavior that everybody must implement. > My suggestion was mostly along the lines of - this is a good way to do > it, rather than, we should have this feature. I recall there was a 3gpp > requrement for it, and I remember asking why it was there, and I dont > remember the answer, in fact. I'm in agreement as long as the discussion about IF has yet to happen. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Mar 30 19:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05466 for ; Tue, 30 Mar 2004 18:47:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj2-0006a4-22 for sip-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239RCuT007240 for sip-archive@odin.ietf.org; Wed, 3 Mar 2004 04:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySdu-0001W6-S3; Wed, 03 Mar 2004 04:26:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySD2-0006ij-Pg for sip@optimus.ietf.org; Wed, 03 Mar 2004 03:58:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11800 for ; Wed, 3 Mar 2004 03:58:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySCg-000284-00 for sip@ietf.org; Wed, 03 Mar 2004 03:58:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySBh-0001r5-00 for sip@ietf.org; Wed, 03 Mar 2004 03:57:10 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AySAo-0001eo-00 for SIP@ietf.org; Wed, 03 Mar 2004 03:56:14 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i238uFYG003618 for ; Wed, 3 Mar 2004 09:56:15 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 09:56:15 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Mar 2004 09:56:55 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Drage, Keith (Keith)'" , "Elwell, John" , SIP@ietf.org Subject: RE: [Sip] Use of P-Asserted-Identity in a response Date: Wed, 3 Mar 2004 09:55:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Mar 2004 08:56:15.0039 (UTC) FILETIME=[625FD4F0:01C400FD] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, As far as I know usage of PAI has not been defined for responses in Q.1912.5. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Drage, > Keith (Keith) > Sent: 4. tammikuuta 2004 2:58 > To: Elwell, John; SIP@ietf.org > Subject: RE: [Sip] Use of P-Asserted-Identity in a response > > > RFC 3325 section 9.1 and section 9.2 both extend table 2 of > RFC 3261 with the new header. > > Both entires leave the "where" column empty. > > The key to RFC 3261 table 2 states: > > An empty entry in the "where" column indicates that the header > field may be present in all requests and responses. > > I would therefore conclude from the existing specification > that both headers may appear in any response to BYE, INV, > OPT, SUB, NOT, REF, i.e. those methods that either create a > dialog, or are used outside a dialog. > > As MESSAGE appeared after RFC 3325 I would also assume that > it is allowed in the MESSAGE method, in both requests and all > responses. > > Note that these tables do not restrict it to 18x and 2xx > responses, although for ISDN mapping purposes those responses > are the useful ones. It is perfectly valid in 3xx, 4xx and > 5xx responses. > > Any assertion of identity in responses (and its value) is of > course dependent on the specification of privacy by the UAS > and on the requirements of the first proxy in the trust domain. > > This usage corresponds to what has been specified in 3GPP TS > 24.229 and I believe in ITU-T Q.1912.5. > > regards > > Keith > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 02 January 2004 16:11 > > To: SIP@ietf.org > > Subject: [Sip] Use of P-Asserted-Identity in a response > > > > > > There seem to be some differences of opinion concerning the use of > > P-Asserted-Identity (PAI) in a response. In particular, this > > is delaying the > > progress of draft-ietf-sipping-qsig2sip, which makes use of > > PAI in a 200 OK > > to convey the connected party identity received from the QSIG > > network. The > > same situation is likely to be encountered when interworking > > with other > > legacy signalling systems. > > > > It is my opinion that PAI can be used in a 200 OK to assert > > the identity of > > the connect party. Moreover, it can be inserted by a gateway > > UAS and, unless > > subject to privacy, can be passed on even to untrusted > > entities including > > the UAC. > > > > My evidence for assuming this is as follows: > > > > 1. RFC 3325: In section 5, 2nd paragraph it states: > > "If the proxy receives a message (request or response) from a > > node that it > > trusts, it can use the information in the P-Asserted-Identity > > header field, > > if any, as if it had authenticated the user itself." > > There is nowhere that forbids the use of P-Asserted-ID in a > response, > > although there are places in the RFC that mention procedures > > for a request > > without mentioning a response. In many places it talks about > > "message", > > which, according to the text above, means request or response. > > > > 2. RFC 3324 clause 5 clearly states that PAI in INVITE > identifies the > > calling user, PAI in a 180 response the ringing user and PAI > > in 200 OK the > > user who answered the call. RFC 3325 is supposed to meet the > > requirement of > > RFC3324. > > > > I have seen a number of arguments against the use of PAI in a > > response: > > > > a) It has been suggested that a PAI in a response represents > > the identity of > > the entity that issued the request. This does not hold water. > > It clearly > > would be in contradiction to clause 5 of RFC3324 and there is > > nowhere in > > RFC3324 or RFC3325 that suggests echoing in a response the > PAI in the > > request. > > > > b)It has been suggested that there would need to be > > corresponding privacy > > requirements for identity information in a response. However, > > RFC 3323 does > > indeed address privacy in responses. See last paragraph of > section 3: > > "It may be desirable to restrict identity information on both > > requests and > > responses. Initially, it might seem unusual to suggest that > > a response has > > privacy concerns - presumably, the originator of the request > > knows who they > > were attempting to contact, so the identity of the respondent > > can hardly be > > confidential. However, some personal information in > > responses (such as the > > contact address at which the respondent is currently > > registered) is subject > > to privacy concerns and can be addressed by these mechanisms." > > Also see section 4.2, which states: > > "...this document defines a new SIP header, Privacy, that can > > be used to > > specify privacy handling for requests and responses." > > > > c)It has been argued that using PAI in a response may cause > > an existing > > implementation to do the wrong thing with respect to > privacy, e.g., if > > privacy is required by the caller, a proxy may apply this to > > the connected > > user's identity in the response as well. I don't think this > > is a likely > > scenario in view of RFC 3323's coverage of privacy in requests and > > responses. > > > > d)Also it has been suggested that an existing UAS may not > take care to > > request privacy in a response, not realising that a proxy > > might add a PAI. > > Again, since RFC 3323 covers privacy in both requests and > > responses, any UA > > implementation that supports privacy in requests should also > > support privacy > > in responses. > > > > e) It has been pointed out that a proxy cannot reject a > > response if the PAI > > is wrong. I don't believe this matters - it should be > > sufficient for the > > proxy just to strip out a PAI that is wrong. > > > > In conclusion, I see evidence that PAI can be used in a > > response to assert > > the ID of the connected party and no solid evidence to the contrary. > > > > John Elwell (john.elwell@siemens.com) > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 31 00:54:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00616 for ; Wed, 31 Mar 2004 00:54:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Yg9-0005Bl-2P for sip-archive@odin.ietf.org; Wed, 31 Mar 2004 00:54:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V5sLhN019909 for sip-archive@odin.ietf.org; Wed, 31 Mar 2004 00:54:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Yfo-00058X-RH; Wed, 31 Mar 2004 00:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Yex-00057w-6P for sip@optimus.ietf.org; Wed, 31 Mar 2004 00:53:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00548 for ; Wed, 31 Mar 2004 00:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Yeu-0000Es-00 for sip@ietf.org; Wed, 31 Mar 2004 00:53:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Ydy-00009g-00 for sip@ietf.org; Wed, 31 Mar 2004 00:52:06 -0500 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1B8Yd2-0007nY-00 for sip@ietf.org; Wed, 31 Mar 2004 00:51:09 -0500 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i2V5ocEP015722 for ; Wed, 31 Mar 2004 07:50:38 +0200 Received: from vies141a.sie.siemens.at (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i2V5obZ8008737 for ; Wed, 31 Mar 2004 07:50:38 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Mar 2004 07:50:52 +0200 Message-ID: From: Postmann Erwin To: sip@ietf.org Date: Wed, 31 Mar 2004 07:50:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] SIP and IP multicast Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear SIP experts, I have following questions (maybe already discussed on the list in the past) regarding the support of multicast within SIP except the usage e.g. for multicast registration by using "sip.mcast.net". Is it possible to address a SIP message to a IPv4/IPv6 multicast address (within the TO Field)? Is it possible to configure a SIP UA in such a way that it listen to specific multicast addresses and then receive the message and processes it? Is it possible to distribute SIP messages via IP multicast mechanisms? Best regards Erwin Postmann _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Mar 31 03:48:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06568 for ; Wed, 31 Mar 2004 03:48:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8bOW-000133-Px for sip-archive@odin.ietf.org; Wed, 31 Mar 2004 03:48:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V8mKYv003966 for sip-archive@odin.ietf.org; Wed, 31 Mar 2004 03:48:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8bOE-0000z0-M4; Wed, 31 Mar 2004 03:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8bNZ-0000wh-Hi for sip@optimus.ietf.org; Wed, 31 Mar 2004 03:47:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06509 for ; Wed, 31 Mar 2004 03:47:19 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8bNX-00031y-00 for sip@ietf.org; Wed, 31 Mar 2004 03:47:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8bMW-0002vm-00 for sip@ietf.org; Wed, 31 Mar 2004 03:46:17 -0500 Received: from [61.149.156.98] (helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1B8bLw-0002pv-00 for sip@ietf.org; Wed, 31 Mar 2004 03:45:41 -0500 To: sip@ietf.org Date: Wed, 31 Mar 2004 16:45:28 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_0000073A.000069C8" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.7 required=5.0 tests=MICROSOFT_EXECUTABLE, MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [Sip] Re: important Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0001_0000073A.000069C8 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit kill the writer of this document! ------=_NextPart_000_0001_0000073A.000069C8 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: attachment.htm.exe, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0001_0000073A.000069C8-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip