From exim@www1.ietf.org Tue Sep 2 09:43:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25234 for ; Tue, 2 Sep 2003 09:43:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u5Vd-0001dM-GR for iptel-archive@odin.ietf.org; Tue, 02 Sep 2003 03:23:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h827NO3n006263 for iptel-archive@odin.ietf.org; Tue, 2 Sep 2003 03:23:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u3An-0005UZ-7Z for iptel-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 00:53:45 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26182 for ; Tue, 2 Sep 2003 00:53:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toJL-0006zK-PY for iptel-web-archive@ietf.org; Mon, 01 Sep 2003 09:01:35 -0400 Date: Mon, 01 Sep 2003 09:01:35 -0400 Message-ID: <20030901130135.21711.77396.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: iptel-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for iptel-web-archive@ietf.org: List Password // URL ---- -------- iptel@ietf.org aroxgu https://www.ietf.org/mailman/options/iptel/iptel-web-archive%40ietf.org From exim@www1.ietf.org Tue Sep 2 10:09:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28932 for ; Tue, 2 Sep 2003 10:09:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBqS-0003o3-En for iptel-archive@odin.ietf.org; Tue, 02 Sep 2003 10:09:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82E9KIe014627 for iptel-archive@odin.ietf.org; Tue, 2 Sep 2003 10:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBqS-0003no-9h for iptel-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 10:09:20 -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 KAA28798 for ; Tue, 2 Sep 2003 10:09:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBj5-0000gA-00 for iptel-web-archive@ietf.org; Tue, 02 Sep 2003 10:01:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uBcm-0000Sw-00 for iptel-web-archive@ietf.org; Tue, 02 Sep 2003 09:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBcg-0006QU-E4; Tue, 02 Sep 2003 09:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBcC-00069N-8m for iptel@optimus.ietf.org; Tue, 02 Sep 2003 09:54:36 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26431 for ; Tue, 2 Sep 2003 09:54:30 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19uBbc-0002ej-EX; Tue, 02 Sep 2003 09:54:00 -0400 X-test-idtracker: no To: IETF-Announce :; Cc: iptel@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Subject: [Iptel] Last Call: 'Management Information Base for Telephony Routing over IP (TRIP)' to Proposed Standard Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Sep 2003 09:54:00 -0400 The IESG has received a request from the IP Telephony WG to consider 'Management Information Base for Telephony Routing over IP (TRIP)' as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-09-16. File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-08.txt _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Sep 9 00:34:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07081 for ; Tue, 9 Sep 2003 00:34:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waD2-0002l5-IF for iptel-archive@odin.ietf.org; Tue, 09 Sep 2003 00:34:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h894YWNX010599 for iptel-archive@odin.ietf.org; Tue, 9 Sep 2003 00:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waD2-0002ks-F9 for iptel-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 00:34:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07069 for ; Tue, 9 Sep 2003 00:34:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waCW-0002hB-KT; Tue, 09 Sep 2003 00:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wRqJ-0003MI-7k for iptel@optimus.ietf.org; Mon, 08 Sep 2003 15:38: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 PAA17365 for ; Mon, 8 Sep 2003 15:38:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wRqH-0006dJ-00 for iptel@ietf.org; Mon, 08 Sep 2003 15:38:29 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx with esmtp (Exim 4.12) id 19wRqH-0006dG-00 for iptel@ietf.org; Mon, 08 Sep 2003 15:38:29 -0400 Received: from fokus.fraunhofer.de (fesarius [193.175.132.142]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h88JcSF26945 for ; Mon, 8 Sep 2003 21:38:28 +0200 (MEST) Message-ID: <3F5CDAB4.3050909@fokus.fraunhofer.de> From: Bogdan-Andrei IANCU Reply-To: iancu@fokus.fraunhofer.de User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] CPL - Recurse in proxy node Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Sep 2003 21:38:28 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi *, I have some questions about processing a proxy node when recurse in active. I went through the draft, but there were no mentions about what I was interested in, so, here are my questions. First of all , as is written in CPL draft, recurse applies for all proxying modes - sequential, parallel and first-only. Now, how exactly this should work!? 1) for sequential - you have a set of locations and do a serial forking on it; if a 3xx is received, put the locations from contact hdr into the set. The question is, you insert the new location into the set according to their q value (location set is a list of location sorted by the q value), or consume first all the location form the original set and if all fails start proxying to the locations received by 3xx replies? Ex: if I have the following location set A;q=0.0, B;q=1.0 and after proxying to A I get a 3xx with a Contact carrying C;q=0.8 and D;q=1.0, what will be next proxying order: C,B,D or B,C,D? 2) for parallel - I have the original location set (A) and as a final reply of the parallel forking I get a 3xx having in its Contact some new location ( that will form location set B). If I follow the idea of recursing, I will end having a serial number of parallel proxying: parallel proxying of A that will generate B -> parallel proxying of B that will maybe generate C, etc (some sequential-parallel proxy combination)- is this the way it suppose to work? 3) for first-only - after doing a proxy only to the first location form the set, if I get back a 3xx response, do I proxy based only on the new received locations or I just add them to the location set (in this case the same question as for serial proxying->adding to location set means to insert or to append - if we respect the order imposed by q or not)? Best regards, Bogdan _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Sep 9 01:03:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07780 for ; Tue, 9 Sep 2003 01:03:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waf6-0003bG-Mf for iptel-archive@odin.ietf.org; Tue, 09 Sep 2003 01:03:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8953Wwn013838 for iptel-archive@odin.ietf.org; Tue, 9 Sep 2003 01:03:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waf6-0003b7-Ji for iptel-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 01:03:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07767 for ; Tue, 9 Sep 2003 01:03:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waeb-0003Wp-HL; Tue, 09 Sep 2003 01:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wae8-0003Vy-8x for iptel@optimus.ietf.org; Tue, 09 Sep 2003 01:02:32 -0400 Received: from hss.hns.com (210-210-93-99.lan.sify.net [210.210.93.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07713; Tue, 9 Sep 2003 01:02:22 -0400 (EDT) From: Stoshniwal@hss.hns.com 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 h894uAw16449; Tue, 9 Sep 2003 10:26:11 +0530 In-Reply-To: <3F5CDAB4.3050909@fokus.fraunhofer.de> Subject: Re: [Iptel] CPL - Recurse in proxy node To: iancu@fokus.fraunhofer.de Cc: iptel , iptel-admin@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.0.2CF1|June 9, 2003) at 09/09/2003 10:26:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Sep 2003 10:26:17 +0530 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KDQpIaSwNCg0KbXkgY29tbWVudHMgaW5saW5lLi4uLg0KDQpyZWdhcmRzLA0KU2lkZGhh cnRoLg0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2lkZGhhcnRoIFRvc2huaXdhbCBAIEh1Z2hlcyBT b2Z0d2FyZSBTeXN0ZW1zDQpodHRwOi8vd3d3Lmhzc3dvcmxkLmNvbQ0KDQoNCmlwdGVsLWFkbWlu QGlldGYub3JnIHdyb3RlIG9uIDA5LzA5LzIwMDMgMDE6MDg6MjggQU06DQoNCj4gSGkgKiwNCj4N Cj4gSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHByb2Nlc3NpbmcgYSBwcm94eSBub2RlIHdo ZW4gcmVjdXJzZSBpbg0KPiBhY3RpdmUuIEkgd2VudCB0aHJvdWdoIHRoZSBkcmFmdCwgYnV0IHRo ZXJlIHdlcmUgbm8gIG1lbnRpb25zIGFib3V0IHdoYXQNCj4gSSB3YXMgaW50ZXJlc3RlZCBpbiwg c28sIGhlcmUgYXJlIG15IHF1ZXN0aW9ucy4gRmlyc3Qgb2YgYWxsICwgYXMgaXMNCj4gd3JpdHRl biBpbiBDUEwgZHJhZnQsIHJlY3Vyc2UgYXBwbGllcyBmb3IgYWxsIHByb3h5aW5nIG1vZGVzIC0N Cj4gc2VxdWVudGlhbCwgcGFyYWxsZWwgYW5kIGZpcnN0LW9ubHkuIE5vdywgaG93IGV4YWN0bHkg dGhpcyBzaG91bGQgd29yayE/DQo+DQo+IDEpIGZvciBzZXF1ZW50aWFsIC0geW91IGhhdmUgYSBz ZXQgb2YgbG9jYXRpb25zIGFuZCBkbyBhIHNlcmlhbCBmb3JraW5nDQo+IG9uIGl0OyBpZiBhIDN4 eCBpcyByZWNlaXZlZCwgcHV0IHRoZSBsb2NhdGlvbnMgZnJvbSBjb250YWN0IGhkcmludG8gdGhl DQo+IHNldC4gVGhlIHF1ZXN0aW9uIGlzLCB5b3UgaW5zZXJ0IHRoZSBuZXcgbG9jYXRpb24gaW50 byB0aGUgc2V0IGFjY29yZGluZw0KPiB0byB0aGVpciBxIHZhbHVlIChsb2NhdGlvbiBzZXQgaXMg YSBsaXN0IG9mIGxvY2F0aW9uIHNvcnRlZCBieSB0aGUgcQ0KPiB2YWx1ZSksIG9yIGNvbnN1bWUg Zmlyc3QgYWxsIHRoZSBsb2NhdGlvbiBmb3JtIHRoZSBvcmlnaW5hbCBzZXQgYW5kIGlmDQo+IGFs bCBmYWlscyBzdGFydCBwcm94eWluZyB0byB0aGUgbG9jYXRpb25zIHJlY2VpdmVkIGJ5IDN4eCBy ZXBsaWVzPyBFeDoNCj4gaWYgSSBoYXZlIHRoZSBmb2xsb3dpbmcgbG9jYXRpb24gc2V0ICBBO3E9 MC4wLCBCO3E9MS4wIGFuZCBhZnRlcg0KPiBwcm94eWluZyB0byBBIEkgZ2V0IGEgM3h4IHdpdGgg YSBDb250YWN0IGNhcnJ5aW5nIEM7cT0wLjggYW5kIEQ7cT0xLjAsDQo+IHdoYXQgd2lsbCBiZSBu ZXh0IHByb3h5aW5nIG9yZGVyOiBDLEIsRCBvciBCLEMsRD8NCg0KSXRzIHlvdXIgY2hvaWNlLCBJ IHRoaW5rLiBGcm9tIHRoZSBTZWN0aW9uIDguMS4zIG9mDQp0aGUgUkZDIDMyNjEgKFByb2Nlc3Np bmcgM3h4IHJlc3BvbnNlcykgOg0KDQoiQXMgdGhlIHRhcmdldCBzZXQgZ3Jvd3MsIHRoZSBjbGll bnQgTUFZIGdlbmVyYXRlIG5ldw0KIHJlcXVlc3RzIHRvIHRoZSBVUklzIGluIGFueSBvcmRlci4g QSBjb21tb24gbWVjaGFuaXNtDQogaXMgdG8gb3JkZXIgdGhlIHNldCBieSB0aGUg4oCcceKAnSBw YXJhbWV0ZXIgdmFsdWUgZnJvbSB0aGUNCiBDb250YWN0IGhlYWRlciBmaWVsZCB2YWx1ZS4gUmVx dWVzdHMgdG8gdGhlIFVSSXMgTUFZIGJlDQogZ2VuZXJhdGVkIHNlcmlhbGx5IG9yIGluIHBhcmFs bGVsLiBPbmUgYXBwcm9hY2ggaXMgdG8NCiBwcm9jZXNzIGdyb3VwcyBvZiBkZWNyZWFzaW5nIHEt dmFsdWVzIHNlcmlhbGx5IGFuZCBwcm9jZXNzDQogdGhlIFVSSXMgaW4gZWFjaCBxLXZhbHVlIGdy b3VwIGluIHBhcmFsbGVsLiBBbm90aGVyIGlzDQogdG8gcGVyZm9ybSBvbmx5IHNlcmlhbCBwcm9j ZXNzaW5nIGluIGRlY3JlYXNpbmcgcS12YWx1ZQ0KIG9yZGVyLCBhcmJpdHJhcmlseSBjaG9vc2lu ZyBiZXR3ZWVuIGNvbnRhY3RzIG9mIGVxdWFsDQogcS12YWx1ZS4iDQoNCkkgd291bGQgcmVjb21t ZW5kIGRlY3JlYXNpbmcgcSB2YWx1ZSBhcyB0aGUgb3JkZXIuIE9uY2UNCnlvdSBnZXQgYSAzeHgs IHBvcHVsYXRlIHlvdXIgY3VycmVudCBsb2NhdGlvbiBzZXQgd2l0aA0KdGhlIG5ldyBmb3VuZCBj b250YWN0cyAoaW4gYSBzb3J0ZWQgbWFubmVyIG9uIHEtdmFsdWUpDQphbmQgdHJ5IHRoZSBsb2Nh dGlvbnMgYWZ0ZXIgdGhlIGxvY2F0aW9uIHNldCBpcyByZWFkeS4NClNvLCBteSBhbnN3ZXIgaXMg QiwgRCwgQy4NCg0KDQoNCj4gMikgZm9yIHBhcmFsbGVsIC0gSSBoYXZlIHRoZSBvcmlnaW5hbCBs b2NhdGlvbiBzZXQgKEEpIGFuZCBhcyBhIGZpbmFsDQo+IHJlcGx5IG9mIHRoZSBwYXJhbGxlbCAg Zm9ya2luZyBJIGdldCBhIDN4eCBoYXZpbmcgaW4gaXRzIENvbnRhY3Qgc29tZQ0KPiBuZXcgbG9j YXRpb24gKCB0aGF0IHdpbGwgZm9ybSBsb2NhdGlvbiBzZXQgQikuIElmIEkgZm9sbG93IHRoZSBp ZGVhIG9mDQo+IHJlY3Vyc2luZywgSSB3aWxsIGVuZCBoYXZpbmcgYSBzZXJpYWwgbnVtYmVyIG9m IHBhcmFsbGVsIHByb3h5aW5nOg0KPiBwYXJhbGxlbCBwcm94eWluZyBvZiBBIHRoYXQgd2lsbCBn ZW5lcmF0ZSBCIC0+IHBhcmFsbGVsIHByb3h5aW5nIG9mIEINCj4gdGhhdCB3aWxsIG1heWJlIGdl bmVyYXRlIEMsIGV0YyAoc29tZSBzZXF1ZW50aWFsLXBhcmFsbGVsIHByb3h5DQo+IGNvbWJpbmF0 aW9uKS0gaXMgdGhpcyB0aGUgd2F5IGl0IHN1cHBvc2UgdG8gd29yaz8NCg0KSSB0aGluayBzby4g T3RoZXJzIGNhbiBjbGFyaWZ5IGluIGNhc2UgdGhpcyBpcyBpbmNvcnJlY3QuDQoNCg0KPiAzKSBm b3IgZmlyc3Qtb25seSAtIGFmdGVyIGRvaW5nIGEgcHJveHkgb25seSB0byB0aGUgZmlyc3QgbG9j YXRpb24gZm9ybQ0KPiB0aGUgc2V0LCBpZiBJIGdldCBiYWNrIGEgM3h4IHJlc3BvbnNlLCBkbyBJ IHByb3h5IGJhc2VkIG9ubHkgb24gdGhlIG5ldw0KPiByZWNlaXZlZCBsb2NhdGlvbnMgb3IgSSBq dXN0IGFkZCB0aGVtIHRvIHRoZSBsb2NhdGlvbiBzZXQgKGluIHRoaXMgY2FzZQ0KPiB0aGUgc2Ft ZSBxdWVzdGlvbiBhcyBmb3Igc2VyaWFsIHByb3h5aW5nLT5hZGRpbmcgdG8gbG9jYXRpb24gc2V0 IG1lYW5zDQo+IHRvIGluc2VydCBvciB0byBhcHBlbmQgLSBpZiB3ZSByZXNwZWN0IHRoZSBvcmRl ciBpbXBvc2VkIGJ5IHEgb3Igbm90KT8NCg0KSWYgeW91IGFyZSBkb2luZyBDUEwsIHlvdSBzaG91 bGQgaW5zZXJ0IHRoZSBuZXcNCmxvY2F0aW9ucyBpbnRvIHlvdXIgbG9jYXRpb24gc2V0Lg0KDQoN Cj4gQmVzdCByZWdhcmRzLA0KPiBCb2dkYW4= _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Sep 9 11:44:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18375 for ; Tue, 9 Sep 2003 11:44:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkez-0004kA-2H for iptel-archive@odin.ietf.org; Tue, 09 Sep 2003 11:44:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89Fi5Ic018228 for iptel-archive@odin.ietf.org; Tue, 9 Sep 2003 11:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkey-0004jv-Uq for iptel-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 11:44:04 -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 LAA18321 for ; Tue, 9 Sep 2003 11:43:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkex-000602-00 for iptel-web-archive@ietf.org; Tue, 09 Sep 2003 11:44:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wkew-0005zh-00 for iptel-web-archive@ietf.org; Tue, 09 Sep 2003 11:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkev-0004i2-KT; Tue, 09 Sep 2003 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wimz-0005qZ-U7 for iptel@optimus.ietf.org; Tue, 09 Sep 2003 09:44:13 -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 JAA06932 for ; Tue, 9 Sep 2003 09:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wims-0002oG-00 for iptel@ietf.org; Tue, 09 Sep 2003 09:44:07 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx with esmtp (Exim 4.12) id 19wimi-0002l7-00 for iptel@ietf.org; Tue, 09 Sep 2003 09:43:56 -0400 Received: from fokus.fraunhofer.de (fesarius [193.175.132.142]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h89DdHg01711; Tue, 9 Sep 2003 15:39:17 +0200 (MEST) Message-ID: <3F5DD805.9040404@fokus.fraunhofer.de> From: Bogdan-Andrei IANCU Reply-To: iancu@fokus.fraunhofer.de User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stoshniwal@hss.hns.com CC: iptel Subject: Re: [Iptel] CPL - Recurse in proxy node References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.fraunhofer.de id h89DdHg01711 Content-Transfer-Encoding: quoted-printable Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Sep 2003 15:39:17 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for your response. Just to be sure if I get it correct: when=20 ordering is first-only, recurse actually has no sense - if a 3xx is=20 received, disregarding recurse, the new locations will be added to the=20 location set and the proxying process will stop by exiting by=20 redirection branch. Thanks again for clarification, Bogdan Stoshniwal@hss.hns.com wrote: > > >Hi, > >my comments inline.... > >regards, >Siddharth. >------------------- >Siddharth Toshniwal @ Hughes Software Systems >http://www.hssworld.com > > >iptel-admin@ietf.org wrote on 09/09/2003 01:08:28 AM: > > =20 > >>Hi *, >> >>I have some questions about processing a proxy node when recurse in >>active. I went through the draft, but there were no mentions about wha= t >>I was interested in, so, here are my questions. First of all , as is >>written in CPL draft, recurse applies for all proxying modes - >>sequential, parallel and first-only. Now, how exactly this should work!= ? >> >>1) for sequential - you have a set of locations and do a serial forking >>on it; if a 3xx is received, put the locations from contact hdrinto the >>set. The question is, you insert the new location into the set accordin= g >>to their q value (location set is a list of location sorted by the q >>value), or consume first all the location form the original set and if >>all fails start proxying to the locations received by 3xx replies? Ex: >>if I have the following location set A;q=3D0.0, B;q=3D1.0 and after >>proxying to A I get a 3xx with a Contact carrying C;q=3D0.8 and D;q=3D1= .0, >>what will be next proxying order: C,B,D or B,C,D? >> =20 >> > >Its your choice, I think. From the Section 8.1.3 of >the RFC 3261 (Processing 3xx responses) : > >"As the target set grows, the client MAY generate new > requests to the URIs in any order. A common mechanism > is to order the set by the =E2=80=9Cq=E2=80=9D parameter value from the > Contact header field value. Requests to the URIs MAY be > generated serially or in parallel. One approach is to > process groups of decreasing q-values serially and process > the URIs in each q-value group in parallel. Another is > to perform only serial processing in decreasing q-value > order, arbitrarily choosing between contacts of equal > q-value." > >I would recommend decreasing q value as the order. Once >you get a 3xx, populate your current location set with >the new found contacts (in a sorted manner on q-value) >and try the locations after the location set is ready. >So, my answer is B, D, C. > > > > =20 > >>2) for parallel - I have the original location set (A) and as a final >>reply of the parallel forking I get a 3xx having in its Contact some >>new location ( that will form location set B). If I follow the idea of >>recursing, I will end having a serial number of parallel proxying: >>parallel proxying of A that will generate B -> parallel proxying of B >>that will maybe generate C, etc (some sequential-parallel proxy >>combination)- is this the way it suppose to work? >> =20 >> > >I think so. Others can clarify in case this is incorrect. > > > =20 > >>3) for first-only - after doing a proxy only to the first location form >>the set, if I get back a 3xx response, do I proxy based only on the new >>received locations or I just add them to the location set (in this case >>the same question as for serial proxying->adding to location set means >>to insert or to append - if we respect the order imposed by q or not)? >> =20 >> > >If you are doing CPL, you should insert the new >locations into your location set. > > > =20 > >>Best regards, >>Bogdan >> _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Sep 9 14:01:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26219 for ; Tue, 9 Sep 2003 14:01:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmnZ-0002kg-E7 for iptel-archive@odin.ietf.org; Tue, 09 Sep 2003 14:01:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89I15N2010572 for iptel-archive@odin.ietf.org; Tue, 9 Sep 2003 14:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmnZ-0002kR-Ah for iptel-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 14:01:05 -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 OAA26191 for ; Tue, 9 Sep 2003 14:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wmnW-0000fC-00 for iptel-web-archive@ietf.org; Tue, 09 Sep 2003 14:01:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wmnW-0000f9-00 for iptel-web-archive@ietf.org; Tue, 09 Sep 2003 14:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmnW-0002jU-M3; Tue, 09 Sep 2003 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmmr-0002hf-2P for iptel@optimus.ietf.org; Tue, 09 Sep 2003 14:00:21 -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 OAA26158 for ; Tue, 9 Sep 2003 14:00:14 -0400 (EDT) From: Stoshniwal@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wmmo-0000eB-00 for iptel@ietf.org; Tue, 09 Sep 2003 14:00:18 -0400 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 19wmmn-0000cf-00 for iptel@ietf.org; Tue, 09 Sep 2003 14:00:17 -0400 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 h89HxIw27845; Tue, 9 Sep 2003 23:29:19 +0530 In-Reply-To: <3F5DD805.9040404@fokus.fraunhofer.de> Subject: Re: [Iptel] CPL - Recurse in proxy node To: iancu@fokus.fraunhofer.de Cc: iptel X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.0.2CF1|June 9, 2003) at 09/09/2003 11:29:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Sep 2003 23:29:26 +0530 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KDQpZZXMsIHRoYXQgaXMgY29ycmVjdC4gSWYgYSBmaXJzdC1vbmx5IGxvY2F0aW9uIGlz IHRyaWVkLA0KdGhlIHJlY3Vyc2lvbiBzaG91bGQgbm90IGhhcHBlbiB0aWxsIHRoZSBDUEwgc2Ny aXB0DQpoYXMgcHJvY2Vzc2VkIHRob3NlIGxvY2F0aW9ucy4NCg0KcmVnYXJkcywNClNpZGRoYXJ0 aC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0NClNpZGRoYXJ0aCBUb3Nobml3YWwgQCBIdWdoZXMgU29m dHdhcmUgU3lzdGVtcw0KaHR0cDovL3d3dy5oc3N3b3JsZC5jb20NCg0KDQoNCkJvZ2Rhbi1BbmRy ZWkgSUFOQ1UgPGlhbmN1QGZva3VzLmZyYXVuaG9mZXIuZGU+IHdyb3RlIG9uIDA5LzA5LzIwMDMN CjA3OjA5OjE3IFBNOg0KDQo+IFRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4gSnVzdCB0byBiZSBz dXJlIGlmIEkgZ2V0IGl0IGNvcnJlY3Q6IHdoZW4NCj4gb3JkZXJpbmcgaXMgZmlyc3Qtb25seSwg cmVjdXJzZSBhY3R1YWxseSBoYXMgbm8gc2Vuc2UgLSBpZiBhIDN4eCBpcw0KPiByZWNlaXZlZCwg ZGlzcmVnYXJkaW5nIHJlY3Vyc2UsIHRoZSBuZXcgbG9jYXRpb25zIHdpbGwgYmUgYWRkZWQgdG8g dGhlDQo+IGxvY2F0aW9uIHNldCBhbmQgdGhlIHByb3h5aW5nIHByb2Nlc3Mgd2lsbCBzdG9wIGJ5 ICBleGl0aW5nIGJ5DQo+IHJlZGlyZWN0aW9uIGJyYW5jaC4NCj4NCj4gVGhhbmtzIGFnYWluIGZv ciBjbGFyaWZpY2F0aW9uLA0KPiBCb2dkYW4NCj4NCj4NCj4gU3Rvc2huaXdhbEBoc3MuaG5zLmNv bSB3cm90ZToNCj4NCj4gPkhpLA0KPiA+DQo+ID5teSBjb21tZW50cyBpbmxpbmUuLi4uDQo+ID4N Cj4gPnJlZ2FyZHMsDQo+ID5TaWRkaGFydGguDQo+ID4tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID5T aWRkaGFydGggVG9zaG5pd2FsIEAgSHVnaGVzIFNvZnR3YXJlIFN5c3RlbXMNCj4gPmh0dHA6Ly93 d3cuaHNzd29ybGQuY29tDQo+ID4NCj4gPg0KPiA+aXB0ZWwtYWRtaW5AaWV0Zi5vcmcgd3JvdGUg b24gMDkvMDkvMjAwMyAwMTowODoyOCBBTToNCj4gPg0KPiA+DQo+ID4NCj4gPj5IaSAqLA0KPiA+ Pg0KPiA+PkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCBwcm9jZXNzaW5nIGEgcHJveHkgbm9k ZSB3aGVuIHJlY3Vyc2UgaW4NCj4gPj5hY3RpdmUuIEkgd2VudCB0aHJvdWdoIHRoZSBkcmFmdCwg YnV0IHRoZXJlIHdlcmUgbm8gIG1lbnRpb25zYWJvdXQgd2hhdA0KPiA+Pkkgd2FzIGludGVyZXN0 ZWQgaW4sIHNvLCBoZXJlIGFyZSBteSBxdWVzdGlvbnMuIEZpcnN0IG9mIGFsbCAsIGFzIGlzDQo+ ID4+d3JpdHRlbiBpbiBDUEwgZHJhZnQsIHJlY3Vyc2UgYXBwbGllcyBmb3IgYWxsIHByb3h5aW5n IG1vZGVzIC0NCj4gPj5zZXF1ZW50aWFsLCBwYXJhbGxlbCBhbmQgZmlyc3Qtb25seS4gTm93LCBo b3cgZXhhY3RseSB0aGlzDQo+IHNob3VsZCB3b3JrIT8NCj4gPj4NCj4gPj4xKSBmb3Igc2VxdWVu dGlhbCAtIHlvdSBoYXZlIGEgc2V0IG9mIGxvY2F0aW9ucyBhbmQgZG8gYSBzZXJpYWwgZm9ya2lu Zw0KPiA+Pm9uIGl0OyBpZiBhIDN4eCBpcyByZWNlaXZlZCwgcHV0IHRoZSBsb2NhdGlvbnMgZnJv bSBjb250YWN0IGhkcmludG8gdGhlDQo+ID4+c2V0LiBUaGUgcXVlc3Rpb24gaXMsIHlvdSBpbnNl cnQgdGhlIG5ldyBsb2NhdGlvbiBpbnRvIHRoZQ0KPiBzZXQgYWNjb3JkaW5nDQo+ID4+dG8gdGhl aXIgcSB2YWx1ZSAobG9jYXRpb24gc2V0IGlzIGEgbGlzdCBvZiBsb2NhdGlvbiBzb3J0ZWQgYnkg dGhlIHENCj4gPj52YWx1ZSksIG9yIGNvbnN1bWUgZmlyc3QgYWxsIHRoZSBsb2NhdGlvbiBmb3Jt IHRoZSBvcmlnaW5hbCBzZXQgYW5kIGlmDQo+ID4+YWxsIGZhaWxzIHN0YXJ0IHByb3h5aW5nIHRv IHRoZSBsb2NhdGlvbnMgcmVjZWl2ZWQgYnkgM3h4IHJlcGxpZXM/IEV4Og0KPiA+PmlmIEkgaGF2 ZSB0aGUgZm9sbG93aW5nIGxvY2F0aW9uIHNldCAgQTtxPTAuMCwgQjtxPTEuMCBhbmQgYWZ0ZXIN Cj4gPj5wcm94eWluZyB0byBBIEkgZ2V0IGEgM3h4IHdpdGggYSBDb250YWN0IGNhcnJ5aW5nIEM7 cT0wLjggYW5kIEQ7cT0xLjAsDQo+ID4+d2hhdCB3aWxsIGJlIG5leHQgcHJveHlpbmcgb3JkZXI6 IEMsQixEIG9yIEIsQyxEPw0KPiA+Pg0KPiA+Pg0KPiA+DQo+ID5JdHMgeW91ciBjaG9pY2UsIEkg dGhpbmsuIEZyb20gdGhlIFNlY3Rpb24gOC4xLjMgb2YNCj4gPnRoZSBSRkMgMzI2MSAoUHJvY2Vz c2luZyAzeHggcmVzcG9uc2VzKSA6DQo+ID4NCj4gPiJBcyB0aGUgdGFyZ2V0IHNldCBncm93cywg dGhlIGNsaWVudCBNQVkgZ2VuZXJhdGUgbmV3DQo+ID4gcmVxdWVzdHMgdG8gdGhlIFVSSXMgaW4g YW55IG9yZGVyLiBBIGNvbW1vbiBtZWNoYW5pc20NCj4gPiBpcyB0byBvcmRlciB0aGUgc2V0IGJ5 IHRoZSDigJxx4oCdIHBhcmFtZXRlciB2YWx1ZSBmcm9tIHRoZQ0KPiA+IENvbnRhY3QgaGVhZGVy IGZpZWxkIHZhbHVlLiBSZXF1ZXN0cyB0byB0aGUgVVJJcyBNQVkgYmUNCj4gPiBnZW5lcmF0ZWQg c2VyaWFsbHkgb3IgaW4gcGFyYWxsZWwuIE9uZSBhcHByb2FjaCBpcyB0bw0KPiA+IHByb2Nlc3Mg Z3JvdXBzIG9mIGRlY3JlYXNpbmcgcS12YWx1ZXMgc2VyaWFsbHkgYW5kIHByb2Nlc3MNCj4gPiB0 aGUgVVJJcyBpbiBlYWNoIHEtdmFsdWUgZ3JvdXAgaW4gcGFyYWxsZWwuIEFub3RoZXIgaXMNCj4g PiB0byBwZXJmb3JtIG9ubHkgc2VyaWFsIHByb2Nlc3NpbmcgaW4gZGVjcmVhc2luZyBxLXZhbHVl DQo+ID4gb3JkZXIsIGFyYml0cmFyaWx5IGNob29zaW5nIGJldHdlZW4gY29udGFjdHMgb2YgZXF1 YWwNCj4gPiBxLXZhbHVlLiINCj4gPg0KPiA+SSB3b3VsZCByZWNvbW1lbmQgZGVjcmVhc2luZyBx IHZhbHVlIGFzIHRoZSBvcmRlci4gT25jZQ0KPiA+eW91IGdldCBhIDN4eCwgcG9wdWxhdGUgeW91 ciBjdXJyZW50IGxvY2F0aW9uIHNldCB3aXRoDQo+ID50aGUgbmV3IGZvdW5kIGNvbnRhY3RzIChp biBhIHNvcnRlZCBtYW5uZXIgb24gcS12YWx1ZSkNCj4gPmFuZCB0cnkgdGhlIGxvY2F0aW9ucyBh ZnRlciB0aGUgbG9jYXRpb24gc2V0IGlzIHJlYWR5Lg0KPiA+U28sIG15IGFuc3dlciBpcyBCLCBE LCBDLg0KPiA+DQo+ID4NCj4gPg0KPiA+PjIpIGZvciBwYXJhbGxlbCAtIEkgaGF2ZSB0aGUgb3Jp Z2luYWwgbG9jYXRpb24gc2V0IChBKSBhbmQgYXMgYSBmaW5hbA0KPiA+PnJlcGx5IG9mIHRoZSBw YXJhbGxlbCAgZm9ya2luZyBJIGdldCBhIDN4eCBoYXZpbmcgaW4gaXRzIENvbnRhY3Qgc29tZQ0K PiA+Pm5ldyBsb2NhdGlvbiAoIHRoYXQgd2lsbCBmb3JtIGxvY2F0aW9uIHNldCBCKS4gSWYgSSBm b2xsb3cgdGhlIGlkZWEgb2YNCj4gPj5yZWN1cnNpbmcsIEkgd2lsbCBlbmQgaGF2aW5nIGEgc2Vy aWFsIG51bWJlciBvZiBwYXJhbGxlbCBwcm94eWluZzoNCj4gPj5wYXJhbGxlbCBwcm94eWluZyBv ZiBBIHRoYXQgd2lsbCBnZW5lcmF0ZSBCIC0+IHBhcmFsbGVsIHByb3h5aW5nIG9mIEINCj4gPj50 aGF0IHdpbGwgbWF5YmUgZ2VuZXJhdGUgQywgZXRjIChzb21lIHNlcXVlbnRpYWwtcGFyYWxsZWwg cHJveHkNCj4gPj5jb21iaW5hdGlvbiktIGlzIHRoaXMgdGhlIHdheSBpdCBzdXBwb3NlIHRvIHdv cms/DQo+ID4+DQo+ID4+DQo+ID4NCj4gPkkgdGhpbmsgc28uIE90aGVycyBjYW4gY2xhcmlmeSBp biBjYXNlIHRoaXMgaXMgaW5jb3JyZWN0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+PjMpIGZvciBmaXJz dC1vbmx5IC0gYWZ0ZXIgZG9pbmcgYSBwcm94eSBvbmx5IHRvIHRoZSBmaXJzdCBsb2NhdGlvbiBm b3JtDQo+ID4+dGhlIHNldCwgaWYgSSBnZXQgYmFjayBhIDN4eCByZXNwb25zZSwgZG8gSSBwcm94 eSBiYXNlZCBvbmx5IG9uIHRoZSBuZXcNCj4gPj5yZWNlaXZlZCBsb2NhdGlvbnMgb3IgSSBqdXN0 IGFkZCB0aGVtIHRvIHRoZSBsb2NhdGlvbiBzZXQgKGludGhpcyBjYXNlDQo+ID4+dGhlIHNhbWUg cXVlc3Rpb24gYXMgZm9yIHNlcmlhbCBwcm94eWluZy0+YWRkaW5nIHRvIGxvY2F0aW9uIHNldCBt ZWFucw0KPiA+PnRvIGluc2VydCBvciB0byBhcHBlbmQgLSBpZiB3ZSByZXNwZWN0IHRoZSBvcmRl ciBpbXBvc2VkIGJ5IHEgb3Igbm90KT8NCj4gPj4NCj4gPj4NCj4gPg0KPiA+SWYgeW91IGFyZSBk b2luZyBDUEwsIHlvdSBzaG91bGQgaW5zZXJ0IHRoZSBuZXcNCj4gPmxvY2F0aW9ucyBpbnRvIHlv dXIgbG9jYXRpb24gc2V0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+PkJlc3QgcmVnYXJkcywNCj4gPj5C b2dkYW4= _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Sep 12 16:57:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15333 for ; Fri, 12 Sep 2003 16:57:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xuyV-00082h-NW for iptel-archive@odin.ietf.org; Fri, 12 Sep 2003 16:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CKv3Xt030909 for iptel-archive@odin.ietf.org; Fri, 12 Sep 2003 16:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xuyV-00082S-Jr for iptel-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 16:57:03 -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 QAA15315 for ; Fri, 12 Sep 2003 16:56:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xuyT-0005J8-00 for iptel-web-archive@ietf.org; Fri, 12 Sep 2003 16:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xuyT-0005J4-00 for iptel-web-archive@ietf.org; Fri, 12 Sep 2003 16:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xuyT-00081x-Ll; Fri, 12 Sep 2003 16:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xuyM-00081f-Re for iptel@optimus.ietf.org; Fri, 12 Sep 2003 16:56:55 -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 QAA15308 for ; Fri, 12 Sep 2003 16:56:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xuyK-0005J1-00 for iptel@ietf.org; Fri, 12 Sep 2003 16:56:52 -0400 Received: from jumbo133.adsl.netsonic.fi ([81.17.197.133] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 19xuyJ-0005Ix-00 for iptel@ietf.org; Fri, 12 Sep 2003 16:56:52 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h8C7igSB028204; Fri, 12 Sep 2003 10:44:42 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h8C7igUu028203; Fri, 12 Sep 2003 10:44:42 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: iancu@fokus.fraunhofer.de Cc: Stoshniwal@hss.hns.com, iptel Subject: Re: [Iptel] CPL - Recurse in proxy node X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F5DD805.9040404@fokus.fraunhofer.de> (Bogdan-Andrei IANCU's message of "Tue, 09 Sep 2003 15:39:17 +0200") User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) References: <3F5DD805.9040404@fokus.fraunhofer.de> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 10:44:42 +0300 Bogdan-Andrei IANCU writes: >Thanks for your response. Just to be sure if I get it correct: when ordering >is first-only, recurse actually has no sense - if a 3xx is received, >disregarding recurse, the new locations will be added to the location set >and the proxying process will stop by exiting by redirection branch. I'm afraid I have to disagree with you. The Q values in the user's locations should not be mixed with Q values from 302 Contact header. So, if you execute recursive first-only/sequential proxy node, the contact(s) in 302 are processed immediately, not mixed with the rest of the location set. Pekka >>Hi, >>my comments inline.... >>regards, >>Siddharth. >>------------------- >>Siddharth Toshniwal @ Hughes Software Systems >>http://www.hssworld.com >>iptel-admin@ietf.org wrote on 09/09/2003 01:08:28 AM: >>>Hi *, >>>I have some questions about processing a proxy node when recurse in >>>active. I went through the draft, but there were no mentions about what >>>I was interested in, so, here are my questions. First of all , as is >>>written in CPL draft, recurse applies for all proxying modes - >>>sequential, parallel and first-only. Now, how exactly this should work!? >>>1) for sequential - you have a set of locations and do a serial forking >>>on it; if a 3xx is received, put the locations from contact hdrinto the >>>set. The question is, you insert the new location into the set according >>>to their q value (location set is a list of location sorted by the q >>>value), or consume first all the location form the original set and if >>>all fails start proxying to the locations received by 3xx replies? Ex: >>>if I have the following location set A;q=0.0, B;q=1.0 and after >>>proxying to A I get a 3xx with a Contact carrying C;q=0.8 and D;q=1.0, >>>what will be next proxying order: C,B,D or B,C,D? >>Its your choice, I think. From the Section 8.1.3 of >>the RFC 3261 (Processing 3xx responses) : >>"As the target set grows, the client MAY generate new >> requests to the URIs in any order. A common mechanism >> is to order the set by the "q" parameter value from the >> Contact header field value. Requests to the URIs MAY be >> generated serially or in parallel. One approach is to >> process groups of decreasing q-values serially and process >> the URIs in each q-value group in parallel. Another is >> to perform only serial processing in decreasing q-value >> order, arbitrarily choosing between contacts of equal >> q-value." >>I would recommend decreasing q value as the order. Once >>you get a 3xx, populate your current location set with >>the new found contacts (in a sorted manner on q-value) >>and try the locations after the location set is ready. >>So, my answer is B, D, C. >>>2) for parallel - I have the original location set (A) and as a final >>>reply of the parallel forking I get a 3xx having in its Contact some >>>new location ( that will form location set B). If I follow the idea of >>>recursing, I will end having a serial number of parallel proxying: >>>parallel proxying of A that will generate B -> parallel proxying of B >>>that will maybe generate C, etc (some sequential-parallel proxy >>>combination)- is this the way it suppose to work? >>I think so. Others can clarify in case this is incorrect. >>>3) for first-only - after doing a proxy only to the first location form >>>the set, if I get back a 3xx response, do I proxy based only on the new >>>received locations or I just add them to the location set (in this case >>>the same question as for serial proxying->adding to location set means >>>to insert or to append - if we respect the order imposed by q or not)? >>If you are doing CPL, you should insert the new >>locations into your location set. >>>Best regards, >>>Bogdan _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Sep 15 11:10:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06342 for ; Mon, 15 Sep 2003 11:10:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuzN-0004XI-Pm for iptel-archive@odin.ietf.org; Mon, 15 Sep 2003 11:10:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FFA5mX017429 for iptel-archive@odin.ietf.org; Mon, 15 Sep 2003 11:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuzN-0004X2-MN for iptel-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 11:10:05 -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 LAA06319 for ; Mon, 15 Sep 2003 11:09:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yuzK-000123-00 for iptel-web-archive@ietf.org; Mon, 15 Sep 2003 11:10:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yuzK-00011z-00 for iptel-web-archive@ietf.org; Mon, 15 Sep 2003 11:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuzK-0004W5-A9; Mon, 15 Sep 2003 11:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yq88-000825-Gd for iptel@optimus.ietf.org; Mon, 15 Sep 2003 05:58:48 -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 FAA20863; Mon, 15 Sep 2003 05:58:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yq83-0002Mo-00; Mon, 15 Sep 2003 05:58:43 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19yq82-0002MW-00; Mon, 15 Sep 2003 05:58:43 -0400 Received: from shiraz.ee.surrey.ac.uk ([131.227.86.21] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19yq3l-0005RH-00; Mon, 15 Sep 2003 10:54:17 +0100 Received: from ees1na (helo=localhost) by shiraz.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 19yq3j-0003Sz-00; Mon, 15 Sep 2003 10:54:15 +0100 From: Nadeem Akhtar X-X-Sender: ees1na@shiraz.ee.surrey.ac.uk To: n.akhtar@eim.surrey.ac.uk cc: c.politis@eim.surrey.ac.uk Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.5 tests=BAYES_30,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19yq3l-0005RH-00*oe7vkwj2vUU* (SECM, UniS) Subject: [Iptel] IST EVOLUTE International Workshop Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Sep 2003 10:54:15 +0100 (BST) ** Our apologies if you receive multiple copies of this CfP ** --------------------------------------------------------------------------------- IST EVOLUTE International Workshop Univeristy of Surrey, UK Guildford, Nov. 10, 2003 http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/ --------------------------------------------------------------------------------- <<<<< CALL FOR SUBMISSIONS >>>> The International Workshop on Beyond 3G Evolution of Systems and Services is an event within the framework of the IST-2001-32449 EVOLUTE project, which is partly funded by the EU. The EVOLUTE Workshop, will take place on November 10th, 2003 in Guildford, UK. The Workshop will be hosted by the University of Surrey. The EVOLUTE Workshop will be structured along four tracks: Mobility Management for All-IP Network Infrastructures AAA and Multimedia Services for Next Generation Networks Business Models and Scenarios Testbeds and prototypes For more and detailed information on this Workshop, please visit the website at: http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/ Thank you for your time in advance and welcome to Guildford! Sincerely, Organising Committee of IST EVOLUTE International Workshop CCSR, University of Surrey, UK http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/ _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Sep 15 18:05:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28110 for ; Mon, 15 Sep 2003 18:05:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1T6-0006Bf-NL for iptel-archive@odin.ietf.org; Mon, 15 Sep 2003 18:05:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FM5CkN023782 for iptel-archive@odin.ietf.org; Mon, 15 Sep 2003 18:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1T6-0006BV-Jb for iptel-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 18:05:12 -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 SAA28040 for ; Mon, 15 Sep 2003 18:05:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z1T3-0006t7-00 for iptel-web-archive@ietf.org; Mon, 15 Sep 2003 18:05:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z1T3-0006t4-00 for iptel-web-archive@ietf.org; Mon, 15 Sep 2003 18:05:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1Sw-0006At-OE; Mon, 15 Sep 2003 18:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yvbZ-0000v0-PE for iptel@optimus.ietf.org; Mon, 15 Sep 2003 11:49:33 -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 LAA08447 for ; Mon, 15 Sep 2003 11:49:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yvbY-0004ot-00 for iptel@ietf.org; Mon, 15 Sep 2003 11:49:32 -0400 Received: from relay1.clb.oleane.net ([213.56.31.21]) by ietf-mx with esmtp (Exim 4.12) id 19yvbX-0004ls-00 for iptel@ietf.org; Mon, 15 Sep 2003 11:49:32 -0400 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay1.clb.oleane.net with SMTP id h8FFn0Mx013042 for ; Mon, 15 Sep 2003 17:49:00 +0200 Message-ID: <023401c37ba1$02523940$0601a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0231_01C37BB1.C55C6360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Iptel] International SIP '04 Conference Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Sep 2003 17:49:54 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0231_01C37BB1.C55C6360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For many years International SIP has tracked the evolution of the SIP = protocol by opening up discussion to gainful subjects (Presence and = Instant messaging yesterday, Mobile Networks today, IPv6 tomorrow, etc). = The conference/exhibition will take place in Paris on January 20 to 23. = The SIP 2004 program will be dedicated to deployment examples. The = objective is to show that SIP is henceforth a stable and functional = protocol and operators can invest in architectures and roll out = services.=20 http://www.upperside.fr/sip2004/sip2004intro.htm ------=_NextPart_000_0231_01C37BB1.C55C6360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For many years = International SIP=20 has tracked the evolution of the SIP protocol by opening up = discussion=20 to gainful subjects (Presence and Instant messaging yesterday, Mobile = Networks=20 today, IPv6 tomorrow, etc).
The conference/exhibition will = take place in=20 Paris on January 20 to = 23. The SIP 2004 = program=20 will be dedicated to deployment examples. The objective is to show that = SIP is=20 henceforth a stable and functional protocol and operators can invest in=20 architectures and roll out services.

http://www.uppe= rside.fr/sip2004/sip2004intro.htm
------=_NextPart_000_0231_01C37BB1.C55C6360-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Sep 17 03:15:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29500 for ; Wed, 17 Sep 2003 03:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWWn-0007MP-KV for iptel-archive@odin.ietf.org; Wed, 17 Sep 2003 03:15:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H7F5Pj028294 for iptel-archive@odin.ietf.org; Wed, 17 Sep 2003 03:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWWm-0007MD-S7 for iptel-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 03:15:04 -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 DAA29487 for ; Wed, 17 Sep 2003 03:14:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWWk-0001zj-00 for iptel-web-archive@ietf.org; Wed, 17 Sep 2003 03:15:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zWWk-0001zf-00 for iptel-web-archive@ietf.org; Wed, 17 Sep 2003 03:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWWj-0007Le-V4; Wed, 17 Sep 2003 03:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWVt-0007Ku-Nm for iptel@optimus.ietf.org; Wed, 17 Sep 2003 03:14:09 -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 DAA29481 for ; Wed, 17 Sep 2003 03:14:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWVr-0001zc-00 for iptel@ietf.org; Wed, 17 Sep 2003 03:14:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zWVr-0001zY-00 for iptel@ietf.org; Wed, 17 Sep 2003 03:14:07 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h8H7DYUg015898; Wed, 17 Sep 2003 03:13:34 -0400 (EDT) Message-ID: <3F680997.7030209@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iancu@fokus.fraunhofer.de CC: iptel Subject: Re: [Iptel] CPL - Recurse in proxy node References: <3F5CDAB4.3050909@fokus.fraunhofer.de> In-Reply-To: <3F5CDAB4.3050909@fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Sep 2003 03:13:27 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit a thought inline. Bogdan-Andrei IANCU wrote: > Hi *, > > I have some questions about processing a proxy node when recurse in > active. I went through the draft, but there were no mentions about what > I was interested in, so, here are my questions. First of all , as is > written in CPL draft, recurse applies for all proxying modes - > sequential, parallel and first-only. Now, how exactly this should work!? > > 1) for sequential - you have a set of locations and do a serial forking > on it; if a 3xx is received, put the locations from contact hdr into the > set. The question is, you insert the new location into the set according > to their q value (location set is a list of location sorted by the q > value), or consume first all the location form the original set and if > all fails start proxying to the locations received by 3xx replies? Ex: > if I have the following location set A;q=0.0, B;q=1.0 and after > proxying to A I get a 3xx with a Contact carrying C;q=0.8 and D;q=1.0, > what will be next proxying order: C,B,D or B,C,D? Interesting question. rfc3261, as written, advises to re-sort the result in q-value order, so you would get B, D, C. However, I have raised an issue recently about the problem with doing this. It only works on the assumption that the various elements which have provided these q-values agree on a semantic for the values such that they can be chosen in a way which allows meaningful ordering. That is not the semantic of q-values, in fact, as they are really meant to be ordinal, not cardinal. As such, you cannot usefully mix q-values from different sources and get a meaningful order. As such, the only approach which makes sense is to treat the redirect as a replacement for the contact which caused the redirect. In that case, you would substitute A in {A,B} with {D,C} and thus get {{D,C},B}. That is the approach I would advise. > > 2) for parallel - I have the original location set (A) and as a final > reply of the parallel forking I get a 3xx having in its Contact some > new location ( that will form location set B). If I follow the idea of > recursing, I will end having a serial number of parallel proxying: > parallel proxying of A that will generate B -> parallel proxying of B > that will maybe generate C, etc (some sequential-parallel proxy > combination)- is this the way it suppose to work? Yes. > > 3) for first-only - after doing a proxy only to the first location form > the set, if I get back a 3xx response, do I proxy based only on the new > received locations or I just add them to the location set (in this case > the same question as for serial proxying->adding to location set means > to insert or to append - if we respect the order imposed by q or not)? Good question. I think the text is contradictory in that regard. The behavior described for recurse and first-only cannot be mutually satisfied. I believe this is a bug which needs to be clarified in the document. I would tend to think that "first-only" should win, and so the recurse output would be taken even if recurse was also set. -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 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Sep 19 22:37:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04589 for ; Fri, 19 Sep 2003 22:37:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhFt020140 for ; Fri, 19 Sep 2003 21:37:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TLDKle017842 for iptel-archive@odin.ietf.org; Fri, 29 Aug 2003 17:13:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19soJp-0006tg-FL for iptel-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 14:49:57 -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 OAA22868 for ; Fri, 29 Aug 2003 14:49:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19soJm-0003dP-00 for iptel-web-archive@ietf.org; Fri, 29 Aug 2003 14:49:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19soJm-0003dL-00 for iptel-web-archive@ietf.org; Fri, 29 Aug 2003 14:49:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snyw-0005og-77; Fri, 29 Aug 2003 14:28:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19smRj-0001BY-CY for iptel@optimus.ietf.org; Fri, 29 Aug 2003 12:49:59 -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 MAA12716 for ; Fri, 29 Aug 2003 12:49:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smCc-000040-00 for iptel@ietf.org; Fri, 29 Aug 2003 12:34:22 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19smCa-00003s-00 for iptel@ietf.org; Fri, 29 Aug 2003 12:34:20 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id D8EF620660C for ; Fri, 29 Aug 2003 12:32:39 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19slRq-0007a0-Fn for ietf-announce-list@asgard.ietf.org; Fri, 29 Aug 2003 11:46:02 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19slEr-0006il-Ih for all-ietf@asgard.ietf.org; Fri, 29 Aug 2003 11:32:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03386; Fri, 29 Aug 2003 11:32:30 -0400 (EDT) Message-Id: <200308291532.LAA03386@ietf.org> To: IETF-Announce: ; Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+225357_27306547511527_7933520996" Subject: [Iptel] I-D ACTION:draft-ietf-iptel-cpl-08.txt,.ps Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 29 Aug 2003 11:32:30 -0400 --MIMEStream=_0+225357_27306547511527_7933520996 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : CPL: A Language for User Control of Internet Telephony Services Author(s) : J. Lennox, X. Wu, H. Schulzrinne Filename : draft-ietf-iptel-cpl-08.txt,.ps Pages : 82 Date : 2003-8-29 The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@lists.research.bell-labs.com and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-08.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-iptel-cpl-08.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-iptel-cpl-08.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. --MIMEStream=_0+225357_27306547511527_7933520996 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+134339_4765985965184_88235612644" --MIMEStream=_1+134339_4765985965184_88235612644 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-29113648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-cpl-08.txt --MIMEStream=_1+134339_4765985965184_88235612644 Content-Type: Message/External-body; name="draft-ietf-iptel-cpl-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113648.I-D@ietf.org> --MIMEStream=_1+134339_4765985965184_88235612644-- --MIMEStream=_0+225357_27306547511527_7933520996-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel